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

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

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

Почему вы должны содержать код в чистоте

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

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

Это похоже на теорию «разбитого окна», которая гласит:

«Представьте себе здание с несколькими разбитыми окнами. Если окна не отремонтированы, вандалы имеют тенденцию разбивать еще несколько окон. В конце концов, они могут даже проникнуть в здание и, если оно пустует, стать скваттерами или разжечь внутри костры».

Итак, что мы узнаем из теории «разбитых окон»?

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

Обнаружение красных флажков в вашей кодовой базе

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

1. Пренебрежение разработчиками

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

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

2. Чрезмерная сложность

Иногда разработчики хотят доказать, что они Тони Старк в разработке программного обеспечения.

Я стал разработчиком в 10 раз больше, детка!

Итак, что же они делают? Замените три строки кода одной вложенной строкой со странным нишевым синтаксисом вашего языка. Конечно, такой подход запутает читателей и оставит у них больше вопросов, чем ответов. Но кого это волнует — Главное, чтобы вы чувствовали себя гением, верно? (Нет)

Излишняя разработка простого решения не докажет, что вы гений. Это подтверждает, что вы не понимаете человеческий фактор в разработке программного обеспечения, и подрывает качество кода и ремонтопригодность.

3. «Давайте угадаем, что означает эта переменная»

Одной из самых сложных частей работы программиста является присвоение имен переменным. Хорошо названные переменные или функции могут легко рассказать читателям, что они делают. Напротив, плохое название затрудняет чтение и требует больше времени для понимания.

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

Обычно ваше неправильное поведение с именами выявляется во время проверки кода, но давайте будем честными: зачем начинать трудоемкий спор, когда вы можете просто следовать соглашениям об именах?

4. Дублирование, дублирование и дублирование

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

Вот что произойдет: вы, вероятно, пропустите один или два экземпляра скопированного кода, а затем вам придется снова сканировать проект несколько раз. Я даже не буду вдаваться в головную боль, связанную с тем, что несколько человек присоединяются к задаче для сканирования и устранения проблемы. Это требует много времени и усилий, и его нельзя недооценивать.

Абстракции сложны и отнимают много времени, но сосредоточение внимания на будущем обслуживании стоит вашего времени.

Лучшие практики для создания культуры чистого кода

1. Четкое определение чистого кода

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

Популярные шаблоны передового опыта кодирования могут быть хорошими ресурсами для определения вашей версии чистого кода; некоторые из них SOLID, DRY (не повторяйтесь), KISS (Keep It Simple, Stupid) и т. д.

2. Проверка кода

Какова цель вашего кода? Покажи мне!

Развитие культуры требует взаимодействия с сообществом, и сеанс проверки кода является одним из них. Обычно в обзоре кода должны участвовать два члена команды разработчиков, один из которых не является автором кода. Руководители групп разработчиков должны поощрять своих разработчиков к проверке кода и отправке отзывов до того, как какие-либо изменения будут доставлены в рабочую среду. Благодаря этим действиям может быть достигнуто сочетание следующих целей:

  1. Качество кода: люди более осторожны при отправке кода на проверку, потому что они знают, что кто-то будет смотреть, и если качество не очень хорошее, они могут быть унижены.
  2. Обнаружение дефекта: Исследование группы программирования систем Cisco показало, что просмотр 200–400 LOC в течение 60–90 минут должен обеспечить обнаружение дефекта на 70–90 %.
  3. Возможность обучения: присоединяясь к сеансам рецензирования, рецензенты и автор могут учиться друг у друга. Они могут узнать, как лучше придерживаться стандартов кодирования.

3. Постоянно улучшайте кодовые базы посредством рефакторинга

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

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

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

Каждый раз, когда вы выполняете работу в области кода, всегда оставляйте код немного чище, а не немного грязнее, чем вы его нашли. — Дядя Боб

4. Обеспечение соблюдения стандартов кодирования

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

Обычно используемые автоматизированные инструменты включают Pylint для Python, ESLint для JavaScript и т. д. Если вы используете CI/CD, рассмотрите возможность интеграции этих инструментов в свой конвейер для проверки нарушений стандартов кодирования во время рабочего процесса разработки.

5. Вознаграждайте достижения в области чистого кода

Есть два способа мотивировать человека к действию: потребности или награды. Такое же поведение можно применить к лучшим практикам чистого кода, что обеспечит доставку структурированного кода и уменьшит количество нарушений стандартов кодирования.

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

Насколько достаточно чистого кода?

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

На самом деле, насколько «чистым» будет ваш код, может сильно зависеть от согласия вашей команды. Хотя поддержание структуры кода важно, следует учитывать и другие факторы, которые могут повлиять на успех проекта, такие как нехватка времени, доступность ресурсов, особые требования и коллективные навыки членов команды.

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

«Отличное программное обеспечение должно быть адаптируемым и подготовленным к будущим изменениям в бизнесе и его определении».

Чтобы получить максимальную отдачу от этой статьи, не стесняйтесь выполнять эти задачи 👇:

  1. Ваша организация стремится обеспечить чистую культуру кодирования или нет? Если да, то какой текущий подход помогает разработчикам придерживаться практики чистого кода?
  2. Считаете ли вы, что чистый код является исключительной обязанностью отдельных разработчиков, или это должны быть коллективные усилия внутри команды или организации? Почему?

Первоначально опубликовано на https://junedang.com 1 июля 2023 г.