В программировании нет вообще никаких непреложных истин. Даже самые очевидные правила могут иметь контекст, в которых их применять нельзя. К сожалению в 99% организаций есть прям заповеди, обязательные к исполнению. И есть правила, которые считаются правилами хорошего тона (как не сморкаться в занавеску). Однако всегда бывают ситуации, когда лучше все-таки сморкаться.
Вот примеры.
DRY
Например, DRY - don’t repeat yourself. Хорошее полезное правило, но его можно довести до маразма. Из того что я встречал на практике: есть два разных по бизнес-смыслу раздела, которые начинались с простого CRUD, и многие части (и фронта и бека) выглядели во многом абсолютно одинаково. Если их объединить с помощью общей высосанной из пальца абстракции и тем самым избавиться от небольшого дублирования кода, то потом (очень скоро) можно будет сойти с ума, потому что эти две вещи скоро разъедутся, обрастая кастомными фичами, и абстракция будет только вредить. Нельзя абстрагировать неабстрагуемое, даже если DRY нарушен.
«[Немного] дублирования обходится гораздо дешевле, чем неправильная абстракция» — Сэнди Мец
Т.е. DRY - хороший принцип, но бывают исключения.
KISS
Keep it simple, stupid. Всем хотелось бы держать программу простой, но иногда приходится всё усложнить, чтобы добиться ускорения разработки, уменьшения количества ошибок и т.д. Например, KISS может войти в прямое противоречие с тем же DRY: код с дублированием зачастую проще понимать (меньше абстракций и зависимостей), зато это огромное поле для ошибок (забыл поправить в третьем файле) и замедление добавления новых фич.
В фунции не должно быть более чем X строк, длина строки должна быть не более чем Y и т.д. (правила линтера)
Обычно этот X придумывается от балды. В таких случаях хочется спросить, почему именно столько, а не на одну больше или на две меньше. И обычно время от времени появляется вполне валидный код, который по каким-то причинам не влезает, и люди извращаются как могут, переписывают через дичь, чтобы как-то пайплайн протащить.
Мы пишем только на таком-то языке
И начинаются пляски с бубном вокруг PHP, на котором пытаются завести highload-решения. Это выливается в интереснейшие инженерные задачи, как из говна и палок сделать самолёт. Бесконечные темы для докладов на конференциях.
и тысячи таких
У каждого программиста между ушей есть нейросеть, которой он пользуется. Нельзя рассматривать его как бездумного робота.
Если кто-то тупой и постоянно творит дичь, то не надо добавлять правил и следить за их исполнением, тупого надо просто увольнять. Зачем вам тупой???. Если это опытный программист, и в большинстве случаев поступает разумно, то не надо его ограничивать всякой хернёй - это уменьшение эффективности, да еще и снижение мотивации
Вот примеры.
DRY
Например, DRY - don’t repeat yourself. Хорошее полезное правило, но его можно довести до маразма. Из того что я встречал на практике: есть два разных по бизнес-смыслу раздела, которые начинались с простого CRUD, и многие части (и фронта и бека) выглядели во многом абсолютно одинаково. Если их объединить с помощью общей высосанной из пальца абстракции и тем самым избавиться от небольшого дублирования кода, то потом (очень скоро) можно будет сойти с ума, потому что эти две вещи скоро разъедутся, обрастая кастомными фичами, и абстракция будет только вредить. Нельзя абстрагировать неабстрагуемое, даже если DRY нарушен.
«[Немного] дублирования обходится гораздо дешевле, чем неправильная абстракция» — Сэнди Мец
Т.е. DRY - хороший принцип, но бывают исключения.
KISS
Keep it simple, stupid. Всем хотелось бы держать программу простой, но иногда приходится всё усложнить, чтобы добиться ускорения разработки, уменьшения количества ошибок и т.д. Например, KISS может войти в прямое противоречие с тем же DRY: код с дублированием зачастую проще понимать (меньше абстракций и зависимостей), зато это огромное поле для ошибок (забыл поправить в третьем файле) и замедление добавления новых фич.
В фунции не должно быть более чем X строк, длина строки должна быть не более чем Y и т.д. (правила линтера)
Обычно этот X придумывается от балды. В таких случаях хочется спросить, почему именно столько, а не на одну больше или на две меньше. И обычно время от времени появляется вполне валидный код, который по каким-то причинам не влезает, и люди извращаются как могут, переписывают через дичь, чтобы как-то пайплайн протащить.
Мы пишем только на таком-то языке
И начинаются пляски с бубном вокруг PHP, на котором пытаются завести highload-решения. Это выливается в интереснейшие инженерные задачи, как из говна и палок сделать самолёт. Бесконечные темы для докладов на конференциях.
и тысячи таких
У каждого программиста между ушей есть нейросеть, которой он пользуется. Нельзя рассматривать его как бездумного робота.
Если кто-то тупой и постоянно творит дичь, то не надо добавлять правил и следить за их исполнением, тупого надо просто увольнять. Зачем вам тупой???. Если это опытный программист, и в большинстве случаев поступает разумно, то не надо его ограничивать всякой хернёй - это уменьшение эффективности, да еще и снижение мотивации