[Перевод] В чём разница между хорошим и плохим кодом? Объяснение для непрограммистов
Однажды я где-то прочитал цитату, имевшую приблизительно следующий смысл:
«Жизни многих людей в современном мире зависят от программного обеспечения, например, оно контролирует системы управления большими коммерческими авиалайнерами. Тем не менее, сфера разработки ПО практически никак не регулируется. Любой может стать разработчиком-самоучкой, при этом нет никаких сертификаций или правил, как в других профессиях с высокими ставками, например, в архитектуре или нейрохирургии. Это угрожающе нерегулируемая сфера, хотя несколько строк плохого кода могут привести к смерти».
Кажется, это заявление я прочитал в каком-то крупном СМИ. Статья называлась примерно так: «Опасайтесь плохого кода, он может вас убить; хотя постойте, он невидим, так что не стоит беспокоиться!». Весьма успокаивающее послание для читателей, как считаете? Сейчас я думаю, что авторы статьи просто пытались создать сенсацию из наличия таящегося «плохого кода» в авиалайнерах, поездах и беспилотных автомобилях, которых становится в нашем обществе всё больше, и таким образом увеличить количество просмотров.
Я пишу код, анализирую код и выполняю рефакторинг кода (то есть переписываю его более чётким и удобным образом) примерно по пять часов в день, поэтому знаю, что такое код (и что такое плохой код!). Иногда я забываю о том, что многие люди не имеют понимания о том, что же такое код.
Для таких людей я представлю ответ на вопрос: «Если вы кодер, то чем вы занимаетесь?»
«Я создаю крошечные системы из небольших дверей, которые открываются и закрываются разным образом и в разных конфигурациях. Когда дверь открывается, через неё могут пройти электроны, а когда она закрывается, путь электронам заблокирован. Так как дверцы слишком малы, чтобы изготавливать их вручную, их за меня собирает компьютер. В зависимости от слов, которые я вбиваю в компьютер, он создаёт за меня различные типы таких маленьких дверей».
Да, действительно, как и сказано в данном ответе, разработчики ПО/кодеры/программисты на самом деле создают вещи, имеющие физическую форму, но слишком маленькие, чтобы их разглядеть (однако их можно представить как системы или наборы небольших дверей). Само по себе это достаточно безумно, но если вы, по крайней мере, представите это, то получите концептуальное представление о том, что же такое «кодинг». Поздравляю! Однако вернёмся к вопросу в заглавии: «Что же такое плохой код?»
В рамках нашей аналогии крошечных систем из небольших дверей можно сказать, что плохой код — это когда у вас есть слишком много дверей, выстроенных чрезмерно повторяющимся или сложным образом.
Так как дальнейшее объяснение на примере дверей будет затруднительным, я воспользуюсь другой аналогией.
Допустим, нам нужно изготовить устройство для поворота ручки двери. Ручку, которая может поворачиваться и в свою очередь поворачивать другую ручку на расстоянии. Требования к изделию показаны ниже. Поворачиваем одну ручку, и другая ручка на некотором расстоянии тоже поворачивается:
Это и есть нужная нам система — ручка, поворачивающая другую ручку.
Плохой код думает только об имеющейся задаче и предлагает простейшее решение — ручка и устройство для её поворачивания, соединённые полугибким рычагом. На этом начальном этапе плохой код выигрывает премию бритвы Оккама. Хороший код поначалу кажется переусложнённым, в нём используется резиновый ремень и два колеса.
Одно победное очко плохому коду! Он прост и в нём меньше подвижных деталей!
Как всегда происходит в цикле разработки, на определённом этапе требования клиента меняются. В нашей аналогии клиент теперь хочет, чтобы устройство поворота ручки находилось впереди и сбоку от исходной ручки, как показано ниже:
Упс! Требование к продукту изменилось!
В плохой код нужно добавить несколько собранных из подручных материалов компонентов, что делает всю систему менее устойчивой и подверженной сбоям. При появлении новых требований в хорошем коде нужны только незначительные изменения; для решения этой проблемы просто используется резиновый ремень подлиннее.
Плохой код становится соединением неустойчивых компонентов…
Теперь наш клиент решил, что ручки должны поворачиваться с разной скоростью. Небольшой поворот входной ручки должен приводить к сильному повороту соединённой с ней ручки.
В свете этого нового требования, плохой код должен добавить в систему дополнительные компоненты, что ещё больше усложнит его. С другой стороны, в хорошем коде требуется лишь небольшое изменение: поставить со стороны присоединённой ручки колесо побольше:
Две вставки и рычаг смешной формы? Кто тебя будет поддерживать, плохой код?
Как показано выше, если требования просты, хороший код часто кажется излишне сложным, но он по-настоящему проявляет себя при изменении требований клиента (которые бывают всегда). Иными словами, он хорошо масштабируется и изменяется. С другой стороны, плохой код кажется простым и отличным для простых задач, но превращается в кошмар, когда система меняется или повышает свою сложность.
Впрочем, возможно, вы думаете: «Ну, обе описанные системы достигают одного результата: устройство для поворота ручки успешно работает и в том, и в другом случае».
Это правда, и вполне подходит для соло-кодинга и хобби-проектов. Одному богу известно, что я написал десятки тысяч строк плохого кода (в моём случае на ванильном JS), но это было нормально, потому что мне никогда не приходилось поддерживать этот код и добавлять в него что-то новое (зацените эти 2422 строки исходного кода www.python-gui-builder.com, одного из моих хобби-сайтов, написанного в 2020 году). Код работал и я его развернул, а потом никогда больше не возвращался к нему.
Однако профессиональный кодинг — это по своей сути совместный труд, и любой написанный вами код совершенно точно постоянно будут читать и изменять другие кодеры, в настоящем или будущем. Рабочий день этих кодеров будет гораздо проще и эффективнее, если код максимально прост в понимании.
- «Вот устройство для поворачивания ручки, оно состоит из двух колёс и ремня», или
- «Это вставка для удерживания соединительного рычага, вот соединительный рычаг, его конец нужно вставить в небольшое отверстие здесь, в этой маленькой вставке…»
Какое описание бы вы предпочли, работая джуниор-разработчиком и получив кодовую базу от своего сеньора?
