[2/5] Чистый дизайн (Tidy First?) (Рубрика Architecture)
Продолжая первый пост о книге "Чистый дизайн" расскажу для начала про первую часть, в которой автор рассказывает о концепции небольших изменений, которые делают код проще. Причем здесь мы меняем структуру софта, а не его поведение. Автор говорит, что это напоминает рефакторинг и tidyings - это подможество рефакторинга. Отдельный термин появился потому, что рефакторингом теперь часто называют и те измения, что меняют поведение программы, а автор это хочет четко отделить.
В итоге автор предлагает следующие подходы
- Охранные выражения (guarding clauses) - вынос в начало функции начальных выражений, которые надо учитывать и ранний возврат при их наступлении из функции
- Мертвый код (dead code) - его просто надо удалить (если он понадобится, то его можно будет восстановить из системы контроля версий)
- Нормализация симметрий (normalize symmetries) - если кратко, то надо использовать консистентные подходы по всему коду, например, подход к определению и инициализации переменных. Тут могут помочь линтеры или подходы к readability, как в Google (про которые я писал раньше в посте про measuring engineering productivity)
- Новый интерфейс, старая реализация (new interface, old implementation) - при реализации изменений мы можем определить новый красивый интерфейс и всех перевести на него, а поначалу под капотом дергать вызов старой реализации. На самом деле это дефолтный подход при миграциях:)
- Порядок чтения кода (reading order) - файл с кодом должен быть устроен так, чтобы его было удобно изучать читателю (забавно, что это верно для всего: книг, презентаций, мануалов)
- Принцип связности (cohesion order) - суть в том, чтобы организовать код в файле так, чтобы при изменениях элементы, что меняются вместе, распологались рядом. Это же верно и для разных файлов, что сцеплены (coupling) - их можно перенести в общий каталог.
- Соединение объявления переменной и его инициализации (move declaration and initialization together) - опять же тут суть в том, чтобы свести связанные кусочки логики вместе
- Пояснительные переменные (explaining variables) - создание отдельных переменных для сложных выражений вместо вычисления их just in place, например при прокидывании выражения в параметры вызываемой функции
- Пояснительные константы (explaining constants) - создание констант вместо раскиданных по коду магических значений
- Явная передача параметров (explicit parameters) - вместо прокидывания hashmap с ненормированным количеством параметров лучше их явно прокинуть в параметры при вызове функции
- Визуальная группировка инструкций (chunk statements) - если при чтении кода вы понимаете, что одна часть делает вот это, а другая делает то, то просто добавьте дополнительную пустую линию между этими блоками кода, плюс этот блоки кода можно улучшать при помощи остальных советов из этой части
- Извлечение функций-хелперов (extract helper) - извлечение вспомогательных блоков кода в отдельные функции с именем
- Одна большая свалка (one pile) - во время очистки иногда требуется свести все части кода в одно место, а уже потом применять остальные подходы. Когда мы делаем так, то получаем одну большую свалку.
- Содержательные комментарии (explaining comments) - если при чтении куска кода у вас щелкает и возникает мысль "Ах, вот что это такое", то есть смысл записать это озарение в комментарий
- Удаление избыточных комментариев (delete redundant comments) - иногда при очистке кода часть комментариев становится очевидной, в этот момент такие комментарии стоит удалить.
#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture