Улучшенные четыре правила проектирования ПО

[LaRN]

Вот дела. То ругают индо-код, то пишут что это не так уж и плохо.

[gnaeus]

Мне кажется, автор не топит за говнокод, а говорит достаточно разумные вещи.

• Технологии, требующие глубокого изучения или знания математики, повышают порог входа.

Если у нас собралась команда рок-звезд, мы можем применять все это. Но не каждому это дано. Не все столь фанатичны. И для среднестатистического проекта лучше писать так, чтобы это понял среднестатистический разработчик. И да, если пишем с "индусами", чтобы понял даже "индус".

• Бездумное следование принципу DRY может увести не туда.

Как он выглядит упрощенно: увидели повторяющийся код — выделили в функцию / метод / базовый класс. Но это неверно! Сначала мы должны ответить на вопрос: а должен ли этот код повторяться и при внесении изменений? Или в последствии мы можем изменить один вариант копипасты, а другой оставить нетронутым? Т.е. отвечает ли выделенная функция принципу SRP.

Поэтому иногда копипаста и бойлерплейт бывают полезны.

[LaRN]

Согласен. Но в описании про это особо не описано и нет критериев, когда нужно выделять код в процедуру, а когда не нужно, т.е. по факту такое решение должен принимать не рядовой разработчик, а midl или кто повыше, с пониманием бизнеса и того как оно в коде реализовано (а у него время не резиновое, его внимания куча вопрос требует). Т.е. человек со стороны, не знакомый с кодом или с не большим опытом, такое не потянет (я про аутсорсеров или джунов например).

Для рядовых разработчиков обычно создают простые правила (например стандарт кодирования принятый в конкретной команде или good practice), как себя вести в какой-то ситуации и DRY мне кажется тут более понятная парадигма (бери то что уже сделано не изобретай велосипед)

Из минусов дублирования кода я вижу такой: прилетит требование поменять бизнес логику, а она вместо одной процедуру размазана по коду. И будут несколько команд делать одно и то же в разных местах и наверняка по разному. И добавят вместо условной одной ошибки в процедуре, N ошибок в разных местах и не факт, что вообще найдут все места, где поменять нужно. Поддерживать такое очень сложно потом.

[Kanut]

Проблемы которые автор затрагивает абсолютно понятны и далеко не новы. А вот выводы которые он делает и пути решeния которые он предлагает…
Лично я бы сказал что есть гораздо более «удачные» подходы к решению этих проблем. Тот же дядюшка Боб с его «Чистым кодом» на мой взгляд предлагает лучшее решение. Но это конечно очень субьективно…