Качество кода всегда имеет значение, но особенно важно, если ваш код является частью командного проекта или доступен для других. Регулярные экспертные проверки кода играют жизненно важную роль в создании высококачественного, пригодного для использования кода, который отвечает потребностям бизнеса и соответствует требованиям политики.
Представьте себе мир, в котором каждый разработчик может писать код так, как ему заблагорассудится. Несомненно, мы обнаружили бы, что один и тот же код написан разными способами, и в конечном итоге наша кодовая база превратилась бы в громоздкий беспорядок. Вот почему важно иметь политику стандартов кодирования, в которой описываются методы кодирования компании и ее процедуры проверки кода.
При проверке кода коллеги проверяют код друг друга. Они должны понимать, что ошибаться может только человек. Они проверяют код на наличие ошибок, код, противоречащий политике кодирования компании, и любой код, который, хотя и синтаксически правильный, может быть улучшен в интересах удобочитаемости, ремонтопригодности или производительности. Наша книга Чистый код на C# посвящена этим темам.
В этом обзоре мы рассмотрим следующие темы:
· Подготовка кода к просмотру
· Ведение код-ревью
· Знать, что проверять
· Знание того, когда отправлять код на проверку
· Предоставление отзывов и ответы на них
Прежде чем мы углубимся, давайте опишем общий процесс проверки кода.
Процесс проверки кода
Перед рецензированием кода вы должны убедиться, что ваш код компилируется и соответствует известным требованиям. Он должен пройти все модульные тесты и сквозные тесты. Как только вы будете уверены, что можете успешно скомпилировать, протестировать и запустить свой код, вы можете вернуть его в текущую рабочую ветку. После регистрации вы отправляете запрос на извлечение.
Затем рецензент рассмотрит ваш код и поделится комментариями и отзывами. Если ваш код проходит проверку кода, ваша проверка кода завершена, и вы можете объединить свою рабочую ветку с основной веткой. В противном случае код будет отклонен, и вам потребуется просмотреть свою работу и решить проблемы, поднятые вашим рецензентом.
На следующей схеме показан процесс:
Подготовка кода к проверке
Подготовка к проверке кода иногда может показаться неприятной, но в результате получается более качественный код, который легко читать и поддерживать. Время, затрачиваемое на подготовку к проверке кода, может значительно сэкономить время рецензента и сделать сам обзор более эффективным.
Вот несколько моментов, которые следует учитывать при подготовке к проверке кода:
· Всегда помните о проверке кода. Приступая к программированию, вы должны помнить о проверке кода. Держите свой код небольшим. Если возможно, ограничьте свой код одной функцией.
· Удостоверьтесь, что все ваши тесты проходят успешно, даже если ваш код собирается: Если ваш код собирается, но у вас есть неудачные тесты, немедленно разберитесь с ними, прежде чем двигаться дальше. Выпуск кода, который «работает», но не прошел тестирование, может привести к тому, что некоторые клиенты будут очень недовольны, когда код пойдет в производство.
· Помните YAGNI («Вам это не понадобится»): при написании кода обязательно добавляйте только тот код, который необходим для выполнения требований или функций, над которыми вы работаете.
· Проверяйте наличие дублирующегося кода: если ваш код должен быть объектно-ориентированным и быть СУХИМ («Не повторяйтесь») и ТВЕРДЫМ (см. статью Роберта Мартина «Принципы проектирования и шаблоны проектирования» в 2009 г.), просмотрите свой собственный код, чтобы увидеть, содержит ли он любой процедурный или повторяющийся код. Если это так, найдите время, чтобы реорганизовать его, чтобы он был объектно-ориентированным, DRY и SOLID.
· Используйте статические анализаторы. Статические анализаторы кода, настроенные для применения передовых практик вашей компании, проверят ваш код и выявят все обнаруженные проблемы. Не игнорируйте информацию и предупреждения, которые могут вызвать проблемы в будущем.
Ведение проверки кода
При проведении код-ревью важно присутствие нужных людей по согласованию с руководителем проекта. Программисты, ответственные за отправку кода на проверку, будут присутствовать при проверке кода, если только они не работают удаленно. В случае удаленной работы рецензент просматривает код и либо принимает запрос на вытягивание, либо отклоняет запрос на вытягивание, либо отправляет разработчику несколько вопросов, на которые нужно ответить, прежде чем предпринимать какие-либо дальнейшие действия.
Подходящий руководитель для проверки кода должен:
· Быть техническим авторитетом: они должны понимать руководящие принципы компании по кодированию и методологии разработки программного обеспечения. Также важно, чтобы они имели хорошее общее представление об анализируемом программном обеспечении.
Обладать хорошими навыками межличностного общения: это должен быть теплый и ободряющий человек, способный предоставить конструктивную обратную связь, чтобы избежать конфликта между рецензентом и человеком, чей код рецензируется.
· Не быть чрезмерно критичным: они не должны быть чрезмерно критичными и должны быть в состоянии объяснить свою критику кода. Полезно, если они знакомятся с разными стилями программирования и могут объективно рассматривать код, чтобы убедиться, что он соответствует требованиям проекта.
Независимые проверки кода обычно выполняются по запросам на вытягивание в инструменте контроля версий, используемом командой. Программист отправит код в систему контроля версий, а затем выдаст запрос на включение. Затем рецензент кода просматривает код в запросе на вытягивание. Обратная связь будет в виде комментариев, прикрепленных к пулл-реквесту. Если есть проблемы с запросом на включение, то рецензент отклонит запрос на изменение и прокомментирует проблемы, которые необходимо решить программисту. Если проверка кода прошла успешно, рецензент может добавить комментарий с положительным отзывом, объединить запрос на извлечение и закрыть его.
Программисты должны будут отметить любые замечания, сделанные рецензентом, и принять их к сведению. Если код необходимо отправить повторно, то программист должен будет убедиться, что все комментарии рецензента были учтены до повторной отправки.
Хорошая идея — делать проверки кода короткими и не проверять слишком много строк одновременно.
Влияние отзывов на рецензентов
При просмотре кода ваших коллег вы должны стремиться к тому, чтобы обратная связь была положительной. Отрицательная обратная связь фокусируется на рецензенте, а не на проблеме, и оказывает разрушительное воздействие на рецензента. Затем развивается отсутствие мотивации, что может негативно сказаться на команде, так как работа не выполняется вовремя или на требуемом уровне. Любые плохие отношения между рецензентом и рецензентом также будут ощущаться командой. В результате может пострадать весь проект.
Если дело дойдет до того, что рецензент сыт по горло и уйдет на новую должность в другое место, то проект пострадает как во времени, так и в финансовом плане, так как потребуется потратить время и деньги на поиск и обучение замены. На следующей диаграмме показаны негативные отзывы рецензента по отношению к рецензенту:
Положительная обратная связь от рецензента к рецензенту имеет противоположный эффект. Когда рецензент дает положительный отзыв рецензенту, он сосредотачивается на проблеме, а не на человеке. Они объясняют, почему представленный код не является хорошим, и предлагают рецензенту способы его улучшения. Отзыв, предоставленный рецензентом, делается только для улучшения качества кода, представленного рецензентом.
Когда рецензент получает положительную (конструктивную) обратную связь, ему легче принимать комментарии к сведению и реагировать соответствующим образом, отвечая на вопросы рецензента, а также задавать любые соответствующие вопросы самостоятельно. Поэтому в код вносятся поправки, и он повторно отправляется на рассмотрение на основе лучшего понимания требования. Это положительно сказывается на коллективе, так как атмосфера остается позитивной, а работа выполняется вовремя и с требуемым качеством. Следующая диаграмма показывает это:
Важно помнить, что ваша цель как рецензента — быть конструктивным, а не деструктивным. Счастливая команда – продуктивная команда!
Полезным методом позитивной критики является метод сэндвича с обратной связью. Вы начинаете с похвалы за хорошие моменты, затем даете конструктивную критику, а затем заканчиваете еще одной похвалой. Этот метод может быть очень полезен, если в вашей команде есть члены, которые плохо реагируют на критику. Ваши социальные навыки в общении с людьми так же важны, как и ваши навыки работы с программным обеспечением для создания качественного кода.
Давайте теперь рассмотрим, что мы должны рассмотреть.
Знаем, что проверять
Полный и тщательный обзор кода учитывает ряд различных аспектов кода:
Руководство по кодированию и бизнес-требования компании
Весь новый код должен соответствовать стандартам кодирования и лучшим практикам, принятым в компании. Он также должен соответствовать бизнес-требованиям.
Например, если в требовании пользователя/заинтересованной стороны указано, что как пользователь я хочу добавить новую учетную запись клиента, соответствует ли рассматриваемый код всем условиям, изложенным в этом требовании? Если в руководстве по кодированию компании указано, что весь код должен включать модульные тесты, которые проверяют нормальный поток и исключительные случаи, то все ли необходимые тесты были реализованы? Если ответ на любой из этих вопросов отрицательный, то код должен быть прокомментирован, комментарии должны быть учтены программистом, а код отправлен повторно.
Соглашения об именах
Код должен быть проверен, чтобы увидеть, соблюдены ли соглашения об именах для различных конструкций кода, таких как классы, интерфейсы, переменные-члены, локальные переменные, перечисления и методы. Никому не нравятся загадочные имена, которые трудно расшифровать, особенно если кодовая база велика. Имена должны быть достаточно длинными, чтобы быть удобочитаемыми и понятными для человека, а также быть значимыми по отношению к назначению кода.
Форматирование
Форматирование имеет большое значение для облегчения понимания кода. Пространства имен, фигурные скобки и отступы должны использоваться в соответствии с рекомендациями, а начало и конец блоков кода должны быть легко идентифицируемыми.
Опять же, вот набор вопросов, которые рецензент должен задать в своем обзоре:
· Должен ли быть код с отступом с использованием пробелов или табуляции?
· Было ли использовано правильное количество пустого пространства?
· Есть ли слишком длинные строки кода, которые следует распределить по нескольким строкам?
· А как насчет разрывов строк?
· Следуя рекомендациям по стилю, есть ли только одно утверждение в строке? В строке только одно объявление?
· Строки продолжения имеют правильный отступ?
· Разделяются ли методы одной линией?
· Разделены ли скобками несколько предложений, составляющих одно выражение?
· Являются ли классы и методы чистыми и небольшими, и выполняют ли они только ту работу, для которой предназначены?
Тестирование
Тесты должны быть понятными и охватывать хорошее подмножество вариантов использования. Они должны охватывать обычные пути выполнения и исключительные варианты использования. Рецензент должен проверить следующее:
· Предоставил ли программист тесты для всего кода?
· Есть ли непроверенный код?
· Все ли тесты работают?
· Проваливаются ли какие-либо тесты?
· Имеется ли адекватная документация по коду, включая комментарии, комментарии к документации, тесты и документацию по продукту?
· Видите ли вы что-нибудь особенное, что, даже если оно компилируется и работает изолированно, может вызвать ошибки при интеграции в систему?
· Хорошо ли задокументирован код для облегчения обслуживания и поддержки?
Посмотрим, как пойдет процесс:
Непроверенный код может вызвать непредвиденные исключения во время тестирования и производства. Но неверные тесты так же плохи, как и непроверенный код. Это может привести к ошибкам, которые трудно диагностировать, которые могут раздражать клиента и заставлять вас работать в дальнейшем.
линия. Ошибки — это технический долг, и бизнес воспринимает их негативно. Более того, вы, возможно, написали код, но другим, возможно, придется читать его, поскольку они поддерживают и расширяют проект. Всегда полезно предоставить некоторую документацию для ваших коллег.
Как технический специалист, проверяющий код, обнаруживаете ли вы какие-либо запахи кода, которые могут стать проблемой? Если это так, то вы должны пометить, прокомментировать и отклонить запрос на вытягивание, а также заставить программиста повторно отправить свою работу.
Как рецензент, вы должны убедиться, что эти исключения не используются для управления ходом выполнения программы, и что все возникающие ошибки содержат значимые сообщения, которые будут полезны разработчикам и клиентам, которые их получат.
Архитектурные рекомендации и шаблоны проектирования
Новый код необходимо проверить, чтобы убедиться, что он соответствует архитектурным рекомендациям проекта. Код должен следовать любым парадигмам кодирования, которые использует компания, таким как SOLID, DRY, YAGNI и ООП. Кроме того, по возможности код должен использовать подходящие шаблоны проектирования.
Здесь в игру вступают шаблоны Gang-of-Four (GoF). В GOF входят четыре автора книги по C++ под названием Design Patterns: Elements of Reusable Object-Oriented Software. Авторами были Эрих Гамма, Ричард Хелм, Ральф Джонсон и Джон Влиссидес.
Сегодня их шаблоны проектирования широко используются в большинстве, если не во всех, объектно-ориентированных языках программирования. Полезными ссылками являются шаблоны проектирования .NET от Praseen Pai и Shine Xavier (Packt) и https://www.dofactory.com/net/design-patternshttps. Последний сайт охватывает каждый из шаблонов GoF и предоставляет определение, диаграмму классов UML, участников, структурный код и некоторый реальный код для шаблонов.
Код также должен быть правильно организован и помещен в правильное пространство имен и модуль. Проверьте, не является ли код слишком упрощенным или, наоборот, слишком сложным.
Производительность и безопасность
Базовый контрольный список производительности и безопасности включает следующее:
· Насколько хорошо работает код?
· Есть ли узкие места, которые необходимо устранить?
· Запрограммирован ли код таким образом, чтобы он защищал от атак путем внедрения кода SQL и атак типа «отказ в обслуживании»?
· Проверяется ли код должным образом, чтобы гарантировать, что в базе данных сохраняются только достоверные данные?
· Проверяли ли вы пользовательский интерфейс, документацию и сообщения об ошибках на наличие орфографических ошибок?
· Сталкивались ли вы с магическими числами или жестко закодированными значениями?
· Верны ли данные конфигурации?
· Были ли случайно зарегистрированы какие-либо секреты?
Всесторонний обзор кода будет охватывать все предыдущие аспекты. Но когда самое подходящее время для проведения проверки кода?
Знать, когда отправлять код на проверку
Проверка кода должна проводиться после завершения разработки и до того, как программист кода передаст код в отдел контроля качества. Прежде чем какой-либо код будет проверен в системе контроля версий, весь код должен быть собран и запущен без ошибок, предупреждений или информации.
Когда ваш код завершен и полностью задокументирован, ваши тесты работают, а системная интеграция работает без каких-либо проблем, тогда вы готовы отправить свой код на экспертную оценку кода. Как только ваш код будет одобрен, его можно будет передать в отдел контроля качества. На следующей диаграмме показан жизненный цикл разработки программного обеспечения (SDLC) от разработки кода до конца срока службы кода:
Если проверка кода проходит успешно, код передается команде QA, которая проводит собственное внутреннее тестирование. Все найденные ошибки передаются разработчикам для исправления. Если внутреннее тестирование проходит контроль качества, оно развертывается в рамках приемочного тестирования пользователей (UAT).
В случае сбоя UAT возникают проблемы с командой DevOps, которая может быть разработчиками или инфраструктурой. Если UAT проходит QA, то он развертывается на промежуточной стадии. Staging — это команда, ответственная за развертывание
продукт в производственных условиях. Когда программное обеспечение находится в руках клиента, он создает отчет об ошибке, если обнаруживает какие-либо ошибки. Затем разработчики работают над исправлением ошибок клиента, и процесс перезапускается. Как только продукт достигает конца своего срока службы, он выводится из эксплуатации.
Предоставление отзывов об отзывах и ответы на них
Стоит помнить, что проверка кода направлена на улучшение общего качества кода в соответствии с рекомендациями компании. Поэтому обратная связь должна быть конструктивной и не использоваться в качестве предлога, чтобы оскорбить или поставить коллегу в неловкое положение. Точно так же отзыв рецензента не следует принимать на свой счет, а ответы рецензенту должны быть сосредоточены на подходящих действиях и объяснениях.
Предоставление отзыва в качестве рецензента
Издевательства на рабочем месте могут быть проблемой, и среда программирования не защищена от них. Никому не нравятся дерзкие программисты, считающие себя большими. Поэтому важно, чтобы рецензент обладал хорошими навыками межличностного общения и был очень дипломатичен. Имейте в виду, что некоторые люди могут легко обидеться и воспринять что-то неправильно. Знание того, с кем вы имеете дело и как они могут отреагировать, поможет вам тщательно выбирать подход.
Как рецензент кода, вы будете нести ответственность за понимание требований и обеспечение того, чтобы код им соответствовал. Постарайтесь ответить на эти вопросы:
· Умеете ли вы читать и понимать код?
· Видите ли вы какие-либо потенциальные ошибки?
· Были ли сделаны какие-либо компромиссы, и если да, то почему?
· Приводят ли компромиссы к какому-либо техническому долгу, который необходимо будет учесть в проекте в дальнейшем?
После завершения обзора у вас есть три категории отзывов на выбор: положительный, необязательный и критический. С положительной обратной связью вы можете похвалить программиста за то, что он сделал действительно хорошо. Это хороший способ поднять боевой дух, поскольку в командах программистов он часто может иссякать. Необязательная обратная связь может быть очень полезной, помогая программистам оттачивать свои навыки программирования в соответствии с рекомендациями компании, и они могут работать над улучшением общего состояния разрабатываемого программного обеспечения.
Наконец, у нас есть критический отзыв. Критическая обратная связь необходима для любых выявленных проблем и должна быть решена до того, как код будет принят и передан в отдел обеспечения качества. Это обратная связь, где вам нужно будет тщательно выбирать слова, чтобы никого не обидеть. Важно, чтобы ваши критические комментарии касались конкретной поднятой проблемы и приводили веские доводы в поддержку обратной связи.
Ответ на отзыв в качестве рецензента
Как программист-рецензент, вы должны эффективно донести до рецензента предысторию своего кода. Вы можете помочь им, делая небольшие коммиты. Небольшие объемы кода гораздо легче просматривать, чем большие объемы кода. Чем больше кода рецензируется, тем легче быть.
промахнуться и проскользнуть через сетку. Пока вы ожидаете проверки вашего кода, вы не должны вносить в него дальнейшие изменения.
Полученные отзывы могут быть положительными, необязательными или критическими. Положительный отзыв помогает повысить вашу уверенность в проекте, а также моральный дух. Опирайтесь на это и продолжайте использовать передовой опыт. Вы можете действовать или не действовать на основе необязательного отзыва, но всегда полезно обсудить это со своим рецензентом.
К критическим отзывам следует относиться серьезно и действовать по ним, поскольку они необходимы для самого успеха проекта. Очень важно, чтобы вы относились к критическим отзывам вежливо и профессионально. Не позволяйте себе обижаться на комментарии рецензента: они не должны быть личными. Это особенно важно для начинающих программистов и программистов, которым не хватает уверенности.
Как только вы получите отзыв от своего рецензента, действуйте в соответствии с ним и обязательно обсудите его с ним по мере необходимости.
Заключение
Проверка кода играет ключевую роль в создании эффективного кода, отвечающего требованиям бизнеса. Эффективные обзоры кода предъявляют требования как к рецензентам, так и к рецензентам. Как рецензенты, мы должны использовать наши межличностные навыки, предоставляя обратную связь нашим коллегам-программистам. Как рецензенты, мы должны учитывать положительные отзывы и действовать в соответствии с критическими отзывами.
Экспертная проверка кода требует времени и может быть неудобной как для рецензента, так и для рецензента. Но в долгосрочной перспективе они помогают нам создавать высококачественные продукты, которые легко расширять и поддерживать. В то же время они облегчают повторное использование кода, что означает большой выигрыш с точки зрения эффективности. Для более подробного ознакомления здесь ссылка на книгу Чистый код на C# Джейсона Оллса.
Дополнительная литература https://docs.microsoft.com/en-us/visualstudio/code-quality/?view=vs-2019: В этой документации Microsoft содержится информация о различных инструментах, доступных для помочь вам проанализировать и улучшить качество и ремонтопригодность вашего кода. https://en.wikipedia.org/wiki/Code_review: На этой странице есть много полезных ссылок, которые помогут вам лучше узнать о проверках кода и их ценности для вашего бизнеса. Книга шаблонов проектирования Gang-of-Four: https://springframework.guru/gang-of-four-design-patterns/ Шаблоны проектирования .NET, Прасид Пай и Шайн Ксавье: https://www.packtpub. com/application-development/net-design-patterns Страница справки GitHub: https://help.github.com/en
