Я думаю, вы уже знаете, что такое чистый код. Очень точное определение читабельного кода приведено в известной книге Дяди Боба («Чистый код. Создание, анализ и рефакторинг» Роберта Сесила Мартина). С момента публикации этой книги было много разговоров о Чистом Коде. Люди говорят о мастерстве, о читабельности. Они даже доходят до доработок кода. Если вы публично скажете что-нибудь против чистого кода, вы обнаружите себя в списке «никогда не нанимать».
К сожалению, никто не задается вопросом, есть ли причины, по которым не стоит писать чистый код. Я могу привести несклько.
1. Любой дурак сможет указать на ошибки в коде
Допустим, вы потратили некоторое количество времени и усилий на то, чтобы вычистить свой код. Вы удалили повторы, использовали короткие и содержательные имена, ваши методы легки для понимания. В какой-то момент вы решили, что отполировали его достаточно, выпуск в любом случае станет сенсацией.
Некоторое время спустя коллега глянет на ваш код и укажет на существующие проблемы. Чем больше названий вы используете, тем больше шансов ошибиться. Чем короче ваши методы, тем легче найти дубликаты. Итак, ваш сотрудник просматривает ваш код и говорит вам, как можно его улучшить. Позор, не так ли?
Ничего такого не случилось бы, если бы вы писали запутанный код. В этом случае худшее, что ваш коллега мог бы сказать, это что код грязный. А на это есть прекрасный ответ: “Ну и что? Он же работает!” Чем громче вы это скажете, тем более убедительным это покажется. Никто не найдет баги в вашем коде лишь бегло проглядев его.
2. Вам нравится быть важным
Допустим, вы взяли отпуск на 2-3 недели. Когда вы возвращаетесь, ваши коллеги говорят вам, что пользователь отправил сообщение о баге в вашем коде и они его исправили. Они поведают вам, что благодаря вашим юнит-тестам им удалось факторизовать там кое-что без создания новых багов. После этого они смогли с легкостью исправить ошибку в оригинале кода и выпустить новую версию.
Какие-то странные ощущения, не так ли? Это звучит так, как будто вас вполне можно заменить, и теперь все об этом знают. Этого не должно было случиться. Может, было бы лучше, если бы вас вызвали посреди вашего отпуска, чтобы как можно быстрее исправить этот баг? Сначала это было бы небольшим неудобством, но какая разница? Ваша семья узнала бы, какой вы суперважный высококлассный хакер. А ваши коллеги узнали бы, что если вы уйдете, они могут переписывать ваши модули из черновиков.
Так что же делать, когда вас вызывают в связи с неотложной проблемой? У вас есть варианты:
- Вы можете ласково сказать, что это очень простая проблема, и вы объясните им, как ее исправить. Если этот метод не сработает, вы можете обвинить их в том, что ни вас не так поняли.
- Достаточно часто придется напрягаться и исправлять ошибки самостоятельно.
- Иногда вы можете быть пожестче, в стиле «А без меня вы не можете это сделать?!»В любом случае все будут относиться к вам с глубоким уважением.
3. Вам не нравятся принципы объектно-ориентированного программирования
Эти сокращения вроде DRY или DIP. Если вы загуглите, вы найдете длинные объяснения, в общем-то, ни о чем. Все они говорят, что по неким абстрактным причинам вроде гибкости или модульности вы должны писать более сложный код. Как только вы начнете обращать внимание на эти принципы, ваш код наполнится Шаблонами Дизайна.
Да ладно! Неужели вы позволите этим принципам унять ваше стремление к нешаблонному коду? Вы же знаете, что можете сделать лучше! Вы можете сказать, что эти шаблоны вносят ненужную сложность в ваш код. Если кто-нибудь спросит, почему у вас 7 почти идентичных вариантов блока кода при 3 методах, вы всегда можете ответить: «Так вы можете легко видеть течение: один шаг после другого». Чем чаще вы это говорите, тем более убедительным это становится.
4. Вы хотите создавать рабочие места для других
Вы знаете, что в глубине души вы настоящий альтруист. Когда вы пишете код, вы не собираетесь беречь деньги основателей компании. Вы хотите, чтобы они наняли больше тестировщиков и инженеров программного обеспечения чтобы понять ту вещь, которую вы создали. Что может быть достойнее создания рабочих мест и головоломок для других людей?
А есть настоящие причины, по которым не пишется чистый код?
Ладно, давайте оставим шутки в стороне. Есть ли причины для того, чтобы не писать чистый код? С тем же успехом можно спросить, есть ли причины для написания грязного кода. Ответом будет жирное «нет». Тем не менее чистота кода это не булево выражение 0/1, это скорее шкала от 0 до 1. Я думаю, есть случаи, в которых нет необходимости писать уж очень чистый код:
1. Вы не умеете писать чистый код
Собственно, это одна настоящая причина. Скажем, вы хотите научиться писать чистый код. Вы полны энтузиазма, но воспринимаете все слишком буквально. Тогда вам не стоит приниматься за написание чистого кода немедленно. Если вы попытаетесь применить все техники из книги Дяди Боба, в итоге вы получите худший код из когда-либо написанных вами. Я советую изучать и использовать их по одной. Когда вы доведете применение какой-то техники практически до автоматизма, можете приниматься за следующую. Вы начнете писать потрясающий код гораздо раньше, чем думаете.
2. Вы в критическом положении
Это тоже вполне вероятно. Иногда такие положения бывают. Возможно, в вашем продукте есть баг, и компания теряет сотни тысяч долларов ежедневно, пока он не устранен.
Я сомневаюсь, стоит ли включать сюда случай, когда вы работаете над стартапом и должны выпустить что-то раньше ваших конкурентов. Я сомневаюсь, потому что вы можете сэкономить кучу времени выбрав инструменты для быстрой разработки приложений (RAD). Какое-то время вы можете сэкономить (и заполучить много багов) путем отказа от разработки через тестирование (TDD). Хотя стартапы и не могут тратить время на очень чистый код, написание кода с багами также не поможет делу.
По какой бы причине вы ни оказались в критическом режиме, меньшим злом будет продвижение вперед и последующее исправление ошибок. Главное, не забудьте позже убрать беспорядок.
***
Подписывайтесь на наш канал в Telegram
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]