YAGNI, быстрый провал и техдолг в коде
Дисциплина объёма кода: не писать лишнее (YAGNI), падать рано (быстрый провал), не копить скрытый долг. В культуре кода это уже звучит как KISS/YAGNI — здесь практика и типичные антипаттерны.
YAGNI
You Aren't Gonna Need It — не реализуйте возможности «на вырост», пока нет запроса и теста.
| Антипаттерн | Направление |
|---|---|
| Мёртвый код, закомментированные блоки | Удалить |
| UML «на будущее» вместо кода | Код — источник правды |
| Иерархия с одним наследником | Свернуть |
| Интерфейс с одной реализацией | Убрать лишний слой |
| Паттерн «потому что модно» | Только под задачу |
| «Бизнес-коллекции»-обёртки | Стандартные структуры |
YAGNI не оправдывает отсутствие рефакторинга: вы не строите фичу на год вперёд, но улучшаете то, что уже меняете (правило бойскаутов в статье 1).
Рефакторинг и фича — разные коммиты
Не совмещайте изменение поведения и перестройку структуры в одном непрозрачном PR. Ревьюер должен видеть:
- либо «только поведение» (зелёные тесты на сценарий);
- либо «только структура» (те же тесты, тот же вывод).
Это совпадает с практикой легаси и XP.
Преждевременная оптимизация
Кратко:
- не кэшировать в доменном объекте «на всякий случай»;
- не вводить абстракции «под масштаб», пока нет измерений;
- профилировать, потом менять структуру данных (Кнут, Art of Computer Programming).
Подробнее — производительность выполнения.
Технический долг
Технический долг — отложенная стоимость сопровождения. Типичные формы в репозитории:
| Долг | Почему опасен |
|---|---|
| Код, завязанный на prod-only конфиг | Локально не воспроизвести |
| Вечные TODO/FIXME/HACK | Забытые обязательства |
| Отключённые warnings / не strict mode | Дефекты всплывают в runtime |
| Трекер багов вместо теста | Регрессии возвращаются |
Стратегия:
- Воспроизвести дефект тестом.
- Починить минимально.
- Рефакторить в рамках MAPPER, если зона всё равно трогалась.
Связь с экономикой ПО — 7-13.
Feature flags и сложность
Переключатели функций удобны для релиза, но размножают ветвления. Удаляйте флаги после стабилизации; иначе цикломатическая сложность и когнитивная нагрузка растут годами.
Для тимлида
- Закладывать время на чистку в спринт так же, как на баги (процент или «правило бойскаутов»).
- Метрики Sonar — повод для разговора, не KPI ради зелёного (итоги).
- ИИ-генерация ускоряет черновик — ревью по MAPPER обязательно (5).
Дальше: Тесты и качество, Исключения, Справочник тем.
См. также
Другие статьи этого же раздела в боковом меню (как на странице "О разделе"). Именование, форматирование, комментарии, документация в коде и базовые принципы читаемости — практики, которые команда договаривается соблюдать каждый день. Цикломатическая сложность — одна из наиболее устойчиво применяемых метрик статического анализа программного кода, призванная количественно оценивать логическую структуру исполняемого модуля. Правило MAPPER (Model Abstract Partial Programmable Explaining Reality) — как сопоставлять реальность и код один к одному. Богатые объекты предметной области, value objects вместо string/int и антипаттерны DTO-оргии. const, иммутабельность, ленивая инициализация и побочные эффекты в читаемом коде. Разделение «что» и «как», итерации, магические числа, callback hell и явные ошибки. Меньше if и switch, отказ от null, быстрый провал и полиморфизм вместо флагов. Singleton, god object, shotgun surgery, feature envy и глобальное состояние — симптомы и приёмы рефакторинга. Приватные методы, flaky-тесты, assertTrue, моки и данные — качество тестового кода и связь с разделом тестирования. Пустые catch, исключения как goto, узкие try и сообщения для пользователя. Краткие итоги раздела "Культура кода". Вопросы перед отправкой кода в репозиторий — именование, принципы, тесты, ревью и безопасность. Ответы ищите в статьях раздела.Культура написания и поддержки кода
Цикломатическая сложность и читаемость кода
MAPPER — модель кода и предметная область
Анемичные модели и примитивная одержимость
Изменяемость, побочные эффекты и неизменяемые данные
Декларативный код — что и как
Условия, null и явные контракты
Связанность, глобалы и запахи модульности
Тесты как часть культуры кода
Исключения и обработка ошибок в читаемом коде
Итоги
Чек-лист самопроверки