(Не)чистый код.
Как и обещал, для начала немного теории.
Проблема написания «хорошего» кода настолько стара, что, думая о ней, поневоле начинаешь использовать возвратные местоимения и побольше союзов. Как в Ветхом завете
И собрал я джунов своих, И увидел я код их,
И пиздил оных за ошибки, совершенные ими.
И передал им паттерны свои.
И сказал я: это хорошо
Книга Дядюшки Боба 1.01.01
🔴В АБЗАЦЕ НИЖЕ ЕСТЬ ДОЛЯ ШУТКИ🔴
Вообще, не «чистый код» - не такая уж проблема, если подумать. Знаете, почему Мартин выбрал прилагательное «чистый», а не «правильный»? Да потому что «грязный» код – тоже будет работать, и вполне себе правильно.
Чистый код – это прежде всего легко читаемый, изменяемый и масштабируемый код. Нечистый код тоже может быть оптимальным с точки зрения выполнения своей прямой функции. Но при этом разобраться в нём, не говоря уж про какое-то сопровождение будет очень тяжело.
За чистоту кода отвечают, преимущественно, 3 философских принципа, которыми неплохо руководствоваться и в жизни
👉KISS – Keep It Simple Stupid – призывает нас не быть сложнее, чем необходимо. Один метод – одна задача. Небольшие методы. Логичные имена переменных. Переиспользование. Всё это берёт начало с каких-то дремучих годов, а сам акроним был придуман проектировщиком военных самолетов из Lockheed.
👉BDUF – Big Design Up Front – известное всем русскоязычным людям с детства как «Семь раз отмерь - один раз отрежь». Думаю, даже пояснять не надо.
👉YAGNI – You Aren’t Gonna Need It – А оно тебе точно, бля@ть, надо? И самой близкой аналогией здесь будет бритва Оккама. Главное, не применяйте его слишком широко, а то можно задуматься, а нужна ли Вам вообще работа, семья…
Помимо этих, есть еще прямо или косвенно следующие из предыдущих принципы
👉DRY – Don’t Repeat Yourself – про недопустимость дублирования кода с одинаковой функциональностью
👉GIGO – Garbage In Garbage Out – про требования к валидации входящих данных. Да-да, это именно та история, когда мы, работая, к примеру, с персданными сотрудников должны проверять дату рождения (неплохо было бы, ограничивать её хотя бы XIX веком снизу и текущей датой сверху)
👉LIAR – Leave, Its Already Ready – Отъебись, и без тебя работает. В целом понятно, что имеется в виду: не стоит переделывать что-либо, с чем ты не согласен до конца, если не знаешь точно, нахрена оно сделано именно так.
Венцом всего это считается сугубо практический принцип проектирования – да, именно он – SOLID, что тоже является аббревиатурой
➡️S – Single – принцип единственной ответственности. То самое «один метод/класс – одна задача»
➡️O – Open/Close – открытость для расширения, но закрытость для модификации (расширять функционал можно, изменять контракт входящих/исходящих данных нельзя)
➡️L – принцип подстановки Барбары Лисков – про полиморфизм и наследование
➡️I – требование к специализации интерфейсов, хороший интерфейс – узконаправленно решающий определенную задачу, плохой интерфейс – принуждающий посетить группу анонимных наркоманов при бронировании поездки на Марс. Для не разработчиков, интерфейс – это не только куда тыкать, это еще и место взаимодействия между частями системы.
➡️D – Dependency – про вертикальные зависимости (более высокоуровневый модуль не должен зависеть от более низкоуровневого для 1Сников – не допускается вызов из модуля менеджера метода из модуля формы), уменьшение связности, увеличение гибкости и отграничивание от несущественного.
Практическим результатом влияния всего этого на код являются уже паттерны программирования – всякие фабрики, наблюдатели, стратегии и прочая… Но главное – если Вы будете следовать этим принципам – Вы интуитивно будете применять паттерны, даже не зная их.
Если подход к чистому коду основан на определенных принципах, то подход к «грязному» - исключительно на человеческой лени и тупости. И поэтому имя им – легион. Всеми любимые спагетти, пиццы, равиоли, говнокод, китайский код и еще куча различных моделей. Погружаться я в них не особо хочу – все-таки рука уже соскальзывает с воображаемой границы сообщения. Да и зачем? Вы всё это умеете и без моих объяснений.
#медвежийкодстайл
