Есть обычный clean code: понятные имена, маленькие функции, тесты, отсутствие дублей. А есть экстремально чистый код. Это когда ты чистишь всё, что увеличивает когнитивную нагрузку: старые endpoint’ы, поля в DTO, похожие Dockerfile’ы, GitLab CI на тысячу YAML-строк, локальные конфиги и комментарии TODO удалить, пережившие несколько релизов, ребрендинг и двух тимлидов.

Я раньше относился к этому как к косметике. Ну лежит старый кусок кода. Не трогает же никого. Потом несколько раз упёрся в ситуации, где “ненужный” код внезапно увеличивал сложность задачи до нерешаемых размеров.

Что будет в статье:

1. Почему мёртвый код не бесплатный.

2. Что происходит с DTO, когда в него годами складывают “ещё одно поле”.

3. Почему endpoint, который “скорее всего не используется” всё равно страшно удалить.

4. Чем опасны deprecated events ради старого UI и старых отчётов.

5. Почему боятся удалять конфиг-поля, которые “не нужны”

6. Что скрывают забытые Gitlab job’ы

7. Почему фича “на будущее” может стоить дороже, чем кажется.

Погнали.

1. Почему мёртвый код не бесплатный

Самая частая иллюзия: если код не вызывается, он бесплатный.

Нет.

Он компилируется. Индексируется IDE. Попадает в поиск. Его видит новый разработчик. Его учитывают при рефакторинге. Его нельзя сломать при изменении контракта. Его тесты бегут в CI. Его Dockerfile собирается. Его YAML участвует в pipeline.

Даже если фича выключена флагом, код вокруг неё не исчез. Он остался в проекте и продолжает жить вместе с командой.

У нас была обычная backend-система: Scala, Java, HTTP API, база, очереди, контейнеры, адаптеры, отчёты, CI/CD. Ничего экзотического. Просто проект, который прожил несколько лет, клиентов, развороты продукта, миграции UI и несколько поколений инфраструктуры.

Со временем в нём появились слои:

• “это поле вроде больше не используется”

• “этот endpoint, кажется, нужен только старому клиенту”

• “этот event deprecated, но вдруг кто-то слушает”

• “этот compose для локального запуска, а этот для тестов, а этот для старого стенда”

• “этот GitLab job manual и allow_failure, потому что когда-то надо было быстро починить pipeline”

По отдельности всё разумно. В сумме перед каждым изменением ты разбираешься не с задачей, а с историей цивилизации.

2. DTO с кучей хлама

Показательный пример: поле в DTO, которое “можно убрать, если на проде нет таких сущностей”.

case class ServiceDto(
  id: String,
  title: String,
  archived: Boolean = false, // TODO: не используется, если в проде нет архивных сервисов - удалить
  settings: Option[Settings]
)

На первый взгляд: ну и что. Boolean. Один флаг. Но DTO ходит через базу, JSON, DAO, фильтры, тесты и местами наружу. Удаление маленького поля требует проверить данные, миграции, фронт, сериализацию, отчёты и админку.

В shared DTO это растёт ещё быстрее:

case class MessageDto(
  id: Option[String],
  text: Option[String],
  rating: Option[Boolean],        // FIXME: перенести в другую модель
  serviceFlag: Option[Boolean],   // FIXME: вроде не используется, уточнить
  processed: Option[Boolean],     // FIXME: отдельное поле
  context: Option[Json],          // FIXME: отдельное поле
  messageType: Option[String],    // FIXME: в payload
  buttons: Option[Seq[Button]],   // FIXME: отдельное поле
  replyTo: Option[String]         // FIXME: отдельное поле
)

Один FIXME ещё можно пережить. Восемь подряд внутри shared DTO - уже диагноз.

Shared-модель дорогая: её трогает backend, адаптеры, тесты, иногда внешний API. Она может лежать в базе JSON-ом или уже быть скопированной в другой сервис.

Так DTO становится складом ненужных вещей. Можно выкинуть? Наверное. Но вдруг понадобится.

3. Endpoint, который “скорее всего не используется”

В routes нашёлся прекрасный комментарий:

concat(
  // TODO: скорее всего не используется, удалить
  post {
    ...
  },
  // TODO: скорее всего не используется, удалить
  get {
    ...
  }
)

Endpoint нельзя удалить как обычный метод. Нужно проверить:

• есть ли вызовы в UI;

• есть ли внешние клиенты;

• есть ли обращения в access logs;

• не ходит ли туда какой-нибудь cron;

• не используют ли его QA-скрипты;

• нет ли старой мобильной версии;

• нет ли интеграции, которую никто не помнит.

Пока это не проверено, endpoint остаётся. Его поддерживают при изменении auth, не ломают при смене модели ответа, обходят глазами в routes.

Самое обидное: комментарий “скорее всего не используется” создаёт тревогу, но не знание.

Нормальный вариант для такого кода:

1. Завести задачу на удаление.

2. Повесить метрику/лог на endpoint.

3. Подождать разумный срок.

4. Если вызовов нет, удалить.

5. Если вызовы есть, найти владельца и описать контракт.

Иначе TODO становится вечной табличкой на двери.

4. События, которые “можно удалить в будущем”

Классика: событие deprecated, но его держит старый UI или старый отчёт.

// TODO deprecated. Используется только старым UI, можно удалить в будущем
case class UserChangedEvent(...)

publish(event) // TODO: после перехода на новые отчёты этот event больше не нужен

Вот это “в будущем” особенно прекрасно. Старый UI живёт дольше чем планировали. Отчёт вроде заменили, но event всё ещё летит в очередь: его пишут, сериализуют, тестируют, иногда кладут в аналитическое хранилище.

События страшно удалять: их могут читать отчёты, аудит, BI, алерты, внешняя интеграция или забытый месячный скрипт.

Совместимость с прошлым - рабочая история, но только если в этом реально есть потребность. Если старый потребитель нужен, пишем условие поддержки. Если нет - ищем потребителей и удаляем все хвосты.

Иначе вы не заменили механизм, а добавили второй.

5. Конфиг-поля, которые “не нужны”, но живут

В одном config case class были параметры очереди:

case class QueueConfig(
  queueName: String,
  clientId: String,       // TODO: нет необходимости в этом параметре
  maxMessages: Long,
  maxAge: Duration,
  cleanupInterval: Int,   // TODO: нет необходимости в этом параметре
  servers: List[String]
)

Конфиг - не просто класс. Это ещё:

• application.conf;

• env-переменные;

• helm values или другой deploy layer;

• docker-compose;

• тестовые ресурсы;

• README;

• знания DevOps;

• значения в секретнице.

Поэтому удалить config key иногда сложнее, чем метод. Метод найдёт компилятор. Config key может жить в трёх репозиториях и пяти окружениях.

Плохой сценарий: параметр не нужен, но никто не чистит. Новый разработчик ищет clientId, тратит час, понимает что он нигде не используется, но удалить боится.

Ещё хуже: параметр не используется, но его продолжают настраивать в deploy. Ручку крутим, а она давно ни к чему не подключена.

6. Что скрывают забытые Gitlab job’ы

Самый неожиданный хлам часто в CI.

В одном проекте было больше двадцати .gitlab-ci*.yml и сотня с лишним job’ов. Среди обычных build/package/deploy встречались следы конкретных задач.

Например, отдельный deploy для нагрузочного тестирования:

test1__4_load_test:
  extends: .deploy_on_stand
  variables:
    SERVICE_NAME: service1
    CUSTOM_ENV___API_HOST: http://mock-api:6081
  environment:
    name: test1

Сам job нормальный: подняли сервис с mock API, прогнали нагрузку. Проблема после релиза. Нужен сценарий постоянно - делаем расписание, владельца, метрики и место в релизе. Не нужен - удаляем.

Иначе через год разработчик видит 4_load_test и не понимает:

• это всё ещё актуальный нагрузочный стенд?

• его надо запускать перед релизом?

• mock API живой?

• если поменять переменную окружения, что сломается?

Ещё хвост: job под специфичный запуск сервиса.

test1__service2:
  extends: .deploy_on_stand
  variables:
    SERVICE_NAME: service2
    SPECIAL_STORAGE_HOST: "localhost:9181"
  environment:
    name: test1

Возможно, он был нужен для фичи, стенда или эксперимента. Фича вышла, эксперимент закончился, job остался. Теперь он висит в pipeline, попадает в поиск и тормозит изменения deploy-шаблонов.

CI-мусор стоит денег: runner’ы, минуты pipeline, ревью. Но главная цена человеческая: каждый непонятный job заставляет думать “а вдруг важно?”

CI надо чистить как код. Нагрузочные job’ы становятся регулярной практикой или удаляются. Специальные deploy-сценарии получают владельца и описание или уходят из репозитория.

7. Продуктовые “ненужности”: фича на будущее

С кодом проще: можно найти grep’ом, посчитать, завести cleanup таску.

С продуктовыми ненужностями сложнее.

Допустим, есть фича: backend, UI, настройки, права, аналитика, тесты, документация, деплой. Потом выяснилось, что ей никто не пользуется. Или пользуется раз в год. Или продакт говорит: “оставим на будущее”.

Для продакта это выглядит бесплатно: фича уже сделана.

Для команды - нет:

• при изменении модели надо учитывать эту фичу;

• при рефакторинге UI надо переносить её экран;

• при изменении прав надо думать о её permission;

• при миграции БД надо не сломать её таблицу;

• тесты должны проходить;

• документация должна не врать;

• support должен помнить, что она есть;

• новые разработчики должны понять, зачем она нужна.

Что с этим делать

Я не верю в генеральную уборку на месяц. Она проигрывает продуктовой реальности: всем надоедает, приходит срочная фича, cleanup-ветка тухнет.

Работает другое.

1. Четко маркировать кандидатов на удаление

Плохой комментарий:

// TODO удалить

Лучше:

// TODO CLEANUP-123: удалить после 30 дней без вызовов endpoint'а

Ещё лучше: метрика, алерт, дата удаления, владелец.

2. Удалять маленькими партиями

Один PR: один endpoint, config key, Dockerfile-шаблон или deprecated event. Удаление должно быть рутинным. Если cleanup PR страшно ревьюить, он слишком большой.

3. Считать налог

Не “код некрасивый”, а:

• pipeline дольше на 7 минут;

• 15 Dockerfile’ов надо обновлять руками;

• 3 клиента сидят на deprecated endpoint;

• 40 тестов гоняют старый контракт;

• новый разработчик тратит день на local setup.

Числа работают лучше эстетики.

4. Добавлять дату смерти временным решениям

Временный код без даты смерти - постоянный код с плохим названием. Рядом нужно хотя бы что-то:

• условие удаления;

• дата пересмотра;

• метрика использования;

• ссылка на задачу;

• владелец.

Иначе это не workaround. Это новая архитектура, просто плохая.

5. Удалять продуктовые фичи тоже

Это самое сложное. Надо говорить: “фича не используется, но стоит нам X”. Не “разработчики ноют”, а:

• дольше релизы;

• дороже QA;

• больше regression surface;

• больше документации;

• больше поддержки;

• сложнее менять архитектуру.

Продакту не всегда видно, что фича “на будущее” каждый месяц выставляет счёт. Наша задача - показать его.

Финал

Экстремально чистый код - не стерильность и не желание удалить всё. Это дисциплина не хранить вещи без владельца, срока жизни и понятной пользы.

Старый endpoint может жить. Deprecated event может жить. Compose для редкого сценария тоже. Даже костыль может жить, если команда понимает зачем и до какого момента.

Проблема начинается, когда проект становится складом “на всякий случай”. На складе можно работать, просто каждый шаг требует обходить коробки.

Потом мы удивляемся, почему фичи едут медленно. Не потому что команда слабая, язык плохой или архитектура не та. Иногда у корабля просто всё днище в ракушках.

И пора чистить, пока он ещё плывёт.

Если вам близки темы разработки, рефакторинга, архитектуры и стартапов буду рад видеть вас в моём Telegram-канале.

Успешных вам релизов!