Кажется, все сейчас стремятся к «чистому» коду. Нет почти ни одной статьи в блогах, где автор не скажет о том, насколько «чист» его подход. Команды собираются обсудить, какое из возможных решений самое чистое. Разработчики вокруг заверяют, что практикуют «чистый код».
Тем не менее, я осознал: нет такого понятия — чистый код.
Чистотой невозможно измерить что-то полезное. Код просто не может быть «чистым», ведь «чистота» просто не говорит ничего об этом коде.
Какой лицемер!
Меня тоже можно обвинить в том, что раньше я неоднократно использовал термин «чистый». Хочу также заметить, что не ставлю целью принизить тех, кто использует это понятие.
Как маркетинговый термин или описание видения, «чистый» подходит прекрасно, но как у технического определения тут есть ряд проблем…
Чистый код — хороший код, верно?
Когда кто-то говорит про чистый код, то обычно они имеют ввиду, что он хороший.
Дело в том, что хорошим код может быть по нескольким причинам:
Читабельный
Понятный
Простой
Быстрый
Безопасный
Элегантный
Легко тестируемый
Инкапсулированный
Масштабируемый
Легко поддерживаемый
Переиспользуемый
Легко удаляемый
Чистый и аккуратный
Независимый
Систематичный
Консистентный
и любой другой набор признаков
Все эти признаки в некотором роде противоречат друг другу. Самый простой код, скорее всего, сложно тестировать. Множество интерфейсов и вложенных зависимостей упрощают тестирование, но делают код сложнее.
Сильная зависимость от синглтонов позволит упростить понимание, но такое приложение сложнее обслуживать.
Если вы активно используете синглтоны, то они, возможно, и упрощают понимание, но также могут усложнить поддержку приложения.
На самом деле, можно сказать, что некоторые из этих признаков прямо противоречат другим и они не могут быть удовлетворены одновременно. Разработка — это компромиссы, и, чтобы обсуждать их в команде, все должны иметь представление о них.
Если код хороший, то мы должны объяснить почему
Когда кто-то говорит о «чистом» решении, то обычно представляет его как наилучшее, не объясняя почему.
Для конструктивного диалога о технических решениях мы должны быть в состоянии объяснить, почему одно решение лучше другого. Неправильно спорить о том, какой подход «чище», будто есть некий чистомер для измерения этой загадочной меры.
На самом деле, довольно сложно объяснить, почему вот это решение лучше или хуже другого, но такой навык необходимо оттачивать.
Вы бы предпочли диалог в таком формате?
Мне нравится решение X, потому что оно кажется «чище»
Или в таком?
Мне нравится решение X. В этом случае разделяется основная логика и обработка ошибок. Его проще понять, потому что не приходится разбираться одновременно с и с тем и с другим. Разделение также упрощает тестирование, позволяя замокать один объект на время тестирования другого. Конечно, для этого родительскому объекту придётся вводить зависимости, но это допустимый компромисс ради упрощения тестирования.
Второй аргумент указывает на плюсы и минусы обсуждаемого подхода, а вот такой термин как «чистота» лишь отговорка, чтобы не практиковаться в умении формулировать свои идеи.
Мы должны использовать точные термины
Программирование, как правило, командная игра. Если вы работаете в одиночку, то можете делать всё, что хотите, но работая в команде нужно обсуждать свои идеи. Иметь возможность дискутировать о технических решениях, говоря на точном языке, когда у команды единое понимание терминов — бесценно для взаимопонимания.
«Чистый код» имеет разное значение для каждого.
Для одних разработчиков код чистый, потому что в нём прослеживается чёткая архитектура. Для других — просто потому, что он оформлен по оговорённым стандартам.
Такие понятия, как «инкапсулированый», «тестируемый», «переиспользуемый» или «мокабельный» имеют единое значение для всех нас. Когда мы используем точные термины для описания кода, то можем быть уверены, что все остальные правильно нас понимают.
Понятие «чистый» настолько же точное, насколько «хороший». Вы можете говорить, что код чистый или хороший, но всё это не отменяет необходимости объяснить свою позицию конкретнее.
Так что такое чистый код?
Я пришёл к выводу, что чаще всего, когда мы говорим «чистый» код, то считаем его хорошим, но не можем объяснить почему. Нам просто кажется, что это правильное решение.
Или иногда мы знаем, что этот код хороший, но не в состоянии сформулировать почему, а потом в конце статьи своего блога пишем: «Просто посмотрите, насколько стало чище!»
Конечно, здорово развивать хорошую интуицию, но этого недостаточно. Необходимо копнуть глубже, понять и сформулировать, почему мы считаем этот код хорошим. Какие качества выделяют его среди других решений? Насколько эти качества важны в нашем проекте? Может оказаться и так, что это не самое лучшее решение.
Надеюсь, я смог убедить вас в том, что вам нужен не чистый код, вам нужен ________ код. Просто подставьте те определения, что лучше подходят вашему проекту.
