Error program review

Code review is one of the oldest and most reliable methods of defect detection. It is based on the simple idea used in many other areas of human life: if a problem is being discussed and solved by several people, they will be able to work out a better solution and avoid many mistakes. When one is working alone, one may even not suspect he/she is making an obvious mistake or realizing something in a non-optimal way.

The code review method implies collaborative attentive reading of source code and suggesting recommendations on improving it. Errors or potentially incorrect code fragments are detected during the process of code review. It is also accepted that the author of the code shouldn’t give any explanations on how a certain part of the program works. The execution algorithm should be clear directly from the program text and comments. If the code doesn’t meet this condition, it should be revised.

Code review is usually an effective method, as programmers notice errors in another’s code easier than in their own. Code review also fulfills an educational purpose: programmers participating in the review learn new programming methods, patterns and good coding styles. To learn more about the code review method see a wonderful book by Steve McConnell «Code Complete» [1]. The Wikipedia article might be of interest too: Code review [2].

The only yet great disadvantage of this method is its high cost. You need to gather several programmers regularly to review fresh code or re-review revised code. It distracts programmers from their own tasks and requires their focusing on the new work. At the same time, they need regular breaks. If you try to review large code fragments at once, your attention quickly weakens and the benefit of code review decreases as quickly. As a result, a great many man-hours are spent on code review.

A compromise solution that helps reduce the price of code analysis is using specialized software tools. These tools perform static code analysis and give recommendations to the programmer on which code fragments to consider. Since static analyzers don’t possess AI, they perform analysis worse than a programmer. On the other hand, these tools work fast, don’t get tired and can be used regularly. The static code analyzer PVS-Studio developed by our company is one of these programs. It has an especially useful mode of incremental analysis which is launched automatically after compiling modified files. Consequently, many bugs and misprints can be caught very early.

References

• Steve McConnell, «Code Complete, 2nd Edition» Microsoft Press, Paperback, 2nd edition, Published June 2004, 914 pages, ISBN: 0-7356-1967-0.
• Wikipedia. Code review. https://en.wikipedia.org/wiki/Code_review

Время прочтения
14 мин

Просмотры 209K

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

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

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

• Обсуждение проблем с сочувствием и пониманием.
• Помощь партнёру в устранении недостатков.

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

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

Так почему мы проводим code review таким образом?

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

Я собираюсь сделать смелое предположение, что вам хотелось бы улучшить code review в настоящем, где вы работаете с людьми, а не с роботами. Даже более смелое предположение, что хорошие отношения с коллегами — это главная цель, а не просто переменная для ускорения исправления ошибок (минимизации параметра cost-per-defect). Как бы изменились ваши методы ревью с учётом этих обстоятельств?

В этой статье обсудим техники, которые предполагают, что code review — не только технический, но и социальный процесс.

Что такое code review?

Термин “code review” может означать разные действия, от простого чтения какого-то кода из-за спины разработчика до совещания на 20 человек, где вы разбираете код строчка за строчкой. Я здесь имею в виду формальную и письменную процедуру, но не отягощённую рядом совещаний для инспекции кода.

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

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

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

Ревью завершается, когда рецензент одобряет изменения. Обычно этому сопутствует отправка сообщения LGTM, сокращённой фразы “looks good to me”.

Почему это так трудно?

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

«Это одна из причин, почему я не скучаю по IT, ведь программисты — весьма малопривлекательные люди… Например, в авиации те, кто слишком переоценивают свои способности, уже мертвы».

Филип Гринспан, сооснователь ArsDigita, из книги «Основатели за работой».

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

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

Техники

1. Отдайте компьютерам скучную часть работы
2. Оформите аргументы по стилю в виде руководства по стилю
3. Начинайте ревью немедленно
4. Начните с высокого уровня, и спускайтесь ниже
5. Щедро используйте примеры кода
6. Никогда не говорите «ты»
7. Оформляйте отзывы как запросы, а не команды
8. Обосновывайте принципами, а не мнениями

Отдайте компьютерам скучную часть работы

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

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

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

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

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

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

Нужно всем вместе поработать, чтобы внедрить автоматические проверки такого рода в рабочий процесс code review (например, хуки перед коммитами в Git или вебхуки в GitHub). Если процесс ревью требует от автора запускать такие проверки вручную, то вы лишаетесь большей части преимуществ. Автор неизбежно иногда будет забывать о проверке, из-за чего вам придётся возиться с с простыми ошибками, которые могла исправить автоматическая проверка.

Оформите аргументы по стилю в виде руководства по стилю

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

Хорошее руководство по стилю определяет не только внешние элементы оформления вроде соглашения о присвоении имён или правила отступов, но и как использовать функции данного языка программирования. Например, JavaScript и Perl набиты функциональностью — там есть много вариантов реализации одной и той же логики. Руководство по стилю определяет Один Правильный Способ программирования, так что вы больше не увидите, что одна половина вашей команды использует один набор функций языка, а другая половина — совершенно другой набор функций.

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

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

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

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

Я предпочитаю держать наше руководство в формате Markdown в системе контроля версия (например, на GitHub Pages). Так все изменения проходят через стандартную процедуру рецензирования — кто-то должен явно одобрить изменения, а каждый в команде может поднять любую проблему. Вики и Google Docs тоже подходят.

Вариант 3: Гибридный подход
Сочетая варианты 1 и 2, вы можете адаптировать существующее руководство и одновременно вести локальный документ для расширения или перезаписи базы. Хороший пример — руководство Chromium C++. Там в качестве базы взяли руководство по C++ от Google, но сделали собственные изменения и дополнения.

Начинайте ревью немедленно

Расценивайте code reviews как задачу с высоким приоритетом. Когда вы изучаете код или пишете отзыв, не торопитесь, но начинайте делать это немедленно — в идеале, в течение нескольких минут.

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

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

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

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

Начните с высокого уровня, и спускайтесь ниже

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

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

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

Щедро используйте примеры кода

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

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

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

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

urls = []
for path in paths:
  url = 'https://'
  url += domain
  url += path
  urls.append(url)

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

Автор будет гораздо счастливее получить такую заметку:

Предлагаю рассмотреть списковое включение такого рода:

urls = ['https://' + domain + path for path in paths]

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

Применяйте эту технику только для ясных, бесспорных улучшений. В вышеприведённом примере спискового включения немногие разработчики будут спорить с сокращением количества строк кода на 83%. И наоборот, если вы напишете пространный пример для демонстрации изменения, которое «лучше» на ваш личный вкус (например, изменения стиля), то такой пример кода создаст впечатление, что вы настырно проталкиваете свои предпочтения, а не проявляете щедрость.

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

Никогда не говорите «ты»

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

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

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

Например, вот безобидный комментарий:

Ты допустил ошибку в слове «благополучно».

Автор может интерпретировать такое замечание двумя соврешенно разными способами:

• Интерпретация 1: Эй, приятель! Ты неправильно написал слово «благополучно». Но я всё равно считаю, что ты умный! Вероятно, это просто опечатка.
• Интерпретация 2: Ты допустил ошибку в слове «благополучно», придурок.

Сравните это с замечанием, в котором отсутствует обращение «ты»:

sucessfully -> successfully

Вторая заметка — это просто исправление, а не оценка автора.

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

Вариант 1: Замените «ты» на «мы»

Ты можешь дать этой переменной более наглядное имя, вроде seconds_remaining?

превращается в:

Мы можем дать этой переменной более наглядное имя, вроде seconds_remaining?

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

Вариант 2: Удалите из предложения субъект
Другой вариант избежать личного обращения — использовать сокращение, которое исключает из предложения субъект:

Надо подумать о переименовании переменной для более наглядного имени, вроде seconds_remaining.

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

Эта переменная должна быть переименована для более наглядного имени, вроде seconds_remaining.

Ещё один вариант — перефразировать предложение в виде вопроса, который начинается со слов «Что насчёт…» или «Как насчёт…»:

Что насчёт переименовать эту переменную для более наглядного имени, вроде seconds_remaining.

Оформляйте отзывы как запросы, а не команды

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

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

Сравните одно и то же замечание, оформленное двумя разными способами:

Людям нравится контролировать свою работу. Такой запрос даёт автору чувство самостоятельности.

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

Сравните, насколько воинственной кажется беседа в зависимости от оформления первоначального замечания:

Видите, насколько более цивилизованным стало общение, когда вы

сконструировали воображаемый диалог в доказательство своего тезиса

оформили замечание в виде запроса, а не команды?

Обосновывайте принципами, а не мнениями

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

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

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

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

Часть 2: скоро

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

• Работа со слишком большими код ревью.
• Распознавание возможности дать высокую оценку.
• Соблюдение рамок ревью.
• Действия в безвыходных ситуациях.

UPD. Опубликована вторая часть статьи.

Code review is a part of the software development process which involves testing the source code to identify bugs at an early stage. A code review process is typically conducted before merging with the codebase.

An effective code review prevents bugs and errors from getting into your project by improving code quality at an early stage of the software development process.

In this post, we’ll explain what code review is and explore popular code review tools that help organizations with the code review process.

What Is the Code Review Process?

The primary goal of the code review process is to assess any new code for bugs, errors, and quality standards set by the organization. The code review process should not just consist of one-sided feedback. Therefore, an intangible benefit of the code review process is the collective team’s improved coding skills.

If you would like to initiate a code review process in your organization, you should first decide who would review the code. If you belong to a small team, you may assign team leads to review all code. In a larger team size with multiple reviewers, you could enable a process in which every code review is assigned to an experienced developer based on their workload.

The next consideration for you is to decide on timelines, rounds, and minimal requirements for submitting code review requests.

The final consideration is about how feedback should be given in the code review process. Make sure you highlight the positive aspects of the code while suggesting alternatives for drawbacks.

Your feedback should be constructive enough to encourage the developer to understand your perspective and initiate a conversation when necessary.

It is easy for code reviews to get stuck in limbo, leading to being less efficient and even counter-productive.

Don’t let bugs and errors affect the hard work you’ve done on your project 🐛 Find the best code review tools with this guide ⤵️Click to Tweet

Why Is Code Review Critical?

The code review process is critical because it is never a part of the formal curriculum in schools. You may learn the nuances of a programming language and project management, but code review is a process that evolves as an organization ages.

Code review is critical for the following reasons:

• Ensure that you have no bugs in code.
• Minimize your chances of having issues.
• Confirm new code adheres to guidelines.
• Increase the efficiency of new code.

Code reviews further lead to improving other team members’ expertise. As a senior developer typically conducts a code review, a junior developer may use this feedback to improve their own coding.

How to Perform a Code Review?

There are four ways to conduct code reviews.

Over-the-Shoulder Code Reviews

Over-the-shoulder code reviews are done on the developer’s workstation, where an experienced team member walks through the new code, providing suggestions through a conversation. It is the easiest approach to code reviews and does not require a pre-defined structure.

Such a code review may still be done informally today, along with a formal code review process that may be in place. Over-the-shoulder code reviews were traditionally done in person, while distributed teams can follow this method through collaborative tools as well.

Email Pass-Around

While over-the-shoulder code reviews are a great way to review new code, geographically distributed teams have traditionally relied on email for code reviews.

In this code review process, a developer emails a diff of changes to the whole development team, usually through version control systems that automate notifications. This email initiates a conversation on the changes, where team members may request further changes, point out errors, or ask for clarifications.

In the early days, email was the primary means of communication because of Its versatility Open source organizations often maintained a public mailing list, which would also serve as a medium to discuss and provide feedback on code.

With the advent of code review tools, these mailing lists still exist, but primarily for announcements and discussion onward.

Pair Programming

Pair programming is a continuous code review process. Two developers sit at a workstation, but only one of them actively codes whereas the other provides real-time feedback.

While it may serve as a great tool to inspect new code and train developers, it could potentially prove to be inefficient due to its time-consuming nature. This process locks down the reviewer from doing any other productive work during the period.

Tool-Assisted

A tool-assisted code review process involves the use of a specialized tool to facilitate the process of code review. A tool generally helps you with the following tasks:

• Organize and display the updated files in a change.
• Facilitate a conversation between reviewers and developers.
• Assess the efficacy of the code review process with metrics.

While these are the broad requirements of a code review tool, modern tools may provide a handful of other functions. We’ll explore a range of code review tools later in this post.

Why Should You Use Code Review Tools?

The main outcome of a code review process is to increase efficiency. While these traditional methods of code review have worked in the past, you may be losing efficiency if you haven’t switched to a code review tool. A code review tool automates the process of code review so that a reviewer solely focuses on the code.

A code review tool integrates with your development cycle to initiate a code review before new code is merged into the main codebase. You can choose a tool that is compatible with your technology stack to seamlessly integrate it into your workflow.

For instance, if you use Git for code management, TravisCI for continuous integration, ensure that you select a tool that supports these technologies to be able to fit into the development process.

There are two types of code testing in software development: dynamic and static.

Dynamic analysis involves checking if the code follows a set of rules and running unit tests, typically performed by a predefined script. Static code testing is done after a developer creates a new code to be merged into the current code.

Now let’s dive in some of the most popular code review tools!

A Closer Look at 13 Powerful Code Review Tools

In this section, we review the most popular static code review tools.

1. Review Board

Review Board is a web-based, open source tool for code review. To test this code review tool, you can either explore the demo on their website or download and set up the software on your server.

The Python programming language and its installers, MySQL or PostgreSQL as a database, and a web server are the prerequisites to run Review Board on a server.

You can integrate Review Board with a wide range of version control systems — Git, Mercurial, CVS, Subversion and Perforce. You can also link Review Board to Amazon S3 for storing screenshots directly in the tool.

Review Board lets you perform both pre-commit and post-commit code reviews depending on your requirements. If you haven’t integrated a version control system, you can use a diff file to upload code changes to the tool for a review.

A graphical comparison of changes in your code is also provided. In addition to code reviews, Review Board lets you conduct document reviews too.

The first version of Review Board came out over a decade ago, but it’s still in active development. Therefore, the community for Review Board has grown over the years and you will likely find support if you have any issues using the tool.

Review Board is a simple tool for code reviews, which you can host on your server. You should give it a try if you do not wish to host your code on a public website.

2. Crucible

Crucible is a collaborative code review tool by Atlassian. It is a commercial suite of tools that allows you to review code, discuss plans changes, and identify bugs across a host of version control systems.

Crucible provides two payment plans, one for small teams and while the other for enterprises. For a small team, you need to make a one-time payment of $10 for unlimited repositories limited to five users. For large teams, the fees start at $1100 for ten users and unlimited repositories.

Both these plans offer a 30-day free trial without the need for a credit card.

Similar to Review Board, Crucible supports a large number of version control systems — SVN, Git, Mercurial, CVS, and Perforce. Its primary function is to enable you to perform code reviews. In addition to overall comments on the code, it allows you to comment inline within the diff view to pinpoint exactly what you’re referring to specifically.

Crucible integrates well with Atlassian’s other enterprise products like Confluence and Enterprise BitBucket. However, you will possibly get the most benefits from Crucible by using it alongside Jira, Atlassian’s Issue, and Project Tracker. It allows you to perform pre-commit reviews and audits on merged code.

3. GitHub

If you use GitHub to maintain your Git repositories on the cloud, you may have already used forks and pull requests to review code. In case you have no idea of what GitHub is, here’s a beginner’s guide to GitHub and the differences between Git and GitHub.

GitHub has an inbuilt code review tool in its pull requests. The code review tool is bundled with GitHub’s core service, which provides a free plan for developers. GitHub’s free plan limits the number of users to three in private repositories. Paid plans start at $7 per month.

GitHub allows a reviewer with access to the code repository to assign themselves to the pull request and complete a review. A developer who has submitted the pull request may also request a review from an administrator.

In addition to the discussion on the overall pull request, you are able to analyze the diff, comment inline, and check the history of changes. The code review tool also allows you to resolve simple Git conflicts through the web interface. GitHub even allows you to integrate with additional review tools through its marketplace to create a more robust process.

The GitHub code review tool is a great tool if you are already on the platform. It does not require any additional installation or configuration. The primary issue with the GitHub code review tool is that it supports only Git repositories hosted on GitHub. If you are looking for a similar code review tool that you can download and host on your server, you can try GitLab.

4. Axolo

Axolo is not what you expect when you read “code review tool”. You’re probably picturing a screen full of diffs. Not at all! Axolo is all about communication. Specifically, Axolo takes all of the usual back-and-forths on GitHub or GitLab and brings the discussion into Slack.

They do that by creating an ephemeral Slack channel for each code review, they invite only the people that should be (the code author, assignees, and reviewers), send only the required notifications in the channel (code comments, CI/CD, …), and archive the channel once the branch is merged.

With daily reminders, pull request recap notifications for stand-ups, and dedicated code review timeslots, engineering teams can seamlessly review code without any stale pull requests.

5. Phabricator

Phabricator is a list of open source tools by Phacility that assist you in reviewing code. While you can download and install the suite of code review tools on your server, Phacility also provides a cloud-hosted version of Phabricator.

You have no limitations if you install it on your server. However, you’ll be charged $20 per user per month (with an upper cap of $1000/month), which includes support. To give it a try, you can opt for a 30-day free trial.

Phabricator supports the three most popular version control systems — Git, Mercurial, and SVN. It can manage local repositories, as well as track externally hosted repositories. You can scale it to multiple servers too.

Beyond a Traditional Code Review Tool

Phabricator provides a detailed platform to have a conversation with your team members. You can either have a pre-commit review of a new team member or conduct a review on the newly submitted code. You can conduct a review on merged code too, a process that Phabricator calls as “audit”. Here’s a comparison between a review and an audit on Phabricator.

Phabricator’s additional tools help you in the overall software development cycle. For instance, it provides you with a built-in tracker to manage bugs and features. You can also create a wiki for your software within the tool through Phriction. To integrate the tool with unit tests, you may use Phabricator’s CLI tool. You can build applications over Phabricator through its API as well.

In summary, Phabricator provides you with a ton of features that help you in making your development process more efficient. It makes complete sense to opt for this tool if your project is in an early stage. If you do not have the expertise to set it up on your server, you should opt for the hosted version of the tool.

6. Collaborator

Collaborator by SmartBear is a peer code and document review tool for development teams. In addition to source code review, Collaborator enables teams to review design documents too. A 5-user license pack is priced at $535 a year. A free trial is available depending on your business requirements.

Collaborator supports a large number of version control systems like Subversion, Git, CVS, Mercurial, Perforce, and TFS. It does a good job of integrating with popular project management tools and IDEs like Jira, Eclipse, and Visual Studio.

This tool also enables reporting and analysis of key metrics related to your code review process. Moreover, Collaborator helps in audit management and bug tracking as well. If your tech stack involves enterprise software and you need support to set up your code review process, you should give Collaborator a try.

7. CodeScene

CodeScene is a code review tool that goes beyond traditional static code analysis. It performs behavioral code analysis by including a temporal dimension to analyze the evolution of your codebase. CodeScene is available in two forms: a cloud-based solution and an on-premise solution.

CodeScene’s cloud-based plans start free for public repositories hosted on GitHub. For up to ten private repositories and a team of ten members, CodeScene costs €99 (about $115) per month. An on-premise installation of CodeScene costs €15 (about $17) per developer per month.

CodeScene processes your version control history to provide code visualizations. In addition to this, it applies machine learning algorithms to identify social patterns and hidden risks in code.

Through the version control history, CodeScene profiles ever team member to map out their knowledge base and create inter-team dependencies. It also introduces the concept of hotspots in your repository by identifying files that undergo the most development activity. These hotspots require the highest attention going forward.

If you are looking for a tool that goes beyond a traditional, conversational code review tool, make sure to check out the free trial of CodeScene. To learn more about the underlying logic behind CodeScene’s behavioral code analysis, check out this white paper on CodeScene’s use cases and roles.

8. Visual Expert

Visual Expert is an enterprise solution for code review specializing in database code. It has support for three platforms only: PowerBuilder, SQL Server, and Oracle PL/SQL. If you are using any other DBMS, you will not be able to integrate Visual Expert for code review.

A free trial is available, but you need to send a request to get a quote on its pricing.

In addition to a traditional code review, Visual Expert analyzes each change in your code to foresee any performance issues due to the changes. The tool can automatically generate complete documentation of your application from the code too.

If you are using PowerBuilder, SQL Server, or Oracle PL/SQL and would like a specialized code review tool for your needs, you should try out Visual Expert (here is a guide on building efficient WordPress queries).

9. Gerrit

Gerrit is a free and open source web-based code review tool for Git repositories, written in Java. To run Gerrit, you need to download the source code and run it in Java. Here’s the installation process for a standalone version of Gerrit.

Gerrit combines the functionality of a bug tracker and a review tool into one. During a review, changes are displayed side by side in a unified diff, with the possibility to initiate a conversation for every line of code added. This tool works as an intermediate step between a developer and the central repository. Additionally, Gerrit also incorporates a voting system.

If you possess the technical expertise to install and configure Gerrit, and you are looking for a free code review tool, it should serve as an ideal solution for your projects.

10. Rhodecode

Rhodecode is a web-based tool that assists you in performing code reviews. It supports three version control systems: Mercurial, Git, and Subversion. A cloud-based version of Rhodecode starts at $8 per user per month, whereas an on-premise solution costs $75 per user per year. While it is enterprise software, its community edition, which is free and open source, can be downloaded and compiled free of charge.

Rhodecode enables a team to collaborate effectively through iterative, conversational code reviews to improve code quality. This tool additionally provides a layer of permission management for secure development.

In addition, a visual changelog helps you navigate the history of your project across various branches. An online code editor is also provided for small changes through the web interface.

Rhodecode integrates seamlessly with your existing projects, which makes it a great choice for someone looking for a web-based code review tool. Therefore, the community edition is ideal for those with technical expertise looking for a free and dependable code review tool.

11. Veracode

Veracode provides a suite of code review tools that let you automate testing, accelerate development, integrate a remediation process, and improve the efficiency of your project. The suite of code review tools by Veracode is marketed as a security solution that searches for vulnerability in your systems. They provide a set of two code review tools:

• Static Analysis: A tool that enables developers to identify and fix security flaws in their code.
• Software Composition Analysis: A tool that manages the remediation and mitigation process of flaws in code.

Code review is a part of the Software Composition Analysis and you can opt for a demo of Veracode before committing fully to it. Here is the link to request a quote.

12. Reviewable

Reviewable is a code review tool for GitHub pull requests. It is free for open source repositories, with plans for private repositories starting at $39 per month for ten users. Since the tool is integrated with GitHub, you can sign in using your GitHub account and get started.

If you would like to check out a typical review on Reviewable, you can head over to a demo review.

One interesting thins about Reviewable is that it overcomes a few drawbacks of the code review in GitHub’s pull requests feature. For instance, a comment on a line of code is automatically hidden by GitHub once a developer changes the line because GitHub assumes that the issue has been fixed. But, in reality, things may be different.

Also, GitHub has relatively small line limits for displaying file diffs.

If you are looking for a tool tightly coherent with GitHub but would like more features than pull requests, Reviewable should be your go-to tool.

13. Peer Review for Trac

If you use Subversion, the Peer Review Plugin for Trac provides a free and open source option to conduct code reviews on your projects. The Peer Review Plugin integrates into the Trac open source project, which is a wiki and issue tracking system for development projects.

Trac integrates the wiki and issue tracker with your reviews to provide an end-to-end solution. While the basic functionality of comparing changes and conversation is available, the plugin lets you design customized workflows for your projects.

For example, you could decide tasks to be done on triggers like the submission of a change or approval in a code review. You can also create custom reports on your projects.

If you are also looking for a wiki for documentation and an issue tracker to manage your project’s roadmap, Trac should provide a good option for you.

Code review tools will keep your project free of bugs and errors ❌ Find the best one for your team with this guide 🚀Click to Tweet

Summary

The code review process plays a key role when it comes to boosting the efficiency of your organization. Specifically, taking advantage of the right code review tool is what helps you to remove redundancy in your development cycle.

We looked closer to the most popular code review tools available in 2023 and here’s what we found:

• For a small team just starting out, Review Board is a good choice to initiate the code review process.
• If you are looking for an open-source code review tool, give Gerrit, Peer Review for Trac, or community edition of Rhodocode a try.
• Are you looking for a fairly easy to use code review tool with support? You should try out Rhodecode.
• If you use Git and GitHub to manage your codebase, give GitHub’s inbuilt code review editor a try. If you want to go beyond the basic features of pull requests, you should check out Reviewable.
• Do you belong to a team that uses Oracle, SQL Server, or PowerBuilder for your database code management? You can try out Visual Expert, a code review tool that specializes in database code.
• If you are looking for an enterprise solution, try out Atlassian’s Crucible, SmartBear’s Collaborator, or, Veracode.
• In case you want to use ML and AI to go beyond code review into the behavioral analysis, you should check out CodeScene.
• If you want a complete solution for your software development cycle, check out Phabricator’s suite of tools for code review and beyond.

Now it’s your turn: what code review tool are you using? Why? Tell us in the comments!

Suggested reading:

• Top 13 Scripting Languages You Should Pay Attention to
• What Is the Best Programming Language to Learn

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

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

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

Содержание

1. Что такое процесс ревью кода?
2. Почему код-ревью критичен?
3. Как выполнить ревью кода?
4. Почему Вам стоит использовать инструменты для код-ревью?
5. Более детальный взгляд на 12 мощных инструментов для ревью кода

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

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

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

Далее стоит рассмотреть временные рамки, очередности и минимальные требования принятия запросов на код-ревью.

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

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

-Старайтесь сохранить информативность обратной связи

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

Почему ревью кода критичен?

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

Код-ревью критичен, потому как призван:

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

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

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

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

Ревью «Из-за Плеча»

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

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

Почтовая Рассылка

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

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

—Почтовая рассылка через Google Groups на каждый новый push

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

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

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

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

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

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

С Помощью Инструментов

Такой вид код-ревью включает в себя использование специализированного программного обеспечения (ПО) в целях облегчения процесса ревью кода. Обычно инструмент помогает со следующими задачами:

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

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

Почему Вам стоит Использовать Инструменты для Код-ревью?

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

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

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

Есть два типа тестирования кода в разработке ПО: динамическое и статическое.

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

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

Более Детальный Разбор 12 Мощных Инструментов для Код-ревью

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

1. Review Board
2. Crucible
3. GitHub
4. Phabricator
5. Collaborator
6. CodeScene
7. Visual Expert
8. Gerrit
9. Rhodecode
10. Veracode
11. Reviewable
12. Peer Review для Tac

1. Review Board

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

—Обзор Review Board

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

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

—Обзор изменений в Review Board

Review Board позволяет выполнять как pre-commit, так и post-commit код-ревью в зависимости от требований. Если вы не интегрировали систему контроля версий, можете использовать diff-файл для загрузки изменений кода в инструменте для ревью.

Графическое сравнение изменений в коде также предоставлено. Вдобавок к ревью кода, Review Board позволяет проводить ревью документов.

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

Review Board – простой инструмент для код-ревью, который можно хостить на своём сервере. Вам стоит попробовать его, если не хотите хостить свой код на публичном веб-сайте.

2. Crucible

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

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

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

—Crucible (Источник)

Схоже с Review Board, Crucible поддерживает большое количество систем контроля версий – SVN, Git, Mercurial, CVS и Perforce. Базовая функция – позволить проводить ревью кода. Вдобавок к общим комментариям к коду, он позволяет писать inline-комментарии внутри diff view, чтобы точно указать на то, что вы хотели сказать.

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

3. GitHub

Если вы используете GitHub для поддержания ваших Git-репозиториев в облаке, то вы, вероятно, уже использовали форки (forks) и pull-запросы (pull requests) для ревью кода.

—GitHub в Pull-запросе

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

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

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

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

4. Phabricator

Phabricator — это набор инструментов с открытым исходным кодом от Phacility, которые помогут вам в ревью кода. В то время как вы можете скачать и установить набор софта для ревью кода на своём сервере, Phacility также предоставляет хостируемую в облаке (cloud-hosted) версию Phabricator.

Ограничений, если установить его на своем сервере нет. Впрочем, вам будет выставлен счёт в $20 на каждого пользователя в месяц (с верхним краем в $1000/месяц), также получая при этом поддержку. Также имеется 30-дневный бесплатный пробный период.

-Phabricator

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

Свыше стандартного инструмента ревью кода

Phabricator предоставляет детализированную платформу для общения с участниками команды. Вы можете либо совершить pre-commit ревью нового сотрудника, либо провести ревью на недавно представленный код. Также можете провести ревью на присоединенный (merged) код, такая функция называется “аудит”. Вот сравнение между код-ревью и аудитом в Phabricator.

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

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

5. Collaborator

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

-Collaborator Review Source

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

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

6. CodeScene

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

1. Облачные планы CodeScene бесплатны для публичных репозиториев, размещенных на GitHub. До десяти приватных репозиториев и для команды из десяти участников, CodeScene предлагается за €99 (около $115) в месяц. Локальная установка CodeScene обойдется в €15 (около 17$) на одного разработчика в месяц.

-Анализ в ревью кода CodeScene

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

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

-Knowledge-диаграммы в CodeScene

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

7. Visual Expert

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

Бесплатная пробная версия доступна, но для этого нужно отправить запрос, чтобы узнать цену.

—обзор Visual Expert (Источник)

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

Если вы используете PowerBuilder, SQL-сервер или Oracle PL/SQL и хотели бы специализированный инструмент для ревью кода для ваших потребностей, стоит попробовать Visual Expert.

8. Gerrit

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

—Gerrit

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

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

9. Rhodecode

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

—Rhodecode

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

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

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

10. Veracode

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

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

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

Ревью кода является частью Анализа Состава ПО, и вы можете выбрать демо-версию Veracode перед полным переходом на данный инструмент. Вот ссылка для запроса котировки.

11. Reviewable

Reviewable — это инструмент для код-ревью для pull-запросов GitHub. Он является бесплатным для репозиториев с открытым исходным кодом. Планы для приватных репозиториев начинаются от $39 в месяц для десяти пользователей. Поскольку инструмент объединен с GitHub, Вы можете авторизоваться при помощи вашей учетной записи GitHub и начать работу.

—Обзор Reviewable

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

Интересный момент в Reviewable заключается в том, что он преодолевает некоторые недостатки ревью кода в pull-запросах GitHub. Например, комментарий на строке кода автоматически скрывается GitHub’ом, когда разработчик меняет строку, потому что GitHub предполагает, что проблема была устранена. Но, в реальности, это не всегда так.

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

Если Вы ищете инструмент, который тесно согласован с GitHub, но хотите больше возможностей, чем простые pull-запросы, Reviewable — ваш выбор.

12. Peer Review для Trac

Если вы пользуетесь Subversion, Peer Review Plugin для Trac предоставляет бесплатный и открытый вариант проведения код-ревью на проектах. Плагин Peer Review интегрируется в Open-source-проект Trac, который представляет собой Вики-страницу и систему отслеживания вопросов (issues) для разработки проектов.

—Обзор Peer Review Plugin для Trac (Источник)

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

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

Также, если ищете Вики для документации и трекера проблем для управления «дорожной картой» (roadmap) проекта, Trac — хороший вариант.

Итог

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

Мы присмотрелись к самым популярным инструментам для код-ревью, доступным в 2020 году, и вот что мы нашли:

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

Теперь ваша очередь: какой инструмент для ревью кода используете? Почему? Расскажите нам в комментариях!

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

From Wikipedia, the free encyclopedia

Code review (sometimes referred to as peer review) is a software quality assurance activity in which one or several people check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation. At least one of the persons must not be the code’s author. The persons performing the checking, excluding the author, are called «reviewers».^[1][2]

Although direct discovery of quality problems is often the main goal,^[3] code reviews are usually performed to reach a combination of goals:^[4][5]

• Better code quality  – improve internal code quality and maintainability (readability, uniformity, understandability, etc.)
• Finding defects  – improve quality regarding external aspects, especially correctness, but also find performance problems, security vulnerabilities, injected malware, …
• Learning/Knowledge transfer  – help in transferring knowledge about the codebase, solution approaches, expectations regarding quality, etc.; both to the reviewers as well as to the author
• Increase sense of mutual responsibility  – increase a sense of collective code ownership and solidarity
• Finding better solutions  – generate ideas for new and better solutions and ideas that transcend the specific code at hand.
• Complying to QA guidelines, ISO/IEC standards  – Code reviews are mandatory in some contexts, e.g., air traffic software, safety-critical software

The above-mentioned definition of code review delimits it against neighboring but separate software quality assurance techniques: In static code analysis the main checking is performed by an automated program, in self checks only the author checks the code, in testing the execution of the code is an integral part, and pair programming is performed continuously during implementation and not as a separate step.^[1]

Review types[edit]

There are many variations of code review processes, some of which will be detailed below. Additional review types are part of IEEE 1028

IEEE 1028-2008 lists the following review types:^[6]

• Management reviews
• Technical reviews
• Inspections
• Walk-throughs
• Audits

Inspection (formal)[edit]

The historically first code review process that was studied and described in detail was called «Inspection» by its inventor Michael Fagan.^[7]
This Fagan inspection is a formal process which involves a careful and detailed execution with multiple participants and multiple phases. Formal code reviews are the traditional method of review, in which software developers attend a series of meetings and review code line by line, usually using printed copies of the material. Formal inspections are extremely thorough and have been proven effective at finding defects in the code under review.^[7]

Regular change-based code review (Walk-throughs)[edit]

In recent years,^[when?] many teams in industry have introduced a more lightweight type of code review.^[8][3] Its main characteristic is that the scope of each review is based on the changes to the codebase performed in a ticket, user story, commit, or some other unit of work. Furthermore, there are rules or conventions that embed the review task into the development process (e.g., «every ticket has to be reviewed»), commonly as part of a pull request, instead of explicitly planning each review. Such a review process is called «regular, change-based code review».^[1] There are many variations of this basic process. A survey among 240 development teams from 2017 found that 90% of the teams use a review process that is based on changes (if they use reviews at all), and 60% use regular, change-based code review.^[3] Also, most large software corporations such as Microsoft,^[9] Google,^[10] and Facebook follow a change-based code review process.

Efficiency and effectiveness of reviews[edit]

Capers Jones’ ongoing analysis of over 12,000 software development projects showed that the latent defect discovery rate of formal inspection is in the 60-65% range. For informal inspection, the figure is less than 50%. The latent defect discovery rate for most forms of testing is about 30%.^[11][12]
A code review case study published in the book Best Kept Secrets of Peer Code Review found that lightweight reviews can uncover as many bugs as formal reviews, but were faster and more cost-effective^[13] in contradiction to the study done by Capers Jones^[11]

The types of defects detected in code reviews have also been studied. Empirical studies provided evidence that up to 75% of code review defects affect software evolvability/maintainability rather than functionality,^{[14][15][4][16]} making code reviews an excellent tool for software companies with long product or system life cycles.^[17]
This also means that less than 15% of the issues discussed in code reviews are related to bugs.^[18]

Guidelines[edit]

The effectiveness of code review was found to depend on the speed of reviewing.
Code review rates should be between 200 and 400 lines of code per hour.^{[19][20][21][22]} Inspecting and reviewing more than a few hundred lines of code per hour for critical software (such as safety critical embedded software) may be too fast to find errors.^[19][23]

Supporting tools[edit]

Static code analysis software lessens the task of reviewing large chunks of code on the developer by systematically checking source code for known vulnerabilities and defect types.^[24] A 2012 study by VDC Research reports that 17.6% of the embedded software engineers surveyed currently use automated tools to support peer code review and 23.7% expect to use them within 2 years.^[25]

See also[edit]

• Committer
• Software review
• Software quality
• Best coding practices
• List of software development philosophies

External links[edit]

• Five Code Review Antipatterns (Java Magazine, Best of 2020)

References[edit]