Почему код может «пахнуть», хотя всё работает
«Запах кода» — не ошибка, которую компилятор обязан обнаружить, а заметный признак того, что программу может быть трудно менять и проверять. Например, один метод делает слишком много, похожие фрагменты размножены по разным местам или несколько условий запутались в длинную цепочку. Каждый такой участок способен выдавать правильный результат сегодня, но его устройство повышает риск ошибок при следующем изменении.
Как подозрение превращается в проблему
Представим, что правила расчёта цены скопированы в несколько частей приложения. Когда правило меняется, разработчику приходится находить и обновлять каждую копию. Если одну пропустить, в разных экранах появятся разные цены. Само дублирование не доказывает, что программа уже работает неправильно; оно показывает, где изменение может стать опасным.
Похожая трудность возникает, когда одна функция одновременно проверяет данные, выбирает бизнес-правило и сохраняет результат. Изменение одного этапа затрагивает остальные, а понять последствия сложнее. Поэтому «запах» — повод разобраться в связях между частями программы, а не автоматический приказ переписать их.
Зачем разработчики ищут такие признаки
Во время рефакторинга — изменения внутреннего устройства без намеренного изменения поведения — подозрительный участок упрощают, разделяют или убирают повторения. Затем проверяют, что программа по-прежнему работает как прежде, например автоматическими тестами. Это снижает цену будущих изменений: вместо нескольких несогласованных правок появляется одно место, где задаётся правило.
Но не всякая необычная конструкция требует переделки. Иногда сложность оправдана конкретной задачей, а рефакторинг сам способен внести дефект. Смысл метафоры в том, что запах помогает заметить накопившееся неудобство заранее: код может быть исправен сейчас, но уже затруднять безопасное развитие программы.
