Главная мысль этой книги в том, что беспорядок в коде редко побеждается одним героическим рефакторингом. Намного чаще система оздоравливается через маленькие структурные шаги, сделанные ровно там, где скоро понадобится менять поведение.
С практической точки зрения здесь особенно полезно разделение на tidying и продуктовую доработку. Из книги удобно брать отдельную уборку структуры, идею structure vs behavior, разговор про coupling и cohesion и экономику маленьких шагов, которые снижают стоимость следующих задач и уменьшают риск регрессий.
Для разговора о техдолге и поддерживаемости это один из самых спокойных и зрелых материалов. По нему легко объяснять, почему иногда сначала стоит расчистить точку изменения, как выбирать разумный размер таких шагов и где полезная уборка превращается в лишний перфекционизм.
Практическая польза главы
Малые улучшения
Показывает, как небольшие структурные шаги регулярно снижают стоимость будущих изменений.
Separate tidying
Учит отделять функциональные изменения от уборки дизайна, чтобы уменьшить риск регрессий.
Экономика решения
Помогает выбирать, когда рефакторинг оправдан, а когда лучше отложить ради скорости поставки.
Interview pragmatism
Дает практичный ответ на вопросы про техдолг и поддерживаемость в реальных командах.
Основной источник
Серия book_cube о книге Tidy First?
5 постов: вводная часть, tidyings, управление изменениями и теория (coupling/cohesion, economics).
Tidy First?: A Personal Exercise in Empirical Software Design (Чистый дизайн)
Авторы: Kent Beck
Издательство: O'Reilly Media, 2023
Объём: ~170 страниц
Книга Кента Бека о small structural changes: tidyings, separate tidying и экономике решений через coupling, cohesion и optionality.
О чем книга и зачем термин tidying
Кент Бек отделяет структурные изменения от поведенческих: сначала делаем код удобнее для следующего шага, потом меняем функциональность. Для этого он использует термин tidying как подмножество рефакторинга.
Центральная идея: дизайн не как академическая теория, а как рабочий инструмент, снижающий риск и стресс при постоянных изменениях в проде.
Оригинал книги доступен на O'Reilly Learning. Русский перевод (издательство Питер): страница книги.
Поведение системы
Что продукт делает для пользователя сегодня. Изменения видны сразу, но их цена может быть высокой при плохой структуре.
Структура системы
Насколько дёшево и безопасно вносить изменения завтра. Эффект не мгновенный, но он определяет скорость команды на длинной дистанции.
Часть I: Tidyings
Автор предлагает множество маленьких техник, которые сами по себе недорогие, но в сумме резко улучшают прозрачность и скорость последующих задач.
Читаемость
- Guard clauses и ранний возврат
- Пояснительные переменные и константы
- Порядок чтения кода и визуальная группировка
Структура
- New interface, old implementation
- Сведение declaration + initialization
- Extract helper и работа с cohesion order
Гигиена
- Удаление dead code
- Нормализация симметрий по всему коду
- Удаление избыточных комментариев
Часть II: Managing
Вторая часть книги про процесс: когда начинать уборку, как не смешивать её с фичами и как выбирать размер изменений.
- Отделяйте tidying от изменения поведения (лучше отдельный MR).
- Планируйте цепочки cleanup-изменений, но останавливайтесь до переусложнения.
- Выбирайте batch size с учётом стоимости review и риска конфликтов.
- Поддерживайте ритм: маленькая регулярная уборка лучше редкой генеральной.
- Если изменения запутались, проще откатить и собрать их заново в правильном порядке.
Часть III: Theory
Structure vs Behavior
Поведение даёт ценность сейчас, структура определяет стоимость и скорость следующих изменений.
Time Value + Optionality
Ранние доходы важнее поздних, но дизайн покупает опцион на будущие изменения.
Coupling и Cohesion
Высокий coupling делает дорогими крупные изменения, а хорошая cohesion уменьшает объём затронутого кода.
Reversible vs Irreversible
Структурные изменения чаще обратимы, продуктовые последствия поведения часто необратимы.
В книге отдельно разбирается мысль, близкая к «равенству Константайна»:cost(software) ~ coupling. Чем выше зацепление, тем дороже крупные изменения.
Практический шаблон применения
До фичи
Сделайте 1-2 tidyings, которые убирают явную боль в точке будущего изменения.
Во время фичи
Держите фокус на поведении, не расширяйте рефакторинг без явной экономической причины.
После релиза
Закройте оставшийся технический хвост небольшим tidy-MR, пока контекст в памяти.
Связанные главы
- Что такое архитектура ПО и зачем она в System Design - даёт системный контекст, в котором tidy-подход выступает как инструмент управления архитектурной стоимостью изменений.
- Clean Architecture (short summary) - показывает, как структурные принципы и границы модулей уменьшают coupling и упрощают эволюцию кода.
- A Philosophy of Software Design (short summary) - расширяет идею снижения сложности через глубокие модули и информационное сокрытие, на которых строится tidy-first мышление.
- Building Evolutionary Architectures (short summary) - добавляет уровень архитектурной эволюции и fitness functions, где небольшие безопасные изменения становятся рабочей стратегией.
- Continuous Architecture in Practice (short summary) - связывает tidy-подход с постоянным потоком решений в проде и практикой incremental architecture.