На тему написания хорошего, чистого, правильного кода существует много хороших и одна эталонная книга. Там предлагаются техники и подходы, которые помогают создавать не просто работающие и решающие задачи бизнеса, а ещё и долгоживущие классы, функции, компоненты.
Общая характеристика такого кода всего лишь одна — устойчивость к изменениям. Речь не про охват всех возможных кейсов использования условной кнопки в UI-ките сразу, а про такой дизайн при котором изменения можно будет безболезненно вносить по мере надобности. Но как этого добиться? Как повысить шансы на то, что новый и уполномоченный разработчик не решит переписать кнопку с нуля, по-своему, а аккуратно и предсказуемо внесет требуемые изменения?
Ответ только один. Нужно сделать код понятным.
Да, капитан, но как?
Понятный код — предсказуемый код. Он логичен, компактен, когнитивно прост. Он читается сверху-вниз. Переменные и методы в нем именованы осмысленно, аккуратно. Ответственность методов разделена. Соблюдаются принципы SOLID, DRY, KISS и другие крутые аббревиатуры. В этом посте инструкции по созданию такого кода давать нет смысла, ведь именно их и содержат те самые книги, которые я вспомнил в начале поста.
Однако все эти принципы и теоретические подходы существуют только в лабораторных условиях. На реальном фронтенд-проекте нет-нет, да и встретится кусочек сломанного костыля или ржавая вилка самодельного велосипеда. Так что же, забываем все лучшие практики и наработки наших предшественников и живем как живется?
На то мы и «инженеры», чтобы находить применение чистой науке в реальном мире. Поэтому я предлагаю взять из теоретически-практических уроков великих программистов прошлого основное — стремиться сделать код простым и понятным, чтобы разобраться в нем было легко даже человеку с улицы. При этом ошибки, неточности и шероховатости допускаются в угоду соблюдению сроков.
Самое важное правило, которое стоит усвоить — написанный код лучше идеального. Несовершенства не только допускаются, но и приветствуются. Особенно если они документированы и работа по их «шлифовке» занесена в бэклог.
«Меня уволят за хороший код»
Слышал такое мнение: «Если мой код понятен, значит разобраться в нем может каждый, значит меня можно заменить более дешевым специалистом а то и вообще скормить кодовую базу ИИ и он будет работать условно бесплатно. А меня уволят». Не знаю, насколько это опасение серьезно, но скажу так — если вам платят только за код, то именно такой сценарий вас и ждет.
Любой разработчик уровня выше чем джуниор занимается написанием кода лишь 20-30 процентов времени. Остальное время уходит на выяснение и уточнение требований, обсуждение гипотез, межличностную коммуникацию. И если вы в этом не участвуете, то да, вы в зоне риске. При этом это почти что задача про два стула.
Если вы будете писать хорошо — вас заменят на более дешевого кодера. Если вы будете писать плохо — ваши коллеги-разработчики будут мягко говоря не в восторге от количества комментариев, которые им придется писать каждое код-ревью и количества крит-багов в проде, которые придется тушить, по-классике, вечером пятницы. Если же вы работаете одним фронтом на проекте, то запах кода будет сильно тормозить разработку и релиз фичей перестанет быть предсказуемым.
Бизнес окажется недоволен. Проект закроют. Вас уволят.
Решение и вывод
Решение у этой задачи только одно. Оно не остроумное и даже не в рифму. Он прагматично — в любой ситуации выбирайте оставаться профессионалом. Это значит не допускать халтуры, учитывать интересы других участников проекта, его заказчиков, стремиться сделать идеально, но с учетом тех ресурсов, которые у вас есть. Желаю успехов!
