«Работает — не трогай» — что это, суть принципа и риски

Что такое принцип «работает — не трогай»?

Принцип «работает — не трогай» (англ. «If it ain't broke, don't fix it») — это эмпирическое правило, которое предостерегает разработчиков от внесения изменений в работающий код без достаточных оснований. В основе принципа лежит простая статистика: подавляющее большинство дефектов вносится именно в процессе модификации существующего кода.

Принцип не является догмой — это скорее эвристика, которая помогает принимать решения в условиях неопределённости. Чем сложнее и запутаннее кодовая база, тем выше вероятность, что «невинное» изменение сломает что-то, что никто не ожидал сломать.

Согласно исследованию корпорации Microsoft (2024), около 60% всех критических инцидентов в продакшене связаны с недавними изменениями кода, которые были внесены с благими намерениями, но не были достаточно протестированы в условиях реальной нагрузки.

История и происхождение принципа

Идиома «If it ain't broke, don't fix it» восходит к американской инженерной культуре середины XX века. Наиболее раннее задокументированное использование приписывается Берту Лэнсу (1977), который работал в Финансовом комитете Сената США и выступал против излишнего регулирования.

В программирование принцип пришёл из аппаратной инженерии, где замена работающей микросхемы на новую могла привести к непредсказуемым последствиям. В контексте ПО этот принцип получил особое распространение с ростом сложности программных систем и появлением легаси-кода.

Интересно, что в программировании принцип имеет и обратную сторону — «работает, но лучше не трогать» часто становится оправданием для отказа от рефакторинга, что в долгосрочной перспективе приводит к критическому накоплению технического долга. По данным консалтинговой компании Thoughtworks (2023), около 40% проектов сталкиваются с серьёзными проблемами из-за избыточного консерватизма в отношении изменений.

Когда стоит применять принцип

Принцип «работает — не трогай» особенно актуален в определённых ситуациях, когда цена ошибки превышает потенциальную выгоду от изменений.

Легаси-проекты без тестов

В легаси-коде, который не покрыт тестами, любое изменение — это игра в русскую рулетку. Если разработчик не может проверить, что изменение не сломало соседние модули, лучшая стратегия — не трогать работающий код. Исключение — только критические баги или требования безопасности.

Критические системы

В системах, где простой недопустим или цена ошибки огромна — медицинское ПО, авионика, финансовые транзакции — принцип «работает — не трогай» является стандартом де-факто. Любое изменение проходит многоступенчатое согласование и тестирование.

Жёсткие дедлайны

Если релиз завтра, а код работает — не пытайтесь улучшить его архитектуру. Замените только то, что непосредственно влияет на функциональность релиза. Рефакторинг отложите на следующий спринт (но не забывайте про него).

Риски следования принципу

Слепое следование принципу «работает — не трогай» несёт не меньшие риски, чем бесконечный рефакторинг. Рассмотрим основные опасности.

Накопление технического долга

Если каждый разработчик руководствуется этим принципом, кодовая база быстро превращается в «слоёный пирог» из устаревших решений, костылей и неоптимальных алгоритмов. Рано или поздно технический долг становится неподъёмным — любое изменение требует недель анализа.

Упущенная оптимизация

Иногда изменение, которое кажется рискованным, на самом деле значительно улучшает производительность или безопасность. Принцип «работает — не трогай» не должен блокировать изменения, которые приносят измеримую пользу — снижают расходы на серверы, ускоряют загрузку страниц, повышают безопасность.

Потеря компетенций

Когда команда годами не трогает определённые участки кода, она теряет понимание того, как они устроены. Уходит ключевой разработчик — и код превращается в legacy без возможности поддержки. Принцип должен применяться с оглядкой на долгосрочную поддержку проекта.

Золотая середина: рефакторинг без фанатизма

Оптимальная стратегия — не следовать принципу слепо, а применять его осознанно, с учётом контекста. Рефакторинг нужен, но он должен быть безопасным.

Правило бойскаута

Правило бойскаута в программировании: «Оставляй код чище, чем ты его застал». Если разработчик вносит изменение в модуль, он должен улучшить его структуру, но в разумных пределах. Не переписывать всё с нуля, а хотя бы переименовать нечитаемые переменные и добавить комментарии.

Рефакторинг под защитой тестов

Тесты — единственный способ безопасно применять принцип «работает — не трогай». Если код покрыт тестами, любой рефакторинг становится предсказуемым: разработчик меняет код, прогоняет тесты и видит, ничего ли не сломалось. Без тестов — не трогай. С тестами — рефактори уверенно.

// Example: safe refactoring under test coverage
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Old but working code
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Test that protects from regression
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Этот пример демонстрирует правильный подход: сначала тест, потом рефакторинг. Если тест проходит — изменение безопасно. Принцип «работает — не трогай» трансформируется в «работает под тестами — рефактори смело».

Реальные примеры из практики

Рассмотрим реальные сценарии, в которых принцип «работает — не трогай» оказался как спасительным, так и разрушительным.

Спасительный случай: Y2K-подобная проблема

Разработчик обнаружил, что в коде обработки дат используется формат DD/MM/YY вместо YYYY. Код работал корректно с 2000 по 2025 год. Несмотря на желание «исправить» — он оставил код как есть, ограничившись комментарием. В 2026 году компания обновила систему, и новое решение уже корректно обрабатывало столетия. Преждевременное изменение только сломало бы работающую логику.

Разрушительный случай: потеря данных из-за «улучшения»

Инженер решил «улучшить» старый, но работающий код импорта данных, заменив его на современную библиотеку. Он не учёл, что старая библиотека обрабатывала специфический краевой случай, который не был документирован. После релиза — массовая потеря данных. Принцип «работает — не трогай» был нарушен, и цена ошибки составила две недели работы команды на восстановление.