Code review: Что такое код-ревью

Что такое код-ревью

Послу­шать аудио­вер­сию этой ста­тьи (6 минут):

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

Когда вы пише­те новую функ­цию, она не попа­да­ет сра­зу в про­ект. Вме­сто это­го ваш код отправ­ля­ет­ся на код-ревью (code review).

Что делают на код-ревью

Во вре­мя код-ревью кто-то из стар­ших това­ри­щей изу­ча­ет ваш код на предмет:

• Оши­бок.
• Сти­ли­сти­ки — пише­те ли вы так, как при­ня­то в компании.
• Оформ­ле­ния кода — соблю­да­е­те ли вы отсту­пы и табу­ля­цию, что­бы код было лег­че читать.
• Ком­мен­та­ри­ев — если в ком­па­нии при­ня­то ком­мен­ти­ро­вать клю­че­вые момен­ты в коде.
• Адек­ват­ность реа­ли­за­ции — вы пред­ло­жи­ли изящ­ное реше­ние или реши­ли всё гру­бой силой? А что умест­нее в этой ситуации?
• Вли­я­ния на про­ект — если вы пол­но­стью пере­пи­са­ли фор­мат пере­да­чи дан­ных на сер­вер, то это зна­чит, что дру­гим участ­ни­кам нуж­но будет под­стро­ить­ся под вас и пере­пи­сать свою часть. Это дорого.
• Уяз­ви­мо­стей в без­опас­но­сти — может ли что-то пой­ти не так, если зло­умыш­лен­ник решит исполь­зо­вать этот код в сво­их целях.

Если про­бле­мы есть, про­ве­ря­ю­щий отправ­ля­ет код на дора­бот­ку. Если всё хоро­шо, код пере­хо­дит на сле­ду­ю­щую ста­дию — как пра­ви­ло, в тестирование.

Кто проводит

Обыч­но при­ня­то так: код-ревью дела­ют про­грам­ми­сты более стар­ше­го уров­ня. Джу­ни­о­ров про­ве­ря­ют мид­лы, мид­лов — сеньо­ры, сеньо­ров — дру­гие сеньо­ры или тим­ли­ды. Если ком­па­ния боль­шая, то могут выде­лить отдель­но несколь­ко чело­век, кото­рые смот­рят код у всех и сле­дят за общим стилем.

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

Как это выглядит

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

Зачем это нужно

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

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

Чек-лист для Code Review | Flexberry PLATFORM Documentation

Список требований к выполнению задачи на исправление и доработку продуктов платформы Flexberry

Чек-лист для CodeReview — замечательное средство, позволяющее проверить, что ревьюер не забыл удостовериться в отсутствии всех потенциальных проблем с исследуемым кодом.

Аспекты которые надо проверить

Код

• Работоспособность кода.
  • Код работает и выполняет свои прямые обязанности, логика корректна, и т. д.
  • У циклов есть установленная длина и корректные условия завершения.
• Понятность кода.
  • Код прост для понимания.
  • Названия методов не слишком длинные.
• Соответствие кода принятому стилю оформления.
  • Правильно названы пространства имен / классы / методы / переменные.
  • Соблюдены правила именования файлов в соответствии с классами.
  • Соответствует пространство имен класса и физическое расположение файлов.
  • В каждом файле, только один класс.
• Избыточность кода.
  • Отсутствуют повторяющиеся части которые можно вынесть в отдельную функцию.
  • Отсутствуют методы, которые можно в коде заменить на библиотечные функции.
  • Отсутствует закомментированный код.
  • Отсутствуют изменения части кода, предназначенные для отладки.
  • Отсутствуют глобальные / статические переменные от которых можно избавиться или переместить их.
• Независимость кода.
  • Код является независимым, насколько это возможно.
• Обновление конфигурации.
  • При необходимости добавлены изменения в конфигурации.
  • Есть описание изменений к релизу.
  • Доработаны инструменты установки / развертывания (например, в NuGet-пакете).
• Корректная обработка исключений.
  • Исключения используются по предназначению.
  • Сохраняется информация о произошедшей ошибке (например, в лог)
    • Нет пустых блоков catch.
  • Представлены внятные пояснения к произошедшей ошибке.
    • Сообщения локализованы.
• Предусмотрена безопасность.
  • Все входные данные проверяются (на корректный тип, длину, формат, диапазон).
    • Используются для проверки CodeContracts (.NET >= 4.0).
  • Все выходные данные проверяются и при необходимости кодируются (например, от XSS).

Source Control

• Корректные комментарии к коммиту (чекину TFS).
  • Комментарий к коммиту (чекину TFS) отражает внесенные доработки.
  • Система контроля версий используется по прямому назначению (например, не содержит напоминаний вида “не забыть обновить …”, “TODO”)?
• Соответствие комментариев принятым требованиям оформления.
  • Комментарии соответствуют принятым требованиям к оформлению и правилам (русского) языка.
• Атомарность коммита.
  • NB: обычно коммит не атомарен если в его описании присутствует союз “и”.

Документация

• Есть комментарии в коде.
  • Комментарии раскрывают смысл кода.
  • Все функции и их параметры прокомментированы.
• Соответствие комментариев принятым требованиям оформления.
  • Комментарии соответствуют принятым требованиям к оформлению и правилам (русского) языка.
• Сделаны соответствующие пометки в WIKI.
  • Какое-то необычное поведение или описание пограничных случаев задокументировано.
  • Использование и функционирование сторонних библиотек документировано.
  • Все структуры данных и единицы измерения описаны.

Тестирование

• Есть тесты для кода.
  • Тесты есть и они достаточны.
  • Юнит-тесты проверяют, что код предоставляет требуемую функциональность.
  • Создан сценарий тестирования и специальная страница на соответствующем тестовом стенде.
    • Сценарий тестирования добавлен в нужный план тестирования.
    • Сценарий тестирования соответствует принятым требованиям.

Please enable JavaScript to view the comments powered by Disqus.

Обзор кода (code review)

Обзор кода (code review) – один из самых старых и надежных методов выявления дефектов. Он основан на простой идее, используемой во множестве других сфер человеческой деятельности. Если проблему будут решать и обсуждать несколько человек, то они смогут предложить лучшее решение и избежать множества ошибок. Когда человек работает один, то он может даже не догадываться, что допускает явную ошибку или реализует что-то неоптимальным способом.

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

Как правило, обзор кода хорошо работает, так как программисты намного легче замечают ошибки в чужом коде. Также обзор кода носит обучающую составляющую. Участники обсуждения узнают для себя новые приемы программирования, узнают новые паттерны, учатся красиво оформлять код. Более подробно с методикой обзора кода можно познакомиться в замечательной книге Стива Макконнелла «Совершенный код» (Steve McConnell, «Code Complete») [1]. Также можно рекомендовать статью из Wikipedia: Code review [2].

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

Одним из компромиссных решений, которое снижается стоимость анализа кода, является использование специализированных программных инструментов. Эти инструменты выполняют статический анализ кода и рекомендуют программисту обратить своё внимание на определённые фрагменты кода. Так как программы статического анализа кода не обладают искусственным интеллектом, они выполняют анализ хуже, чем это может сделать программист. Зато эти программы работают быстро, не устают и их можно использовать регулярно. Одной из таких программ, является разрабатываемый нами статический анализатор кода PVS-Studio. Особенно полезен, может оказаться режим инкрементального анализа, который запускается автоматически после компиляции изменённых файлов. В результате многие ошибки и опечатки могут быть выявлены на самом раннем этапе.

Другие ресурсы

• Макконнелл С. Совершенный код. Мастер-класс / Пер. с англ. — М. : Издательско-торговый дом «Русская редакция»; СПб.: Питер, 2005. — 896 стр.: ил. ISBN 5-7502-0064-7.
• Wikipedia. Code review. https://en.wikipedia.org/wiki/Code_review

Devart Code Review Bundle (лицензия + подписка на обновления и техподдержку в течение 1 года), 25 пользователей в Ростове-на-Дону

Программное обеспечение Code Review Bundle – набор из двух инструметов: Review Assistant и Code Compare. Набор  Code Review Bundle позволяет просматривать код  Visual Studio, создавать запросы на отзыв и отвечать на них, не покидая эту среду. Помимо этого, решение сравнивает и объединяет разные файлы и папки, интегрируясь со всеми популярными системами управления версиями: TFS, SVN, Git, Mercurial и Perforce.

Review Assistant использует расширение Visual Studio для Code Compare.  Следующие функции доступны только при использовании обоих инструментов: 

• Добавление комментариев к обзору кода при сравнении версий исходного файла.
• Просмотр комментариев с комментариями к файлу сравнения файлов.
• Выделение регионов кода с комментариями к обзору.
• Обзор кода на месте для внешних клиентов контроля версий, таких как TortoiseSVN.

Code Compare предлагает расширенные функции для сравнения исходного кода:

• Инструмент сравнения и сравнения трехстороннего текста.
• Сравнение структурированных кодов.
• Слияние автоматических файлов.
• Обозначение кода (складывание).

Включает в себя Code Compare + Review Assistant. Review Assistant представляет собой мощный инструмент просмотра кода для Visual Studio. Решение поддерживает легкий обзор рабочего процесса и интегрируется с инструментами сравнения кода и системой контроля версий для комфортного процесса просмотра кода. Review Assistant поддерживает Visual Studio 2012 и 2010 и интегрируется с компонентами управления: Team Foundation Server (TFS), Git, Subversion (SVN) и Mercurial (Hg).

✅ Купите Devart Code Review Bundle (лицензия + подписка на обновления и техподдержку в течение 1 года), 25 пользователей на официальном сайте

✅ Лицензия Devart Code Review Bundle (лицензия + подписка на обновления и техподдержку в течение 1 года), 25 пользователей по выгодной цене

✅ Devart Code Review Bundle (лицензия + подписка на обновления и техподдержку в течение 1 года), 25 пользователей, лицензионное программное обеспечение купите в Ростове-на-Дону и других городах России

Предлагаем также:

Доставка в Ростове-на-Дону

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

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

Контакты в Ростове-на-Дону

Интернет магазин Softline

Офис регионального представительства компании находится по адресу: Проспект Михаила Нагибина, д. 30, оф. 204, Ростов-на-Дону, 344038.
Ростове-на-Дону
По работе интернет-магазина обращайтесь по общему телефону: 8 (800) 200-08-60.
Обработка заказов, отправка электронных ключей (лицензий) и физическая доставка осуществляются по рабочим дням, с 9 до 18 часов (Мск).

Как делать хороший Code Review

“code review” с англ. — обзор/просмотр/проверка кода.
Когда я начинал свой путь программиста в качестве junior разработчика, я был счастлив. Моя работа состояла в том, чтобы написать код — проверить его — переписать код. Жизнь была проста и великолепна. Мне нужно было лишь анализировать комментарии к коду, которые я получал в результате code review, и на основе их улучшать свои навыки программирования. Но в один момент моя жизнь изменилась и меня повысили до senior разработчика. Code review стали моим повседневным занятием. Спустя некоторое время я осознал, что несмотря на то, что хорошо пишу код, мне не хватает опыта для качественных code review.

Я уходил в пятки и чувствовал себя самозванцем каждый раз, когда меня просили проверить чей-то код. Несколько вопросов не давали мне покоя:
а) Стоит ли комментировать ту или иную строчку кода.
b) Я знаю способ, как лучше написать этот класс. Стоит ли говорить об этом?
c) Что он подумает, он ведь более опытный разработчик, чем я?
d) Сломаю ли я приложение, если изменю этот блок кода?

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

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

Ставьте цели и определяйте метрики

Если вы не устанавливаете метрики, вы летите вслепую. Если вы устанавливаете их слишком много или чрезмерно концентрируетесь на них, это помешает вашему обзору.

Скотт М. Граффиус

Вообщем-то успех состоит в балансе. Слишком много метрик — пустая трата времени, а их отсутствие похоже на плавание на корабле без компаса. Перед началом code review вы должны решить, как будете измерять эффективность и назвать несколько глобальных целей проверки.
Как правило, хороший код должен быть:
· Функциональным — он должен работать как изначально задумано.
· Чистым и поддерживаемым — он должен быть читабельным.
· Оптимизированным — работа в соответствии с ожиданиями в продакшене.

Метрики должны иметь определенные цели, чтобы гарантировать, что улучшения измеряются и отслеживаются во время и после проверки. Например, «уменьшить количество обращений в службу поддержки на 15%» или «снизить уровень внедрения дефектов на 50% во время разработки». Помните, что цели должны показать количественную картину того, как ваш код улучшается. «Исправить как можно больше ошибок» не является осязаемой целью, которая к тому же не даст никакой ценности.

Управлять (с англ. manage) можно лишь тем, что можно измерить

Альберт Эйнштейн

Критикуйте идеи, а не людей

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

Фрэнк А. Кларк

Почему проверки кода иногда выходят из-под контроля и становятся эмоционально неустойчивыми? Это происходит, когда мы перестаем обсуждать идею и начинаем обсуждать человека, который создал эту идею. Всегда легко сказать: «Рави, ты глуп, почему ты не реализовал код для параллелизма». Но требуется благодать, уравновешенность и зрелость, чтобы сказать: «Мне интересна реализация этого кода. Как он будет обрабатывать параллелизм?»

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

Нет личностному, только профессиональное!

Задавайте вопросы до полного понимания

Вопросы — это первый шаг к изменениям

Кубра Саит

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

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

Code review должен проходить по тому же принципу. Найджел Муньос, бывший full-stack software engineer в Muse, а в настоящее время независимый инженер-программист, рекомендует проверяющему всегда думать о том, «как то или иное изменение повлияет на общую картинку». Общая картина включает стиль и формат кода, его модульность, архитектуру и так далее.

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

Не кормите из ложки

Дай человеку рыбу, и ты накормишь его на день; научи человека ловить рыбу, и ты накормишь его на всю жизнь

Когда вы делаете проверку кода, вы выступаете в роли наставника, а хорошие наставники обучают. Вы должны привести других к решению и мотивировать их решать проблемы самостоятельно. Представьте себя организатором игры «Охота за сокровищами». Вы даете подсказки участникам, указываете правильное направление и, наконец, позволяете им самим разобраться в происходящем. У данного подхода есть ряд преимуществ:
a) Обучение и обмен опытом
b) Разработчик несет полную ответственность за код.
c) Вы воспитываете следующие поколение талантливых проверяющих.

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

Не проверяйте код более 60 минут.

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

Гарри Каспаров

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

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

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

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

В одиночку мы можем сделать так мало; вместе мы можем сделать так много

Хелен Келлер

Спасибо за внимание!

Code review | Teamlead Roadmap

Описание

Code review – это проверка исходного кода на ошибки, проблемы архитектуры.

Почему code review важен?

Помогает:

• Найти баги
• Выявить проблемы в архитектуре
• Сделать код единообразным

А также, что более важно в долгосрочной перспективе:

• Это работающий инструмент для обратной связи
• Участники code review будут учиться на своих и чужих ошибках
• Для оценки hard skills разработчика
• Code review поможет делиться знаниями о технологиях, вариантах решения проблем, возможных проблемах и самом проекте в команде
• Даёт приток новых идей для улучшений в процессах, подходах и автоматизации
• Децентрализация знаний

Что будет, если не делать code review?

Будет плохо продукту:

• Баги на production. Тестирование не найдёт все баги
• Технический долг снежным комомлавиной накрывает проект. Время разработки новых фич увеличивается экспоненциально
• Подходы и архитектура будут несогласованны. Получится Франкенштейн.

Будет плохо lead-у:

• Плохо знает hard skills разработчиков по отдельности
• Не может оценить производительность

Будет плохо разработчикам:

• Без адекватной обратной связи будет ощущение работы «в стол». Демотивация, депрессия, поиск новой работы
• Не будет притока новых знаний о:
  • Проблемах, с которыми уже столкнулись другие. Учиться на чужих ошибках – это быстро и дёшево
  • Технологиях
  • Вариантах решения проблем
  • Самом проекте

На кого можно делегировать code review?

В code review желательно участвовать всем разработчикам проекта.

Примеры поведения

Примеры плохого поведения

• Токсичное поведение
  • Переход на личности
  • Сарказм
  • Раздражение
• Плохо настроенные процессы
  • Неизвестно, кто должен делать code review
  • Неизвестны критерии прохождения. Процесс может продолжаться бесконечно
  • Список правок не разбит на группы по приоритетам
  • Разработчик долго ожидает code review
  • В merge request приходят огромные фичи
• Software используется недостаточно эффективно
  • Не настроены linter-ы и/или автоматические тесты
  • Разработчики пытаются запомнить список правок
• Разработчику непонятно, зачем нужно вносить правки
• Ревьювер не читал задачу в Jira

Примеры хорошего поведения

• Адекватная обратная связь
  • Уточняющие вопросы вместо прямого указания на ошибки
  • Нейтральность или доброжелательность
• Процессы помогают ускорить и упростить code review
  • Разработчики понимают, что в их интересах делать code review
  • Все знают список требований для прохождения code review
  • Список правок удобным образом приоритизирован. Например, с помощью emoji 🔥, 💬
  • Обратная связь – быстрая, в идеале – в течение дня
  • Merge requests атомарные
• Для ускорения используются библиотеки и программы
  • Используются linter-ы и автоматические тесты
  • Разработчики не пытаются запоминать список правок в уме
• Участники code review согласны и понимают причины почему нужно внести правки
• Ревьювер знает бизнес-логику решаемой задачи

Способы прокачки

Практика и способы прокачки

Code review выглядит просто. Проверяете merge request на ошибки и пишете о них, но есть нюанс. Важно понять и принять, что это долгосрочный процесс. Настоящие причины ошибок – пробелы в знаниях, сниженная мотивация. Lead должен включать soft skills, чтобы не стрелять в ногу себе и команде.

Полезно проводить «review» до написания кода, особенно для junior devs. Lead должен убедиться, что разработчик напишет задачу верным способом. Выяснять нужно с помощью уточняющих вопросов.

Умение критиковать

Умение критиковать – это ключевой навык.

Как смягчить критику вербально:

• Задавать уточняющие вопросы вместо прямого указания на ошибки
• Сперва похвалить, затем – критиковать
• Хвалите, если всё хорошо
• Feedback от разработчика о том как прошло review. Да, взять и спросить
• Не говорите «ТЫ сделал плохо»

Практиковаться можно «в уме» на merge request. Когда поняли что научились – давать настоящий feedback.

Как смягчить критику невербально:

• Следите за эмоциональными состояниями: своим и разработчика

Практикуйтесь «в уме» на косячных merge request. Вы не должны злиться и раздражаться на «эти тупые ошибки 😡». Для настоящих review начинайте с хороших merge requests и постепенно переходите к косячным.

Чтобы не злиться самому помогут:

• Понимание себя и истинных причин раздражения
• Понимание что цель не найти баги, а обучить разработчика не делать их снова; или помочь разработчику сменить позицию или компанию на более подходящую
• Психолог
• Успокоительное
• Просто будьте проще, от ваших багов навряд ли кто-то пострадает (с) Капитан Очевидность

Понять что разработчик устал, ненавидит вас, могут помочь:

• Практические книги по психологии
• Психологические тренинги

Дополнительно

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

Процесс review фичи

1. Выяснить, какую бизнес-логику писал разработчик
2. Рассмотреть ключевые элементы бизнес логики, архитектуру решения
3. Углубиться в детали

Нужно выяснить какую бизнес-логику писал разработчик

Об этом могут рассказать разработчик, менеджер или таска в jira. Feedback выдаётся разработчику и/или менеджеру при проблемах с бизнес-логикой.

Чтобы прокачать этот скилл можно пройтись по задачам с описанием.

Чтобы получить косячные задачи, можно:

• Зайти в «achieved»
• Попросить придумать косячные задачи
• Или попросить придумать задачи косячного менеджера

Результат – понимание задачи или аргументы что не так с задачей. Возможно – список на исправление.

Рассмотреть ключевые элементы бизнес логики, архитектуру решения

Об архитектуре решения и ключевых моментах расскажет разработчик. Feedback нужно выдать ему же.

Практиковаться можно на merge request вместе с разработчиком.

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

Результат – понимание и принятие или аргументы:

• Почему это нужно исправить
• Что будет, если не исправить
• Соглашение с разработчиком как исправить

Углубиться в детали

На проекте должен быть linter. Он проверяет отступы, использование необъявленных переменных и другую головную боль.

Если это необходимо – пройдитесь по деталям реализации.

Результат – статус задачи «review закончено» или аргументированный список правок.

Что ревьюить

В зависимости от целей ревью и времени на него:

• Наиболее критичные задачи
• Практики безопасности
• Архитектуру
• Задачи junior devs
• Все задачи
• Выбранное вами

Вы должны чётко осознавать, что именно и зачем вы ревьюите.

Настройка и использование software

Автоматическая проверка кода

Для ускорения процесса нужно настроить проверку кода на:

• Синтаксические ошибки
• Стилистические неточности
• Предполагаемые ошибки во время исполнения (использование необъявленной переменной и тд)
• Возможные уязвимости в коде и используемых библиотеках

Это поможет сократить время на поиск проблем вручную.

Комментарии

Не полагайтесь на память. Git хостинги дают комментировать участки кода, вести дискуссии. Критичные правки можно записывать например в комментарии к merge request.

Можно настроить автоматическую синхронизацию комментариев с мессенджером.

Интеграции

• Git хостинги умеют слать на почту сообщения, связанные с code review
• Можно добавить интеграцию через API, чтобы слать сообщения в мессенджер
  • О новых merge requests
  • Об утверждённых merge requests
  • О merge requests которые долго никто не проверял
  • Комментариях к коду

Работа с другими процессами

• CI/CD. Если встроить code review в процесс CI/CD, то на выходе можно будет получать более надёжный продукт

Вопросы для собеседования

• Blitz
  • Что такое code review?
  • Организован ли у вас в команде code review?
  • Может ли code review помочь найти баги, которые не может найти тестировщик?
• Вопросы «на подумать»
  • Какие плюсы даёт code review в общем и вашей команде?
  • Можно ли не делать code review? В каких случаях?
  • Сколько времени можно тратить на code review?
  • С какими процессами в команде можно интегрировать code review?
  • Во время code review вы увидели токсичное поведение одного из ревьюеров; например, сарказм, грубость. Нужно ли с этим что-то делать? Если да, то что?

Консультации

Теория

Статьи

Раскрывают тему:

Видео

Code Review — Soshace • Soshace

By Pavel Bragin Following Unfollow Follow   1,322 September 19, 2016 Following Unfollow Follow

Code Review проводится в назначенных парах не мене 2 месяцев с даты формирования пары для лучшего понимания проекта поверяющими сторонами.

Таблица результатов ревью здесь.

Советы по Code Review:

Для всеx:

• Просматривайте только самое важное, дайте инструментам сделать все остальное
  Вам не надо спорить о форматировании и кодстайле. Есть множество инструментов, которые последовательно решают эти вопросы. Важно, чтобы код был корректным, понятным и поддерживаемым. Конечно, стиль и форматирование — часть этого, но вы должны дать инструментам проверить эти вещи.
• Каждый должен просматривать код
  Некоторые люди в этом лучше других. Более опытный человек вполне может обнаружить больше ошибок, и это важно. Но более важным является поддержка позитивного отношения к проверке кода в целом, и это позволит избежать отношения «Мы против них», или того, что для ревью кода является обременительным для кого-то.
• Просматривайте весь код
  Нет кода слишком короткого или слишком простого. Если вы просматриваете всё, то ничего не останется пропущенным. Более того, это делает ревью частью процесса, привычкой, а не требованием.
• Усвойте положительное отношение
  Это важно как для ревьюверов, так и для авторов кода. Ревью кода — это не время чтобы получить все пятерки и влиять своим мастерством кодирования.
  Вам не надо принимать оборонительную позицию. Подходите к ревью с позитивным настроем конструктивной критики, и вы сможете построить доверие к этому процессу.

Для ревьюверов:

• Ревью кода должно быть частым и короткими сессиями. Эффективность ваших ревью снижается примерно через час. Так что откладывание ревью, чтобы просмотреть их все в одной громадной сессии не поможет никому. Найдите время в течение дня, совпадающее с вашими перерывами — чтобы не нарушать состояние потока и сформировать привычку. Ваши коллеги будут благодарны вам за это. Ожидание может быть неприятно, и они могут решить вопросы быстрее, пока код еще свеж в их головах.
• Сказать «все хорошо» — это нормально. Не будьте придирчивы, вам не нужно искать проблему в каждом ревью.
• Используйте чеклист. Чеклисты для ревью кода обеспечивают согласованность — они дают убедиться, что каждый отслеживает важные и распространенные ошибки.

Для авторов кода:

• Код должен быть кратким. Через 200 строк кода эффективность кода значительно снижается. К тому времени, когда вы просмотрите 400 строк, они становятся почти бессмысленными.
• Обеспечьте контекст. Давайте ссылки на любые связанные тикеты или спецификации. Есть инструменты для ревью кода типа Kiln, которые помогут с этим. Давайте короткие, но полезные сообщения к коммитам и много комментариев в коде. Это поможет ревьюверу и вы получите меньше вопросов.
  

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

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

Начните использовать и держите в актуальном состоянии

Чек-лист CodeReview

Общее

• Работает ли код? Выполняет ли он свои прямые обязанности, корректна ли логика, и т. д.
• Легок ли код для понимания?
• Соответствует ли код вашему стилю написания кода? Обычно это относится к расположению скобок, названиям переменных и функций, длинам строк, отступам, форматированию и комментариям.
• Есть ли в ревью избыточный или повторяющийся код?
• Является ли код независимым, насколько это возможно?
• Можно ли избавиться от глобальных переменных или переместить их?
• Есть ли закомментированный код?
• У циклов есть установленная длина и корректные условия завершения?
• Может ли что-то в коде быть заменено библиотечными функциями?
• Может ли быть удалена часть кода, предназначенного для логгирования или отладки?

Безопасность

• Все ли входные данные проверяются (на корректный тип, длину, формат, диапазон) и кодируются?
• Обрабатываются ли ошибки при использовании сторонних утилит?
• Выходные данные проверяются и кодируются (прим. пер.: например, от XSS)?
• Обрабатываются ли неверные значения параметров?

Документация

• Есть ли комментарии? Раскрывают ли они смысл кода?
• Все ли функции прокомментированы?
• Есть ли какое-то необычное поведение или описание пограничных случаев?
• Использование и функционирование сторонних библиотек документировано?
• Все ли структуры данных и единицы измерения описаны?
• Есть ли незавершенный код? Если есть, должен ли он быть удален или помечен маркером типа «TODO»?

Тестирование

• Является ли код тестируемым? Например, он не должен содержать слишком много зависимостей или скрывать их, тестовые фреймворки должны иметь возможность использовать методы кода, и т. д.
• Есть ли тесты и если есть, то достаточны ли они? Например, они покрывают код в нужной мере.
• Юнит-тесты на самом деле проверяют, что код предоставляет требуемую функциональность?
• Все ли массивы проверяются на «выход за границы»?
• Может ли любой тестирующий код быть заменен с использованием существующего API?
  

  Успехов!

About the author

Registered 20-10-2015 | Last seen long time ago 1

Vacancies

• PULSE   (Python, Django, MySQL)
• Soshace   (JS, Node. js, Angular, HTML, CSS)
• Soshace   (Laravel, PHP, MySQL, MongoDB, AWS)
• Soshace   (React, JS, HTML, CSS)

Почему проверка кода важна (и на самом деле экономит время!)

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

Итак, что же такое проверка кода?

Когда разработчик заканчивает работу над проблемой, другой разработчик просматривает код и рассматривает такие вопросы, как:

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

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

Что дает гибкая команда?

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

Проверка кода делится знаниями

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

Проверка кода дает более точные оценки

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

Проверка кода включает перерыв

Никто не любит быть единственным контактным лицом по фрагменту кода. Точно так же никто не хочет углубляться в критически важный фрагмент кода, который они не писали — , особенно во время производственной аварии. Проверки кодекса обмениваются знаниями внутри команды, так что любой член команды может взять бразды правления в свои руки и продолжить управление кораблем. (Мы любим смешанные метафоры в Atlassian!) Но вот в чем суть: без единого разработчика критический путь, это также означает, что члены команды могут брать отпуск по мере необходимости. Если вы обнаружите, что привязаны к столу в системе контроля версий, проверка кода — отличный способ обрести свободу.Свобода взять необходимый отпуск или свободу потратить некоторое время на работу над другой областью продукта.

Проверка кода наставляет новых инженеров

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

ProTip:

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

Но проверка кода требует времени!

Конечно, они требуют времени.Но это время не зря потрачено — далеко не так.

Вот три способа оптимизации для этого.

Разделить нагрузку

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

Проверка перед объединением

Требование проверки кода перед объединением в восходящий поток гарантирует, что ни один код не попадет в непроверенный. Это означает, что сомнительные архитектурные решения, принятые в 2 часа ночи, и неправильное использование фабричного шаблона стажерами обнаруживаются до того, как у них появится шанс оказать длительное (и достойное сожаления) влияние на ваше приложение.

Используйте давление со стороны коллег в своих интересах

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

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

Дэн Радиган

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

Как улучшить хороший анализ кода

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

Множество людей и организаций поделились своими передовыми методами проверки кода и тем, что для них означает определение хорошей проверки кода. Гиды от Google, команда SmartBear и инженер Филипп Хауэр — все это отличное чтение. Ниже я расскажу, как выглядят хорошие обзоры кода и как сделать их еще лучше на уровне команды и организации. Это в контексте технической среды, в которой я работал — в настоящее время в Uber, а до этого в Skype / Microsoft и Skyscanner.

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

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

Области, на которые распространяется проверка кода

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

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

Тон обзора

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

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

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

Утверждение и запрос изменений

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

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

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

От анализа кода к разговору друг с другом

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

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

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

Нитпикс

Nitpicks — это неважные комментарии, код которых можно объединить, даже не обращаясь к ним. Это могут быть такие вещи, как объявления переменных, расположенные в алфавитном порядке, модульные тесты, следующие определенной структуре, или скобки, расположенные в одной строке.

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

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

Обзоры кода для новых столяров

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

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

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

Cross-Office, Cross-Time Zone Обзоры

Проверка кода усложняется, когда рецензенты находятся в разных местах. Это особенно сложно, когда рецензенты находятся в разных часовых поясах. Я получил свою долю этих обзоров на протяжении многих лет, изменяя код, принадлежащий командам в США и Азии, находясь в Европе.

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

Улучшенная проверка кода. уведомляет, когда проверки кода неоднократно сталкиваются с проблемами часового пояса и ищут системное решение вне рамок проверки кода. Предположим, команда из Европы часто меняет службу, что вызывает проверку кода владельцем этой службы из США.На системном уровне возникает вопрос, почему эти изменения происходят так часто. Внесены ли изменения в правильную кодовую базу или следует изменить другую систему? Будет ли частота изменений такой же или со временем снизится? Предполагая, что изменения внесены в правильную кодовую базу и частота не будет снижаться, можно ли каким-то образом нарушить межведомственную зависимость? Решения такого рода проблем часто непросты и могут включать рефакторинг, создание новых сервисов / интерфейсов или улучшение инструментов.Но решение таких зависимостей упростит жизнь обеим командам, а их прогресс — более эффективным в долгосрочной перспективе, а это означает, что окупаемость инвестиций зачастую весьма впечатляет.

Организационная поддержка

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

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

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

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

Начни с хорошего, сделай лучше

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

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

——-

Гергели в настоящее время является ведущим инженером в Амстердаме. Эта запись изначально была опубликована в блоге Гергели: The Pragmatic Engineer . Если вы хотите узнать больше о Гергели, вы можете подписаться на его ежемесячный информационный бюллетень , где вы найдете его статьи по проектированию, техническому лидерству и распределенным системам. Если вы хотите публиковать статьи в блоге Stack Overflow, отправьте электронное письмо по адресу [email protected].

Теги: бюллетень, обзор кода, инженерия, разработка программного обеспечения

Как создать руководство по обзору кода

Этот пост адаптирован из выступления на FutureStack18 в Сан-Франциско под названием «Основные правила проверки кода.”

После проекта New Relic Project Upscale — новаторской реорганизации, призванной сделать наши команды разработчиков более автономными — инженерная организация сформировала несколько новых команд, одной из которых была команда New Relic Database (NRDB). Как следует из названия, команда NRDB отвечает за разработку нашей базы данных событий, которая поддерживает инструмент New Relic Insights, а также несколько других продуктов.

Когда мы сформировали команду NRDB, в ее состав входило несколько инженеров-программистов старшего уровня.Это была высококвалифицированная и очень увлеченная группа разработчиков, которая просматривала запросы на включение запросов друг друга.

Когда страсть становится ядовитой

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

В примере слева рецензент оставил PR в промежуточном состоянии.Они не отвергали его явно, но и не одобряли. В примере справа рецензент сделал очень субъективный запрос, а автор просто внес изменение, но по его тону можно предположить, что он не оценил отзыв.

В результате разработчики команды NRDB становились все более разочарованными, доверие к команде подрывалось, и несколько участников (включая меня) подумывали о переходе в другие команды. У нас были проблемы.

Улучшение нашего процесса — и спасение команды

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

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

Ошибочный подход к процессу проверки кода

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

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

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

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

Борьба за субъективность

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

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

Однако редакторы

и IDE не могут обнаружить — или помешать разработчикам сосредоточиться на таких субъективных проблемах, как запутанные названия методов, сомнительные предпочтения стиля и неправильное форматирование переменных. И когда нам не нравится и не соглашается с тем, что мы находим в таких случаях, мы часто забываем, что эти «недостатки» являются субъективными мнениями, а не объективными фактами.

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

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

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

Наши четыре руководства по проверке кода

Это возвращает нас к руководствам, которые мы разработали для управления субъективными элементами процесса проверки кода командой NRDB.

Во-первых, в качестве предварительного шага к нашим четырем руководящим принципам мы договорились определить , кто в конечном итоге несет ответственность за правильное выполнение любых изменений кода .Это было важно для нас, потому что в субъективных дебатах мнение человека, на котором лежит основная ответственность — другими словами, проверка выполнения кода — должно иметь наибольший вес. В результате мы решили, что «Автор изменения кода несет ответственность за правильное выполнение изменения».

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

Мы обнаружили, что субъективные комментарии чаще всего представлялись как объективная обратная связь на этапе запроса на вытягивание процесса. В результате на этом мы сосредоточили наши рекомендации по проверке кода.

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

1. Проверяющий должен выявить ошибки, которые вызовут проблемы в производственной среде. В конце концов, это проверка кода, поэтому проверяющий должен определить недостающие точки с запятой, бесконечные циклы или недостающую обработку ошибок. Рецензенты не несут ответственности за обнаружение всех таких ошибок (это все еще ответственность автора), но они должны искать очевидные проблемы, которые нарушат работу системы, если они будут внедрены в производственную среду. Такие проблемы являются веской причиной для блокировки запроса на перенос.
2. Рецензент должен убедиться, что заявленная цель изменения кода согласуется с вносимыми изменениями. Если автор отправляет запрос на вытягивание, в котором говорится, что он вносит изменения в сетевой код службы, рецензенты должны ожидать, что все изменения связаны с сетевым кодом службы и вокруг него. Это кажется очевидным, но не секрет, что в таких случаях разработчики имеют тенденцию пытаться внести несколько изменений. Это даже не обязательно неправильная практика, если изменения в основном совпадают. Однако когда вы согласовываете изменение кода с заявленной целью, вы упрощаете определение того, может ли запрос на вытягивание отправлять какие-либо новые ошибки.Здесь мы также согласились с тем, что неспособность согласовать изменение кода с заявленной целью будет оправданием блокировки запроса на перенос.
3. Рецензент должен убедиться, что любые изменения соответствуют стандартам кодирования команды. Я расскажу об этом чуть позже, но в качестве примера, если команда решила, что все переменные должны использовать регистр верблюда, и рецензент находит переменную, в которой не используется регистр верблюда, он должен заблокировать запрос на вытягивание.
4. Рецензент должен искать все, с чем он лично не согласен. Это руководство касается любых комментариев, не охваченных первыми тремя правилами. Мы, , хотим, чтобы рецензентов оставили отзывы, даже если они не подпадают под первые три правила. Мы не хотели, чтобы наши правила подавляли обратную связь, которая необходима для того, чтобы мы учились друг у друга. Однако, поскольку эти комментарии явно субъективны, мы согласились, что они не оправдывают блокировку запроса на перенос.

Чтобы устранить всю путаницу, мы просим рецензентов обозначать свои комментарии как блокирующие или неблокирующие; и добавлять эти комментарии как теги в свои обзоры.Например:

Объективные комментарии

• «Блокировка: отсутствует точка с запятой».
• «Блокировка: этот цикл никогда не заканчивается».
• «Блокировка: здесь не хватает обработки ошибок»

Субъективные комментарии

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

Работа в рамках наших рекомендаций по проверке кода

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

1. Код, созданный нашей командой, не обязательно должен быть единообразным. Это означало преодоление тенденции в нашей отрасли, согласно которой вы должны стремиться удалить из своего кода все отпечатки пальцев, которые определяют, кто какую часть написал. Мы обнаружили, что рентабельность инвестиций при следовании этой тенденции была довольно низкой, и попытки сделать это только что привели нас к тому же субъективному спору: если разработчик пишет код способом, немного отличным от его коллег, означает ли это, что код неправильный? Очевидно, мы решили, что это не , объектив , корпус .
2. Если рецензент добавляет неблокирующий отзыв, автору следует уделить время его рассмотрению. Вначале некоторые члены команды были обеспокоены тем, что авторы просто проигнорируют все неблокирующие комментарии, поскольку их код больше не блокируется субъективной обратной связью. Тогда мы решили повторить, что «мы доверяем нашим товарищам по команде». Если, как рецензенты, мы нашли время, чтобы ввести комментарий, мы, , доверяли , что автор найдет время, чтобы прочитать и рассмотреть его.

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

Спонсорство стандарта кодирования

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

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

1. Мы не можем описывать стандарты кодирования на субъективном языке. Например, спонсор не может сказать: «переменные не должны быть неоднозначными», поскольку неоднозначность является субъективной. Но спонсор может добавить стандарт, который гласит, что «переменные должны использовать венгерскую нотацию», поскольку это объективно и легко реализуемо.
2. I Если вы спонсируете стандарт кодирования, вы должны его поддерживать. Спонсор должен предоставить необходимую документацию и провести обучение. Если существует плагин или другой инструмент, который необходимо установить команде, спонсор несет ответственность за его поддержку. Это ограничение гарантирует, что спонсор увлечен всем, что он хочет добавить к стандартам кодирования команды.

Поиск уважения и компромисса при проверке кода

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

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

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

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

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

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

Эти рекомендации помогают в автономии команды

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

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

Привнесение здорового образа мыслей в вашу команду — Smashing Magazine

Об авторе

Сандрина Перейра (Sandrina Pereira) — интерфейсный разработчик, который помогает превращать идеи в доступный опыт. Кроме того, у нее вечный роман с миром дизайна, так что …
Больше о
Сандрина
↬

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

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

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

В этой статье я расскажу, как этот результат можно изменить, если изменит ваше мышление во время проверки кода:

👩‍💻👨‍💻 Работа в команде

Развитие культуры сотрудничества

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

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

Включите проверку кода в свои оценки

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

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

Экономьте время с помощью инструкций и автоматизации

Эффективный способ гарантировать единообразие вкладов — это интегрировать шаблон запроса на включение в проект. Это поможет автору подать здоровый PR с полным описанием. PR-описание должно объяснять, какова цель изменения, причина этого и как ее воспроизвести. Снимки экрана и справочные ссылки (проблема Git, файл дизайна и т. Д.) — это последние штрихи для не требующей пояснений отправки.

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

Остаться студентом

Любой может выполнить проверку кода, и каждый должен пройти проверку кода — независимо от уровня стажа. С благодарностью принимайте любые отзывы как возможность учиться и делиться знаниями. Смотрите на любую обратную связь как на открытое обсуждение , а не как на защитную реакцию. Как говорит Райан Холидей:

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

— Райан Холидей, Эго — враг

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

Искусство выбора рецензентов

На мой взгляд, выбор рецензентов — одно из наиболее важных решений для эффективного и здорового рецензирования кода в команде.

Допустим, ваш коллега отправляет обзор кода и решает пометить «всех», потому что бессознательно он / она может захотеть ускорить процесс, предоставить наилучший возможный код или убедиться, что все знают об изменении кода. Каждый из рецензентов получает уведомление, затем открывает PR-ссылку и видит множество людей, отмеченных как рецензенты. Мысль «кто-то другой сделает это» всплывает в их головах, что приводит к игнорированию проверки кода и закрытию ссылки.

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

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

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

Имейте сочувствие

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

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

Умейте идти на компромисс

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

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

Проверка кода при личной встрече

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

Учитесь на основе результатов проверки кода

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

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

📝 Как автор

Одна из основных проблем при работе над обзором кода в качестве автора — минимизировать удивление рецензента при первом чтении кода. Это первый шаг к предсказуемой и беспроблемной проверке кода. Вот как это сделать.

Наладьте раннее общение

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

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

Следуйте рекомендациям

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

Будьте вашим первым рецензентом

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

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

Будьте терпеливы

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

Будьте слушателем

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

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

👀 Как рецензент

Планируйте заранее

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

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

Поддерживайте

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

Проверьте ветвь и запустите ее

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

Спросите, прежде чем предполагать

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

Большинство вопросов попадают в эти два типа категорий:

1. «Как» Вопросы
   Если вы не понимаете, как что-то работает или что делает, оцените вместе с автором, достаточно ли ясен код.Не путайте простой код с незнанием. Есть разница между кодом, который трудно читать, и кодом, о котором вы не знаете. Будьте открыты для изучения и использования новой языковой функции, даже если вы еще не очень хорошо ее знаете. Однако используйте его, только если он упрощает кодовую базу.
2. Вопросы «Почему?»
   Если вы не понимаете «почему», не бойтесь предлагать комментировать код, особенно если это крайний случай или исправление ошибки. Код должен быть понятным, когда доходит до объяснения того, что он делает.Комментарии — это дополнение к объяснению причин, лежащих в основе определенного подхода. Объяснение контекста очень ценно, когда дело доходит до ремонтопригодности, и это спасет кого-то от удаления блока кода, который считался бесполезным. (Лично мне нравится комментировать код, пока я не почувствую себя в безопасности, чтобы забыть его позже.)

Конструктивная критика

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

• Открытые обсуждения.
  Избегайте оформления своего отзыва в виде приказа или обвинения, например «Вам следует…» или «Вы забыли…». Выразите свой отзыв как открытое обсуждение, а не как обязательный запрос. Не забудьте комментировать код, а не автора. Если комментарий не о коде, его не следует использовать при проверке кода. Как было сказано ранее, проявите поддержку. Использование пассивного залога, использование множественного числа, вопросы или предложения — хорошие способы подчеркнуть сочувствие автору.

Вместо «Извлечь этот метод отсюда…» предпочтительнее «Этот метод следует извлечь…» или «Что вы думаете об извлечении этого метода…»

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

Неясно: «Этот код должен быть…»

Мнение: «Я считаю, что этот код должен быть…»

Факт: «Согласно [нашим рекомендациям] этот код должен быть…».

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

Мнение: «Я считаю, что этот код может быть…»

Объяснил: «Я считаю, что этот код может быть (…), потому что это улучшит читаемость и упростит модульные тесты».

• Приведите примеры.
  При публикации функции кода или шаблона, с которым автор не знаком, дополните свое предложение ссылкой в ​​качестве руководства. По возможности выйдите за рамки документации MDN и поделитесь фрагментом или рабочим примером, адаптированным к текущему сценарию кода. Если написание слишком сложного примера, окажет поддержку, и предложит помощь лично или посредством видеозвонка.

Помимо таких слов, как «Использование фильтра поможет нам [мотивация]», также скажите: «В этом случае это может быть что-то вроде: [фрагмент кода].Вы можете проверить [пример на Finder.js]. Если есть сомнения, не стесняйтесь пинговать меня в Slack ».

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

Keep The Focus

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

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

Задайте ожидания

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

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

Научитесь отказываться от проверки кода

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

Когда вы соглашаетесь пересмотреть чужой код, этот человек доверяет вашим возможностям — это обязательство. Если у вас нет времени на рецензирование, просто скажите нет своему коллеге (коллегам). Я действительно серьезно; не позволяйте коллегам ждать проверки кода, которая никогда не будет выполнена. Не забывайте сообщать и четко выражать свои ожидания . Будьте честны со своей командой и, что еще лучше, с собой. Независимо от вашего выбора, делайте это правильно и правильно.

Заключение

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

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

Дополнительная литература по SmashingMag:

(ra, yk, il)

12 лучших инструментов для проверки кода для разработчиков (издание 2021 г.)

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

Эффективная проверка кода предотвращает попадание ошибок и ошибок в ваш проект за счет повышения качества кода на ранней стадии процесса разработки программного обеспечения.

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

Что такое процесс проверки кода?

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

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

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

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

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

Сделайте ваш отзыв информативным

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

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

Почему проверка кода важна?

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

Проверка кода важна по следующим причинам:

• Убедитесь, что в коде нет ошибок.
• Сведите к минимуму вероятность возникновения проблем.
• Подтвердите, что новый код соответствует рекомендациям.
• Повышение эффективности нового кода.

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

Как выполнить проверку кода?

Существует четыре способа проверки кодекса.

Обзоры кода через плечо

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

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

Передача электронной почты

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

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

Передача электронной почты через группы Google при каждом новом нажатии

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

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

Программирование пар

Парное программирование иногда может быть неэффективным

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

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

С помощью инструмента

Процесс проверки кода с помощью инструментов включает использование специального инструмента для облегчения процесса проверки кода.Инструмент обычно помогает вам со следующими задачами:

• Организуйте и отображайте обновленные файлы в изменении.
• Облегчите разговор между рецензентами и разработчиками.
• Оцените эффективность процесса проверки кода с помощью показателей.

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

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

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

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

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

При разработке программного обеспечения существует два типа тестирования кода: динамическое и статическое.

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

Теперь давайте погрузимся в некоторые из самых популярных инструментов проверки кода!

Более подробный взгляд на 12 эффективных инструментов проверки кода

В этом разделе мы рассмотрим самые популярные инструменты статической проверки кода.

1. Контрольный совет

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

Обзор

Обзор Совета

Язык программирования Python и его установщики, MySQL или PostgreSQL в качестве базы данных и веб-сервер являются предварительными условиями для запуска Review Board на сервере.

Вы можете интегрировать Review Board с широким спектром систем контроля версий — Git, Mercurial, CVS, Subversion и Perforce. Вы также можете связать Review Board с Amazon S3 для хранения снимков экрана непосредственно в инструменте.

Обзор изменений в совете Обзор

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

Также предоставляется графическое сравнение изменений в вашем коде. Помимо проверки кода, Review Board позволяет также проводить проверки документов.

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

Review Board — это простой инструмент для проверки кода, который вы можете разместить на своем сервере.Вам следует попробовать, если вы не хотите размещать свой код на общедоступном веб-сайте.

2. Тигель

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

Crucible предлагает два плана платежей: один для небольших команд, а другой — для предприятий. Для небольшой команды вам необходимо сделать единовременный платеж в размере 10 долларов за неограниченное количество репозиториев, ограниченное пятью пользователями.Для больших команд плата начинается от 1100 долларов за десять пользователей и неограниченное количество репозиториев.

Оба этих плана предлагают 30-дневную бесплатную пробную версию без кредитной карты.

Инструмент проверки кода Crucible (Источник)

Как и Review Board, Crucible поддерживает большое количество систем контроля версий — SVN, Git, Mercurial, CVS и Perforce. Его основная функция — дать вам возможность выполнять обзоры кода. Помимо общих комментариев к коду, он позволяет вам делать встроенные комментарии в представлении различий, чтобы точно указать, о чем вы конкретно говорите.

Crucible хорошо интегрируется с другими корпоративными продуктами Atlassian, такими как Confluence и Enterprise BitBucket. Однако вы, возможно, получите максимальную пользу от Crucible, если будете использовать его вместе с Jira, Atlassian Issue и Project Tracker. Он позволяет выполнять проверки и аудит объединенного кода перед фиксацией.

3. GitHub

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

Инструмент проверки кода GitHub в запросе на слияние

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

Подпишитесь на информационный бюллетень

Мы увеличили наш трафик на 1187% с помощью WordPress.

Мы покажем вам, как это сделать.

Присоединяйтесь к более чем 20 000 других людей, которые получают нашу еженедельную рассылку с советами по WordPress!

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

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

Инструмент проверки кода GitHub — отличный инструмент, если вы уже используете эту платформу. Не требует дополнительной установки или настройки. Основная проблема с инструментом проверки кода GitHub заключается в том, что он поддерживает только репозитории Git, размещенные на GitHub. Если вы ищете аналогичный инструмент для проверки кода, который можно загрузить и разместить на своем сервере, вы можете попробовать GitLab.

4. Фабрикатор

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

У вас нет ограничений, если вы устанавливаете его на свой сервер. Однако с вас будет взиматься плата в размере 20 долларов США за пользователя в месяц (максимальная сумма — 1000 долларов США в месяц), включая поддержку. Чтобы попробовать, вы можете выбрать 30-дневную бесплатную пробную версию.

Фабрикатор

Phabricator поддерживает три самых популярных системы контроля версий — Git, Mercurial и SVN. Он может управлять локальными репозиториями, а также отслеживать внешние репозитории. Вы также можете масштабировать его на несколько серверов.

Помимо традиционного инструмента проверки кода

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

Дополнительные инструменты

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

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

5. Сотрудник

Collaborator от SmartBear — это инструмент коллегиального кода и проверки документов для команд разработчиков. В дополнение к обзору исходного кода Collaborator позволяет командам также проверять проектную документацию.Стоимость пакета лицензий на 5 пользователей составляет 535 долларов в год. Бесплатная пробная версия доступна в зависимости от требований вашего бизнеса.

Источник обзора соавтора

Collaborator поддерживает большое количество систем контроля версий, таких как Subversion, Git, CVS, Mercurial, Perforce и TFS. Он хорошо интегрируется с популярными инструментами управления проектами и IDE, такими как Jira, Eclipse и Visual Studio.

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

6. CodeScene

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

Облачные планы

CodeScene начинаются бесплатно для общедоступных репозиториев, размещенных на GitHub. Для десяти частных репозиториев и команды из десяти человек CodeScene стоит 99 евро (около 115 долларов США) в месяц. Локальная установка CodeScene стоит 15 евро (около 17 долларов США) на разработчика в месяц.

Инструмент проверки кода CodeScene Анализ

CodeScene обрабатывает вашу историю управления версиями для визуализации кода. В дополнение к этому он применяет алгоритмы машинного обучения для выявления социальных шаблонов и скрытых рисков в коде.

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

Карты знаний CodeScene

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

7. Визуальный эксперт

Visual Expert — это корпоративное решение для анализа кода, специализирующееся на коде базы данных. Он поддерживает только три платформы: PowerBuilder, SQL Server и Oracle PL / SQL. Если вы используете любую другую СУБД, вы не сможете интегрировать Visual Expert для проверки кода.

Доступна бесплатная пробная версия, но вам нужно отправить запрос, чтобы узнать цену на нее.

Обзор инструмента Visual Expert Code Review Tool (Источник)

В дополнение к традиционному обзору кода Visual Expert анализирует каждое изменение в вашем коде, чтобы предвидеть любые проблемы с производительностью, связанные с изменениями. Инструмент также может автоматически генерировать полную документацию вашего приложения из кода.

Если вы используете PowerBuilder, SQL Server или Oracle PL / SQL и вам нужен специализированный инструмент проверки кода для своих нужд, вам следует попробовать Visual Expert (вот руководство по созданию эффективных запросов WordPress).

8. Геррит

Gerrit — это бесплатный веб-инструмент с открытым исходным кодом для проверки кода для репозиториев Git, написанный на Java. Чтобы запустить Gerrit, вам необходимо загрузить исходный код и запустить его на Java. Вот процесс установки автономной версии Gerrit.

Инструмент проверки кода Gerrit

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

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

9. Род-код

Rhodecode — это веб-инструмент, который помогает выполнять обзоры кода. Он поддерживает три системы контроля версий: Mercurial, Git и Subversion.Облачная версия Rhodecode начинается с 8 долларов за пользователя в месяц, тогда как локальное решение стоит 75 долларов за пользователя в год. Хотя это корпоративное программное обеспечение, его бесплатная версия для сообщества с открытым исходным кодом может быть загружена и скомпилирована бесплатно.

Род-код

Rhodecode позволяет команде эффективно сотрудничать посредством итеративных диалоговых обзоров кода для повышения качества кода. Этот инструмент дополнительно обеспечивает уровень управления разрешениями для безопасной разработки.

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

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

10.Veracode

Veracode предоставляет набор инструментов проверки кода, которые позволяют автоматизировать тестирование, ускорить разработку, интегрировать процесс исправления и повысить эффективность вашего проекта. Набор инструментов проверки кода от Veracode позиционируется как решение безопасности, которое ищет уязвимости в ваших системах. Они предоставляют набор из двух инструментов проверки кода:

Обзор Veracode (Источник)

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

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

11. Подлежит проверке

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

Обзор инструмента обзора кода

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

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

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

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

12. Партнерская проверка Trac

Если вы используете Subversion, плагин Peer Review для Trac предоставляет бесплатный вариант с открытым исходным кодом для проведения обзоров кода ваших проектов. Плагин Peer Review интегрируется в проект с открытым исходным кодом Trac, который представляет собой вики-страницу и систему отслеживания проблем для проектов разработки.

Плагин Peer Review для Trac Overview (Источник)

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

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

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

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

Сводка

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

Мы внимательно посмотрели на самые популярные инструменты проверки кода, доступные в 2021 году, и вот что мы обнаружили:

• Для небольшой команды, которая только начинает работать, Review Board — хороший выбор для начала процесса проверки кода.
• Если вы ищете инструмент для проверки кода с открытым исходным кодом, попробуйте Gerrit, Peer Review for Trac или версию Rhodocode для сообщества.
• Вы ищете довольно простой в использовании инструмент проверки кода с поддержкой? Вам следует попробовать Rhodecode.
• Если вы используете Git и GitHub для управления своей кодовой базой, попробуйте встроенный редактор кода GitHub. Если вы хотите выйти за рамки основных функций запросов на вытягивание, вам следует проверить Reviewable.
• Принадлежите ли вы к команде, которая использует Oracle, SQL Server или PowerBuilder для управления кодом вашей базы данных? Вы можете попробовать Visual Expert, инструмент проверки кода, который специализируется на коде базы данных.
• Если вы ищете корпоративное решение, попробуйте Atlassian’s Crucible, SmartBear’s Collaborator или Veracode.
• Если вы хотите использовать машинное обучение и искусственный интеллект, чтобы выйти за рамки анализа кода и перейти к поведенческому анализу, вам следует попробовать CodeScene.
• Если вам нужно полное решение для цикла разработки программного обеспечения, ознакомьтесь с набором инструментов Phabricator для проверки кода и не только.

Теперь ваша очередь: какой инструмент проверки кода вы используете? Зачем? Напишите нам в комментариях!

Рекомендуемое чтение: 13 основных языков сценариев, на которые следует обратить внимание

Если вам понравилась эта статья, то вам понравится хостинговая платформа Kinsta WordPress.Ускорьте свой сайт и получите круглосуточную поддержку от нашей опытной команды WordPress. Наша инфраструктура на базе Google Cloud ориентирована на автоматическое масштабирование, производительность и безопасность. Позвольте нам показать вам разницу Kinsta! Ознакомьтесь с нашими тарифами

Возможности

· Обзор кода · Возможности GitHub

· Обзор кода · GitHub

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

Запуск с запросом на вытягивание

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

Внести изменения

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

Изучите основы запроса на вытягивание →

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

Отличия

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

Узнайте, как сравнивать ветки с различиями →

История

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

Совет: вы можете искать в своей истории коммитов по ключевому слову, коммитеру, организации и т. Д.

Виноват

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

Совет: используйте git blame , чтобы отслеживать изменения в файле.

Обсудить код

Комментарии

На GitHub диалоги происходят вместе с вашим кодом.Оставляйте подробные комментарии по синтаксису кода и задавайте вопросы о встроенной структуре.

Запросы на пересмотр

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

Обзоры

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

Разрешить простые конфликты

Не всегда удается избежать конфликта. Объединяйте запросы на вытягивание быстрее, разрешая простые конфликты слияния на GitHub — командная строка не требуется.

Узнайте, как разрешать конфликты слияния на GitHub и с помощью командной строки.

Объедините код высочайшего качества

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

Разрешения

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

Посмотреть варианты плана →

Охраняемые филиалы

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

Необходимые проверки статуса

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

Пуленепробиваемый процесс проверки

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

Кодеков

Группировать, объединять, архивировать и сравнивать отчеты о покрытии

Codacy

Автоматическая проверка кода, помогающая разработчикам выпускать более качественное программное обеспечение и быстрее

Комбинезоны

Убедитесь, что новый код полностью покрыт, и посмотрите, как появляются тенденции покрытия

Начать

Свободный
Команда
Предприятие
GitHub One

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

4 преимущества аутсорсинга проверки кода
| Блог PullRequest

Фото Hack Capital на Unsplash

Если вы хотите писать чистый, поддерживаемый код, вам нужна проверка кода.

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

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

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

1. Более качественная проверка кода с меньшим количеством ушибленных эго

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

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

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

Проверка кода на стороне позволяет вашей команде сделать качество кода приоритетом.

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

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

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

2. Более быстрый процесс с меньшим количеством ошибок

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

Источник

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

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

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

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

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

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

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

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

3. Лучшее обнаружение и исправление ошибок

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

Когда дело доходит до соответствия требованиям и безопасности, проверка кода может помочь в разнице между тем, что нравится, и тем, что создает проблемы для вашей компании или ваших пользователей. Open Web Application Security Project, некоммерческий проект программного обеспечения с открытым исходным кодом, утверждает, что «проверка кода, вероятно, является самым эффективным методом выявления недостатков безопасности».

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

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

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

4. Снижение затрат в краткосрочной и долгосрочной перспективе

Проактивность в отношении качества кода экономит деньги.

Исследования Stripe и Harris Poll показывают, что технические долги и проблемы с обслуживанием могут отнимать до 42% времени разработчика:

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

Эта альтернативная стоимость становится выше для каждой ошибки.Исследования IBM показали, что исправлять ошибки во время тестирования в 15 раз дороже, а исправлять ошибки во время реализации в 6 раз дороже, чем их обнаружение во время проектирования. Чем больше вы можете уделять первоочередное внимание качеству кода в процессе разработки, тем дешевле становится проверка кода.

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

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

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

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