Зачем писать чистый код, если мои программы работают?

Этот вопрос возник в моей голове уже через несколько месяцев работы на проекте. Очень часто, когда я заканчивал работу над очередным таском и отправлял пул реквест на проверку, я получал серию комментариев касательно моего кода. Несмотря на то, что задача была выполнена и все тесты светились зеленым, мои изменения все равно отклонялись. Комментарии обычно были следующими: метод выглядит слишком большим, переменные не достаточно описывают свое назначение, а вот этот код лучше вынести в отдельный класс и т.д. Это вызывало злость и обиду: “Я же выполнил задачу, все работает и компилятор не жалуется, в чем проблема?”.

Будучи студентом университета, я не очень заморачивался над тем, чтобы “вылизывать” свои программы. Большим успехом было уже то, что мой код просто компилировался, поэтому как только я добивался нужного вывода на экране, я с удовольствием оформлял лабораторную работу и получал положительную оценку. После стольких страданий над задачей мне и в голову не приходило пересмотреть свое решение и попытаться его как-то улучшить. И, конечно же, в то время я и понятия не имел о том, что такое рефакторинг.

На мой взгляд, с этой проблемой сталкивается большинство студентов, которые из года в год пишут код ради получения оценок. Иногда среди них проскакивают гики, которые получают удовольствие от написания программ и стараются совершенствовать свой код с каждым днем. Но даже они, из-за отсутствия заинтересованных наставников или просто постороннего взгляда, упускают очень много деталей. В итоге очень часто начинающие разработчики испытывают чувство несправедливости, когда их начинают ругать за те вещи, которые не имеют прямого отношения к задачам, над которыми они работают. Так ради чего устраивают весь этот блейм и почему просто работающего кода не достаточно?

Когда я пришел на свой первый проект, я думал, что знаю технологию достаточно хорошо, чтобы приносить пользу. Я ошибался. С первых же дней я был окружен сильными разработчиками, которые не давали расслабиться ни на минуту. Приходилось переписывать один и тот же кусок кода по несколько раз, прежде чем он попадал в основную ветку. Проанализировав основные причины, почему мой код не принимают, и пообщавшись с членами команды, я выявил для себя три самых главных постулата, почему чистый код важен:

1. Код пишется для людей

Когда вы пишете программу, которая должна прожить дольше одной демонстрации, есть стопроцентная вероятность, что туда нужно будет внести изменения. И если программа написана плохо, то кроме вас в ней никто не сможет разобраться. Более того, даже вы через месяц уже забудете, что означают все эти символы, и почему функция для получения данных одновременно выполняет апдейт. Читабельность - самый главный критерий, который сейчас ставится перед разработчиком. Представьте, если бы описание задачи было написано одновременно на разных языках, разными шрифтами, с сокращениями, сленгом, а также захватывало часть другой задачи. Разработчик даже не стал бы открывать такой таск. То же самое касается и кода. Если после просмотра его хочется сразу закрыть и выбросить, то такой проект будет сложно поддерживать. Очень часто для того, чтобы добавить фичу в уже работающий код, его переписывают с нуля, потому что любое изменение может все сломать.

2. Код должен быть гибким

И снова про изменения. Практически невозможно с первого раза написать систему, которая бы выполняла все требования заказчика. Постоянно добавляются новые возможности, находятся баги, изменяется внешний вид. Также можно заметить, что одни версии приложения добавляют новые фичи, а другие - удаляют старые. И представьте, какие трудности могут возникнуть у разработчиков, если удаление кнопки на странице ломает авторизацию. Поэтому умение разбивать программу на слои и изолировать фичи друг от друга можно практически считать искусством.

3. Код - самая достоверная документация

Этот пункт косвенно связан с пунктом про читабельность. Для описания любой более или менее сложной компьютерной системы, помимо кода, используется еще ряд документов: диаграммы, блок-схемы, task-board, bugtracker и даже комментарии в коде. Но каждый из этих документов является второстепенным по отношению к коду. И только код однозначно и достоверно описывает, как работает ваша система. Поэтому для того, чтобы видеть цельную картинку “из первых рук”, код должен быть самодокументируемым, а остальные файлы служат для его более удобной визуализации.

В итоге фокус при написании программы смещается от работающего кода к легко изменяемому коду. Чистый гибкий код становится основной целью каждого разработчика. Это тот универсальный скилл, который можно переиспользовать от проекта к проекту и который не зависит от предметной области. Более того, если посмотреть внимательно на основные паттерны, практики и гайдлайны, то они не привязаны даже к языку программирования. Если уметь ими правильно пользоваться, то можно создавать отличные продукты независимо от платформы и технологии.

Я несколько раз использовал понятие “чистый код”, но так и не показал, как он выглядит. На самом деле нет строгого определения, что является “чистым”. Проведем следующую аналогию. Что отличает хороший ресторан от забегаловки в переходе? Скорее всего, это качество продуктов, чистая посуда, стерильная кухня, высокие требованию к обслуживающему персоналу, красивый интерьер и культурная публика. Этот список можно продолжать, но даже сейчас заметно, что есть ряд характеристик, которые дают понять, получите вы удовольствие или нет. И даже если вам не нравится определенная кухня или очень высокие цены, вы все равно отдадите предпочтение ресторану перед забегаловкой. То же касается и кода. Несмотря на то, что каждый разработчик видит идеальный код по-своему, все же есть некоторый набор практик, которые однозначно отделяют плохой код от хорошего:

• Правильные имена переменных, функций, параметров: переменная должна однозначно описывать свою роль.
• Короткие лаконичные функции, которые выполняют только одну задачу: следует отделять функции для чтения данных от функций для изменения и стараться их не смешивать.
• Отсутствие дублирования кода: следуйте принципу Don’t Repeat Yourself, а именно старайтесь выносить код в отдельные блоки (функции), которые в дальнейшем можно будет переиспользовать.
• Использование библиотечных функций вместо написания своих: не изобретайте велосипед, используйте чужие наработки. Скорее всего, они гораздо лучше протестированы и покрывают разные критические ситуации. Плюс, вам не нужно тратить время на написание кода и его отладку.
• Использование декларативного стиля вместо императивного: код должен говорить, что он делает, а не как он это делает.

Конечно же, это не полный список требований к чистому коду. Гораздо больше практик вы можете найти в таких книгах, как Refaсtoring 1, 2, Code Complete и Clean Code. Но даже на основе этих пяти пунктов вы можете оценить свой код - является ли он “чистым”.

Это однозначно очень непростая задача - взглянуть на свой код “со стороны”. Для этого не достаточно только знаний, нужна еще определенная практика и критическое мышление. После того, как вы прочли теорию, вам необходимо:

1. Посмотреть на свои предыдущие наработки (это могут быть пробные проекты, учебные задачи или лабораторные работы) и исправить все проблемы, которые получится найти. Поскольку их может быть очень много, такая монотонная работа позволит вам запомнить основные ошибки и не допускать их в дальнейшем.

2. Попросить своего друга найти как можно больше проблем в вашем коде. Скорее всего, не придется его долго упрашивать. Будет лучше, если вы попросите нескольких человек посмотреть ваш код и составить список ошибок. Так вы получите более объективную оценку и большее количество проблемных мест. Этот процесс называется code review. Его используют в повседневной жизни разработчики, чтобы уже на начальных этапах (сразу после написания кода) выявить как можно больше слабых мест и исправить их до того, как код пойдет в релиз.

3. Если вы уже достаточно хорошо “почистили” свои программы, можно попробовать показать их более широкому кругу программистов. Я очень часто люблю копаться в чужих наработках, изучать стиль других разработчиков, анализировать, что я пишу не так. Для этого я использую разные ресурсы, но я бы хотел выделить парочку:

• Github открывает доступ к коду программистов со всего мира практически на всех языках программирования. Я как C# разработчик часто смотрю, как устроены те или иные библиотеки от Microsoft и других крупных компаний. Это позволяет лучше ориентироваться в том, как выполняется программа и как устроены алгоритмы “под капотом”.

• Codewars дает вам возможность решать задачи, придуманные другими людьми. Задачи устроены таким образом, что решение “в лоб” не всегда работает, и нужно посмотреть на проблему под другим углом. В таком режиме очень удобно совершенствовать навыки владения языком, который вы уже знаете, или изучать новый. В качестве бонуса ваше решение могут оценить другие программисты, а вы можете посмотреть на чужие решения. Сайт делит код на очень умный и изощренный, а также изящный и лаконичный.

В Академии мы стараемся уделять качеству кода столько же времени (или даже больше), сколько и разработке функционала. Потому что научиться писать код можно за несколько недель, но чтобы научиться писать хороший код, нужно потратить не один год. Поэтому мы с самого начала стараемся выработать у академистов привычку критически относиться к качеству кода, постоянно искать лучшие решения, переписывать уже рабочий код и всячески совершенствовать стиль написания программ. И тогда вопросы “как назвать переменную?”, “стоит ли выносить этот код в отдельный файл?” или “сколько параметров должна принимать функция?” будут возникать в голове сами собой. Самое главное - это не пренебрегать качеством кода ради работающего функционала.

В заключение хочу привести известную цитату: “Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте”. На первый взгляд она может показаться довольно странной. Но если вдуматься, то можно осознать, какое большое влияние имеет код каждого разработчика на команду в целом. И если вы не хотите, чтобы на следующем code review ваше имя называли чаще остальных, а ваши пул реквесты отклоняли из раза в раз, заставьте себя относиться к коду не просто как к средству решения каких-то бизнес-задач, но еще и как к произведению искусства, которое многое говорит о своем авторе.

Keep calm and write clean code.