Комментарии 15
Конспект хороший, но книга интересней :)
Не все догмы чистого кода стоит использовать.
Не все догмы чистого кода которые стоит использовать стоит использовать всегда.
Все догмы чистого кода которые всё-же используете стоит использовать с умом, оглядкой и в согласовании с командой.
Чистый код и похожие методики надо внедрять на уровне код-ревью и стандартов программирования в проекте/программе.
Не все догмы чистого кода которые стоит использовать стоит использовать всегда.
Все догмы чистого кода которые всё-же используете стоит использовать с умом, оглядкой и в согласовании с командой.
Чистый код и похожие методики надо внедрять на уровне код-ревью и стандартов программирования в проекте/программе.
В самом начале книги Мартин пишет о субъективности своего же подхода. Это его видение этих вопросов, которое он назвал «Школой Чистого кода».
НЛО прилетело и опубликовало эту надпись здесь
Ну вот, например, можно использовать один switch, а можно сбацать фабрику с абстрактными методами и реализовать их в подклассах. И всё это только ради того, что switch в коде нам глаз мозолит и «нарушает принципы». Из одной функции мы получаем несколько классов. Я бы подумал над разумностью плодить ещё несколько классов в проекте, где их и так тысячи. Здесь 3 класса, там еще 10… и так для каждого switch. О скорости сборки, производительности и даже банальной навигации по исходникам тоже не стоит забывать (я сейчас не только про этот случай).
А как вы себе представляете внедрение этих методик на уровне код-ревью?
Большая часть принципов, описанных здесь, являются лишь симптомами проблем, связанных с неправильным выбором архитектурных решений.
Методы больше 20 строк, switch операторы, наличие или отсутствие контекста — все это следствие неправильно выбранных границ модулей или неправильный абстракций.
Так может на код-ревью лучше следует смотреть на правильность реализации бизнес логики и правильность выбора архитектурных решений, а не на эти принципы?
Если подходить к этим принципам, как к симптомам возможных проблем, то их можно использовать, но использовать их в код ревью как аргументы, я бы не стал.
Конечно можно на уровне команды вынести конвенции по именам классов, методов, переменных и т.п., польза от этого правда очень незначительна. Хотя, если это конечно поможет не называть переменные
a1, a2 и т.п., то уже хорошо.
Так же некоторые принципы можно отнести к странным решениям:
Большая часть принципов, описанных здесь, являются лишь симптомами проблем, связанных с неправильным выбором архитектурных решений.
Методы больше 20 строк, switch операторы, наличие или отсутствие контекста — все это следствие неправильно выбранных границ модулей или неправильный абстракций.
Так может на код-ревью лучше следует смотреть на правильность реализации бизнес логики и правильность выбора архитектурных решений, а не на эти принципы?
Если подходить к этим принципам, как к симптомам возможных проблем, то их можно использовать, но использовать их в код ревью как аргументы, я бы не стал.
Конечно можно на уровне команды вынести конвенции по именам классов, методов, переменных и т.п., польза от этого правда очень незначительна. Хотя, если это конечно поможет не называть переменные
a1, a2 и т.п., то уже хорошо.
Так же некоторые принципы можно отнести к странным решениям:
- Вместо assertEquals использовать assertExpectedEqualsActual
- Изолировать блоки try/catch
- Использовать префиксы get/set
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
«Чистый код» Роберт Мартин. Конспект. Как писать понятный и красивый код?