Коротко: грязный код вроде бы работает, но его тяжело развивать и поддерживать; чистота кода — не перфекционизм, а экономия времени всей команды.

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

Тема кажется прозрачной, но многие ею пренебрегают. Зачем вообще нужен чистый код и что это? Раз есть чистый код — значит, есть и грязный. Грязный код выполняет пользовательские сценарии и в целом работает, но создаёт кучу проблем.

Чем опасен грязный код?

  1. тяжело внедрять новый функционал;
  2. тяжело поддерживать уже работающий функционал (даже если он написан месяц назад);
  3. тяжело рефакторить работающий функционал;
  4. тяжело обновлять сторонние библиотеки;
  5. тяжело деплоить приложение в прод;
  6. тяжело вести разработку в команде;
  7. добавление нового функционала несёт большой риск сломать существующий;
  8. стыд перед другими программистами и коллегами.

Что приводит к грязному коду?

  1. Плохое именование переменных вида someDir, a, b, fic, lol, kek — имя должно полностью отражать то, что в переменной находится.
  2. Плохое именование функций и методов вида funcLol() — то же, что и в п.1.
  3. Комментарии в коде — да, это плохо! Хороший код читается легко и не нуждается в комментариях, если выполнены пп.1–2. Если при написании кода возникает желание что-то пояснить комментарием — знайте: ваш код «грязный».
  4. Нарушение принципов SOLID, DRY, KISS, YAGNI, GRASP — это проверенные временем подходы к тому, как писать «нечистый» (хороший) код. Нарушаете их — код «грязный». Да, это уже ближе к архитектуре, но всё же.
  5. Отсутствие строгой типизации функций/методов и свойств классов — значит, вы не уверены, что делает конкретный участок кода, а это ведёт к плачевным последствиям. Строгая типизация — это хорошо и нужно обязательно.
  6. Отсутствие аннотаций — не так критично, как предыдущее, но сильно упрощает жизнь распределённым командам, работающим в разных IDE: все IDE опираются на аннотации и помогают писать код быстрее и чище.
  7. Излишние усложнения там, где они не нужны — не стоит вместо 2 строк рабочего кода писать 20 с фантастическими сценариями.
  8. Несоблюдение PSR-12 — если в команде нет единого стандарта и каждый пишет как хочет, то примерно через месяц и 40 мерж-реквестов продукт «встанет колом», и никто не разберётся, где что написано.
  9. Отладочные функции в итоговой версии кода — это удар по репутации (особенно для IT-компании) и потенциальная дыра в безопасности: по забывчивости можно вывести на экран хост, логин и пароль от БД.
  10. Неиспользуемые методы, классы и целые модули — если не чистить код, рано или поздно вы перестанете понимать, что и как работает, и продукт придётся переписывать с нуля.

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