В технологических компаниях существует множество правил, касающихся процесса разработки программного обеспечения, и каждое из них было разработано для решения проблемы создания ремонтопригодной и надежной системы. Когда вы разрабатываете сольный домашний проект, у вас обычно есть два шага: написать код и запустить код, используя какой-то контроль версий, такой как git. Однако разработкой функций совместно с другими разработчиками в большой кодовой базе будет сложно управлять, что приведет к возникновению технической задолженности. Технический долг подобен долгу по кредитной карте, чем дольше вы его игнорируете, тем хуже будет в будущем. Это снизит производительность разработчиков и снизит удовлетворенность работой. Поэтому каждой компании НЕОБХОДИМО иметь правила поддержания чистоты кода, когда они нанимают инженеров. Процесс очистки кода можно разделить на следующие 5 основных этапов:
Определить правила -> Написать код -> Использовать статическую проверку кода -> Обзор кода -> Объединить
Определение Правил
Когда присоединяется новый участник, старший инженер или руководитель группы должны ознакомить новых участников с набором правил о том, как они пишут код. Это означает определение соглашений о написании кода. У каждой компании есть свое собственное соглашение о разработке приложения. Например, у Google есть собственное руководство по стилю написания Код Java , в Твиттере есть эффективный scala , соглашение о коде для программирования на scala. Если у вас есть команда, которая заботится о качестве кода, это хорошо, потому что вы можете сотрудничать с ними, чтобы создать или установить это правило. В противном случае вам придется использовать свои навыки убеждения, чтобы убедить других и бизнес-подразделение в том, почему важен чистый код. Команде необходимо создать читаемый и поддерживаемый код, чтобы уменьшить техническую задолженность, чтобы бизнес не тратил больше ресурсов и времени на устранение более серьезных проблем в будущем. Кроме того, вы не можете быть единственным, кто заботится о качестве кода. Почему? Потому что это все равно что плыть против течения. Вы можете немного продвинуться вперед, но каждый раз, разрабатывая функцию, вы будете чувствовать ярость и непродуктивность и в конечном итоге перегорите. Вы и ваша команда должны придерживаться одинакового подхода к созданию лучшей культуры кода. Это может занять некоторое время, усилия и дисциплину, но результат приведет к более высокой скорости разработки и удовлетворенности работой.
Как только ваша команда определит правила и соглашения, вы сможете приступить к разработке функций и написанию кода.
Как обеспечить, чтобы каждый из вашей команды соблюдал установленные правила? Если у вас есть команда из 2 человек, легко продолжать писать код, основанный на соглашениях. Однако как вы можете быть уверены, что эти правила применимы, если в вашей команде более 10 инженеров?
Средство проверки статического кода спешит на помощь
Инструменты статического анализа кода – это метод для компьютерной программы, который выполняется путем изучения кода без его компиляции. Это лучший способ проверить, пахнет ли ваш код. Примеры инструментов статической проверки кода включают: Eslint , Sonarlint … и т.д. Каждая команда или компания может установить правила конвенции. Один из примеров популярного соглашения о кодировании для JavaScript, разработанного инженерами в Airbnb . Это дает простой способ уведомить разработчиков о необходимости следовать соглашениям и передовой практике во время написания кода.
Что вам следует делать, если вам назначен устаревший код и вам необходимо создать функции поверх него? Многие инженеры не имеют привилегии разрабатывать новый солидный проект с нуля. Просмотр устаревшего кода может быть сложным, потому что он может быть нечитаемым. Вы можете воспользоваться правилом бойскаута Роберта К. Мартина:
“Оставляй вещи ЛУЧШЕ, чем ты их нашел”.
Он включает в себя: найден грязный код -> необходимо выполнить задачу -> рефакторинг
Иногда код, который вам нужно реорганизовать, может быть больше, чем время, которое вы потратили на разработку функции. Поэтому вам нужно оценить, велики ли усилия или малы. Если он маленький, проведите рефакторинг. Если он большой, отметьте комментарий ЗАДАЧА на коде и установите его с помощью средства отслеживания проблем.
Используя это правило, небольшие изменения будут суммироваться и позволят создать более читаемый код для будущих сопровождающих для исправления ошибок или добавления новых функций.
Проверка кода
Существует множество способов проверки кода, и у каждой компании свои правила проведения проверки кода. Этот процесс является общим процессом, который, как я вижу, используется большинством компаний при проверке кода.
Важность и преимущества анализа кода, и это лишь некоторые из них, могут повысить качество кода, оказать положительное влияние на командную культуру, а признание экспертных знаний в области кода со стороны коллег является источником гордости для многих программистов.
По крайней мере, 2 человека проводят проверку кода. Тем не менее, 1 человек тоже подойдет, но он/она должен понимать основную бизнес-логику и задачу, которую вы пытаетесь выполнить. Вы сможете объединить свой код, как только все выделенные проблемы будут решены, и обсудить их на протяжении всего процесса. Кроме того, если ваш код получит комментарий, вы должны обратиться ко всем из них. Говоря: “Да, у меня есть исправление, основанное на ваших предложениях”. Или “нет, это не так, как должно работать, по причинам x, y, z”.
Проверка кода также должна быть протестирована с помощью инструментов сборки, таких как модульное тестирование и интеграционное тестирование, чтобы процесс был более быстрым и плавным. Если у вас нет инструментов для сборки, вы можете выполнять парное программирование на экране. Таким образом, рецензенты могут получить мгновенную обратную связь по обзору. Каждый раз, когда вы хотите, чтобы кто-то выполнял ваш код, говорите: “Эй, не могли бы вы подойти и взглянуть на мой код и посмотреть, есть ли в этом что-то странное?”
Наконец, проверка кода бесклассовая , то, что вы самый старший в команде, не означает, что ваш код не нуждается в проверке. Отнеситесь с уважением к рецензии. Хотя состязательное мышление удобно, это не ваша особенность, и вы не можете принимать все решения. Если вы не можете согласиться с вашим отзывом с кодом как есть, переключитесь на обсуждение в режиме реального времени или обратитесь за мнением третьего лица.
Вывод
Устанавливая правила при внедрении инженеров, они могут понять любые ожидания при разработке новых функций. Создайте статическую проверку кода, и автоматизированные средства сборки смогут поддерживать читаемый код в неизменном виде. Наконец, наличие хорошего процесса проверки кода может не только повысить качество кода, но и создать отличную культуру для инженеров в команде. Чистый код – это не “приятно иметь”. Это необходимость. Даже если вы запускаете новую функцию для бизнес-требований и вам необходимо как можно скорее запустить код, старайтесь по возможности не пропускать этот процесс разработки. Вечная бдительность – это цена любого качества, и стремление к этой привычке может помочь вам достичь ее.
Оригинал: “https://dev.to/edwardgunawan/how-to-maintain-clean-code-in-your-projects-22cb”