Грязный код

Хочу поговорить о казалось бы прозрачной теме, но несмотря на ее прозрачность - многие ею пренебрегают по тем или иным причинам.

Зачем нам вообще нужен чистый код и что это такое?

Вообще какой код сам по себе бывает? Если есть чистый код - значит есть и грязный. Суть у этой всей истории одна.

Такая терминология подразумевает определенное состояние качества кода, когда он выполняет зелёные сценарии пользователя, не отбрасывает критических ошибок и в целом то работает, НО при этом имеет ряд существенных проблем, которые мы как раз и рассмотрим.

Какие проблемы вызывает грязный код простыми словами:
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 мерж реквестов - ваш продукт встанет колом и никто не сможет разобраться где что и как написано - и это еще в том случае, если продукт доживет до такого количества выполненных задач без неразруливаемых конфликтов на уровне git.

9) наличие отладочных функций в итоговой версии кода - помимо того, что это удар по репутации компании, особенно если это it-компания - так это еще и потенциальная дыра в безопасности it-sec, потому что по забывчивости можно вывести на экран например хост, логин и пароль от БД. Уверен не стоит пояснять почему это плохо.

10) код содержит неиспользуемые методы, классы, или даже целые модули - если не заниматься чисткой кода и оставлять неиспользуемые функции и классы - то рано или поздно вы просто не сможете разобраться что и как работает и продукт придется переписывать с нуля.