Комментарии 15
Спасибо. Я, естественно, не считаю, что мой конспект лучше книги Мартина ) Она же своего рода классика. Вдруг кто-то не читал ее, а прочитав конспект решит это сделать.
Для новичков обязательно нужен контекст, а в конспекте этого нет. А для тех кто в теме, это очевидные вещи.
Не все догмы чистого кода стоит использовать.
Не все догмы чистого кода которые стоит использовать стоит использовать всегда.
Все догмы чистого кода которые всё-же используете стоит использовать с умом, оглядкой и в согласовании с командой.
Чистый код и похожие методики надо внедрять на уровне код-ревью и стандартов программирования в проекте/программе.
В самом начале книги Мартин пишет о субъективности своего же подхода. Это его видение этих вопросов, которое он назвал «Школой Чистого кода».
Ну это я так.
Напомнить просто, что к любым таким рекомендациям надо подходить с умом, а не слепо. =)
Да и в статье об этом не написано.
Не все догмы чистого кода стоит использовать.

Вот напримере этого конспекта скажите какие не стоит использовать?
Ну вот, например, можно использовать один switch, а можно сбацать фабрику с абстрактными методами и реализовать их в подклассах. И всё это только ради того, что switch в коде нам глаз мозолит и «нарушает принципы». Из одной функции мы получаем несколько классов. Я бы подумал над разумностью плодить ещё несколько классов в проекте, где их и так тысячи. Здесь 3 класса, там еще 10… и так для каждого switch. О скорости сборки, производительности и даже банальной навигации по исходникам тоже не стоит забывать (я сейчас не только про этот случай).
Ну так и написали бы, что одну догму из списка не стоит использовать.
Да и не догма это вовсе. Применив слово догма вы уже начали не корректно.

На самом деле большинство наших программистов — самоучки, и поэтому с трудом принимают такие практики, о которых говорит дядя Боб. Но одни это понимают и перенимают и стараются учиться. А другие не могут, и ищут оправдания своему консерватизму.
А как вы себе представляете внедрение этих методик на уровне код-ревью?
Большая часть принципов, описанных здесь, являются лишь симптомами проблем, связанных с неправильным выбором архитектурных решений.
Методы больше 20 строк, switch операторы, наличие или отсутствие контекста — все это следствие неправильно выбранных границ модулей или неправильный абстракций.
Так может на код-ревью лучше следует смотреть на правильность реализации бизнес логики и правильность выбора архитектурных решений, а не на эти принципы?
Если подходить к этим принципам, как к симптомам возможных проблем, то их можно использовать, но использовать их в код ревью как аргументы, я бы не стал.

Конечно можно на уровне команды вынести конвенции по именам классов, методов, переменных и т.п., польза от этого правда очень незначительна. Хотя, если это конечно поможет не называть переменные
a1, a2 и т.п., то уже хорошо.

Так же некоторые принципы можно отнести к странным решениям:
  1. Вместо assertEquals использовать assertExpectedEqualsActual
  2. Изолировать блоки try/catch
  3. Использовать префиксы get/set

Кстати у Роберта Мартина есть еще замечательный видео урок на 35 часов. Так и называется — Clean Code. Это очень познавательное произведение созданное с юмором и любовью.
Он там сам изображает разных персонажей, говорит разными голосами. Одевается в разные костюмы. Ему помогают его дети и внуки. Монтаж уморительный. Ну и темы раскрывает отлично. Когда я смотрел его видео, я не мог оторваться. А мои домочадцы крутили пальцем у виска.
Всем кто не смотрел — рекомендую. Получите истинное наслаждение.

Русского перевода нету. Если кто переведет качественно — сделает благое дело.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.