Write better code
On GitHub, lightweight code review tools are built into every pull request. Your team can create review processes that improve the quality of your code and fit neatly into your workflow.
See what’s possible
Start with a pull request
Pull requests are fundamental to how teams review and improve code on GitHub. Evolve projects, propose new features, and discuss implementation details before changing your source code.
Make a change
Start a new feature or propose a change to existing code with a pull request—a base for your team to coordinate details and refine your changes.
See every update
Diffs
Preview changes in context with your code to see what is being proposed. Side-by-side Diffs highlight added, edited, and deleted code right next to the original file, so you can easily spot changes.
History
Browse commits, comments, and references related to your pull request in a timeline-style interface. Your pull request will also highlight what’s changed since you last checked.
Pro-tip: You can search your commit history by keyword, committer, organization, and more.
Blame
See what a file looked like before a particular change. With blame view, you can see how any portion of your file has evolved over time without viewing the file’s full history.
Pro-tip: Use git blame to trace the changes in a file.
Discuss code
Comments
On GitHub, conversations happen alongside your code. Leave detailed comments on code syntax and ask questions about structure inline.
Review requests
If you’re on the other side of the code, requesting peer reviews is easy. Add users to your pull request, and they’ll receive a notification letting them know you need their feedback.
Reviews
Save your teammates a few notifications. Bundle your comments into one cohesive review, then specify whether comments are required changes or just suggestions.
Resolve simple conflicts
You can’t always avoid conflict. Merge pull requests faster by resolving simple merge conflicts on GitHub—no command line necessary.
Learn how to resolve merge conflicts on GitHub and using the command line.
Merge the highest quality code
Reviews can improve your code, but mistakes happen. Limit human error and ensure only high quality code gets merged with detailed permissions and status checks.
Permissions
Give collaborators as much access as they need through your repository settings. You can extend access to a few teams and select which ones can read or write to your files. The options you have for permissions depend on your plan.
Protected branches
Protected Branches help you maintain the integrity of your code. Limit who can push to a branch, and disable force pushes to specific branches. Then scale your policies with the Protected Branches API.
Required status checks
Create required status checks to add an extra layer of error prevention on branches. Use the Status API to enforce checks and disable the merge button until they pass. To err is human; to automate, divine!
Bulletproof your review process
Build on GitHub with review tools to avoid human error and add extra polish to your team’s code with review tools.
Codecov
Group, merge, archive and compare coverage reports
Codacy
Automated code reviews to help developers ship better software, faster
Coveralls
Ensure that new code is fully covered, and see coverage trends emerge
Zhigalov / review.md
Рецепт полезного кодревью
За пять лет работы в Яндексе я участвовал в разработке одиннадцати проектов. Писал код на JavaScript, Python и C++. Некоторые проекты делал в одиночку, другие разрабатывал в группе из восьми человек. Но в каждой команде, на всех проектах, вне зависимости от языка программирования я использовал кодревью.
Я люблю ревью, с его помощью постоянно узнаю что-то новое. Иногда, глядя на чужой код, хочется воскликнуть: «А что, так тоже можно?» В чужом коде я нахожу интересные приёмы и беру их себе на вооружение. Много новых знаний черпаю из комментариев к моему коду. Для меня стало открытием, что люди любят делиться своим опытом. Даже когда я разрабатываю проект в одиночку, то прошу ребят из другой команды посмотреть пои пулреквесты. Это мотивирует меня писать красивый понятный код.
Но я не всегда был сторонником этой практики. Вначале, ревью было для меня наказанием. Я мог неделю с вдохновением писать код, вкладывая в него все силы. Отправлял пулреквест, трижды пинговал ревьювера, а в ответ получал сухое «вроде ок» или, что ещё хуже, десятки злобных комментариев не по существу.
Мне на ревью приходили пулы из пяти тысяч строк. Я часами пытался разобраться в коде, по сотне раз скроллил от функции к тесту и обратно. Писал десятки бесполезных комментариев о пропущенной точке с запятой. Всё это жутко меня раздражало. Часто откладывал ревью на потом, и у меня накапливались десятки непросмотренных пулов.
Если вы чувствовали это на себе, значит, статья для вас. Я расскажу о приёмах и инструментах, которые использую каждый день на протяжении пяти лет ежедневного кодревью.
«До ревью». Советы автору
В каждом коммите я выражаю одну простую мысль. Это может быть реализация метода модели или компонент в вёрстке. Так ревьюверу будет проще меня понять. Я не сваливаю на него всю задачу, которую невозможно проглотить за раз, а рассказываю о решении по кусочкам.
Любой рефакторинг выношу в отдельный коммит. Зачастую рефокторинг носит чисто технический характер, например, переименование метода. Ревьюверу не нужно вчитываться в каждую строчку такого изменения. Он пробежит глазами «по диагонали» и сможет уделить больше времени по-настоящему важному коду.
Крошите, разбивайте, измельчайте свой код на маленькие коммиты. Это позволит ревьюверу лучше разобраться в вашем коде. Ничего страшного, если вы переборщите с декомпозицией. Два коммита легко объединить в один. Гораздо сложнее разделить большой коммит на несколько маленьких. «Нарезанные овощи» легко получить перемешивая «нарезанные помидоры» и «измельчённый лук». Но чтобы получить из тарелки салата все ингредиенты по частям, нужно потратить намного больше времени [Q1, Q2, Q3].
После коммита я сразу пушу изменения на гитхаб. Это пару раз выручало меня, когда случались «кофейные неприятности» с ноутбуком.
Когда пишу емэйл, то заполняю заголовок и содержимое письма. Заголовок — короткое и ёмкое название, тело письма — развёрнутое, подробное описание с картинками и ссылками. Такой же подход применяю к описанию коммитов.
Не люблю рецепты, где пишут «добавьте щепотку соли» или «выпекайте до готовности». Щепотка у каждого своя, а глядя на курочку в фольге я не могу определить её готовность. В описании коммитов стараюсь избавляться от всех неоднозначностей. При помощи ASCII-графики описываю тестовый пример. Если решению предшествовало обсуждение, где мы рисовали схемы на доске или в блокноте, то прикладываю к описанию ссылку на фотографию [Q5, Q6].
(пример описания коммита с использованием ASCII-графики)
(пример описания пулреквеста с заголовком и телом. Для редактирования комментария я использовал консольный редактор vim)
(пример отображения коммита с описанием на GitHub. По стрелкам в правом верхнем углу можно перемещаться между коммитами)
Перед подачей блюда повар снимает пробу, выкладывает на красивую тарелку, добавляет украшение. Мы будем делать это тремя командами:
Не представляю свою жизнь без линтера. Это инструмент, который автоматически проверяет соответствие кода выбранному стилю. Для JavaScript я использую ESlint. Можно сравнить линтер с роботом R2-D2 из «Звёздных воин», который ходит по коду и приводит его в порядок. Места, которые он не может исправить сам, подчеркивает красным.
С моим любимым WebStorm этот линтер работает «из коробки». Я вижу и исправляю проблему сразу, как только написал код, а не оставляю эту работу на потом. Перед коммитом линтер запускается автоматически при помощи husky.
Код после линтера приятно смотреть. Я избавляю ревьювера от необходимости писать десятки бесполезных комментариев о пропущенном пробеле. Всё внимание будет сконцентрировано на действительно важных вещах.
(пример запуска линтера на коммит)
(пример описания пулреквеста текстом, если скопировать результат вывода предыдущей команды)
Хеши коммитов становятся ссылками, по которым может навигироваться ревьювер. Они остаются рабочими, даже если объединить все коммиты в один. Подробнее про объединения поговорим дальше.
Пулреквест готов! Но не спешите закрывать задачу, самое интересное ещё впереди.
«Во время ревью». Советы ревьюверу
Перед тем как смотреть код, я стараюсь понять какую задачу решает автор. Читаю описание пулреквеста, перехожу по ссылкам в ишью, изучаю схемы и фотографии. Иногда, ошибка кроется в постановке задачи. Хороший ревьювер оценивает идею, а не выступает в роли «продвинутого линтера».
В любой непонятной ситуации задаю вопрос. Даже если он кажется мне глупым или банальным. Таким вопросом я могу натолкнуть автора на правильную мысль.
В некоторых случаях я не согласен с предложенным решением. Это нормально! У каждого программиста своё мнение. Если код автора объективно хороший, то я не пытаюсь переубедить его. Максимум высказываю предложение, подкрепляя его ссылками, бенчмарками или картинками [Q6]. Это позволяет вести конструктивный диалог, а не переходить на личности.
Код автора может выглядеть не оптимальным на первый взгляд. Он написан так, как принято делать в проекте. В таком случае лучше оставить вариант автора.
Разберёмся на примере. Автор написал функцию суммирования массива чисел таким образом:
Такой код можно переписать компактнее, используя стрелочные функции:
Иногда, мне на ревью приходит очень большой и сложный пулреквест. Автор старался две недели, а мне предстоит осознать полёт его мысли и вникнуть в каждую строчку за несколько часов. Одному мне не справиться.
В таком случае я прошу автора об offline-ревью. Ставлю рядом складной стульчик (кстати, не используйте мягкий: рискуете тем, что ревью затянется надолго), сажу автора возле себя и прошу рассказать его о решении.
Эффективность такого подхода невысокая. Во-первых, тратится время двух разработчиков. Во-вторых, легко начать злоупотреблять этой практикой: слишком велик соблазн не думать самостоятельно над кодом автора (пусть придёт и расскажет). В-третьих, я погружаюсь в ход мыслей автора, невольно принимая его за правильный — так я не вырабатываю свою точку зрения.
Опасная практика, но порой без неё не обойтись. Применяйте offline-ревью с осторожностью.
«После ревью». Советы автору
Вернёмся к пулреквесту, который я готовил в первой части статьи. Ревьювер написал комментарии. Наступает этап правок и обсуждений.
Если я согласен с замечанием, то исправляю его и пишу в комментарии что исправил. Ревьюверу будет приятно увидеть, что я прислушался к нему, а я сразу вижу какие замечания поправил, а какие нет. Если не согласен, то задаю ревьюверу вопросы: почему он так считает? правильно ли он понял мою мысль? чем он может подкрепить свою точку зрения? Стараюсь завязать конструктивный диалог, в ходе которого мы докопаемся до истины.
Я отвечаю на комментарии во вкладке с файлами. Так ревьювер получит одно письмо со всеми отметками и вопросами, а не по письму на каждый комментарий.
(пример ответа на ревью: комментируйте на вкладке с файлами и благодарите ревьювера в конце)
В конце обязательно благодарю ревьювера. Он потратил своё время на то, чтобы вникнуть в мой код и сделать его лучше. Разве это не заслуживает приятных слов? В следующий раз этот человек возьмётся за мой пулреквест с бо’льшим энтузиазмом, потому что видит важность своих советов и уважение с моей стороны.
Разделение на микрокоммиты помогает на кодревью. Для истории такое разделение избыточно. До этого я старался разделять код на коммиты так, чтобы каждый коммит описывал шаг рецепта. Настало время объединить коммиты пулреквеста в один, чтобы получить готовое блюдо, которым будет легко оперировать при сервировке стола.
(пример ребейза, в котором четыре последние коммита сливаются в один)
Можно обойти трудности описанные выше используя новые возможности интерфейса GitHub. Для этого перед мержем выбираем пункт «Squash and merge».
(пример объединения коммитов при мерже через интерфейс GitHub)
(Серверную версию ветки можно удалить по кнопке сразу после мержа пулреквеста.)
В заключение, ещё раз коротко о командах, которые я использую:
Спасибо Вадиму Макишвили за редактуру и полезные вопросы. Олегу Мохову за рекомендации, после которых я чуть больше чем полностью переписал статью. Тане Занаховой, за вычитку всех орфографических и пунктационных ошибок. Без вас ничего бы не получилось. Спасибо вам большое!
Копируем картинку в буфер обмена и вставляем в любое поле ввода на гитхабе. В комментарии к issue, коммиту или в поле описания пулреквеста. Спустя несколько секунд получим ссылку на картинку. Я установил на сотовый телефон программу Office Lens. Она вычищает лишний мусор с фотографии, кропает, убирает искривления и позволяет быстро пошарить картинку в любой чатик.
Если по делу и без злоупотребления. В общем, всё как в жизни. 
Ревью кода системы средствами git
Бывает нужно оставить отзыв об исходном коде в репозитории в целом, например при приемке кода на поддержку от других разработчиков или подключаясь к новому проекту.
Процессы ревью в Github и аналогах построены вокруг вносимых изменений, а в нашем случае комментарии нужно дать к состоянию всего кода системы на момент комментирования.
Как это сделать средствами самого git: зафиксировать состояние в ветке для ревью, затем в merge request к этой ветке оставить свои замечания.
В общем суть метода уже изложена, ниже лишь немного подробностей.
Проблематика
Представьте ситуацию: вам передают репозиторий с кодом и просят вынести свое мнение о нем. Обычно в подобных случаях замечания составляются в отдельном документе/таске/страничке в конфлюенс и т.п., что не очень удобно так как:
Метод ревью кода системы
Итак, нам нужно проделать следующее: зафиксировать состояние в ветке для ревью, затем в merge request к этой ветке оставить свои замечания.
На примере подготовленного для заметки репозитория https://github.com/oktend/system-review-example проделаем эти шаги:
Теперь наши ветки выглядят примерно так: 
https://github.com/oktend/system-review-example/network
Результат
В созданном merge request можно увидеть все собранные в ходе ревью замечания, даже обсудить их.
Состояние, для которого были выдвинуты замечания будет зафиксировано пока ветку явно не удалят.
Замечания можно просматривать в веб-интерфейсе github (или аналогов), в IDE, или средствами самого git.
К ревью можно будет вернуться в будущем сохранив замечания и контекст, в котором они были выдвинуты.
Примечания
Вполне допускаю возможность, что переизобрел велосипед и что для подобных случаев есть лучший метод, тогда буду благодарен за указание на лучший путь.
Идею для этого метода придумал не я, а предложил один разработчик, если Артем изъявит желание, укажу как автора.
PHP Profi
Квест → Как хакнуть форму
12 лучших инструментов для ревью кода для разработчиков (2020) Перевод
Эффективное ревью кода предотвращает попадание багов и ошибок в ваш проект путем улучшения качества кода на ранней стадии процесса разработки софта.
В этой статье мы объясним, что такое код-ревью и изучим популярные инструменты, которые помогают организациям с данным процессом.
Что такое процесс ревью кода?
Основная задача ревью кода заключается в проверке любого нового кода на баги, ошибки, а также на соблюдение стандартов качества, установленных организацией. Процесс ревью кода не должен состоять лишь из одностороннего фидбэка. Следовательно, нематериальная польза код-ревью заключается в коллективном улучшении навыков написания кода в команде.
Далее стоит рассмотреть временные рамки, очередности и минимальные требования принятия запросов на код-ревью.
Наконец, следует учесть как должна даваться обратная связь в процессе ревью кода. Убедитесь, что вы подчеркиваете положительные аспекты кода, попутно предлагая альтернативы в выявленных недостатках.
Ваша обратная связь должна быть достаточно конструктивной, чтобы позволить разработчику понять ваше видение и, при необходимости, начать обсуждение.
-Старайтесь сохранить информативность обратной связи
Проверяющие могут оказаться в «лимбе» достаточно просто, что приводит к более низкой эффективности и даже контрпродуктивности.
Почему ревью кода критичен?
Код-ревью критичен, потому как призван:
Ревью кода впоследствии ведет к улучшению компетенции членов команды. В то время как старший разработчик осуществляет код-ревью, младший разработчик может использовать обратную связь для улучшения своих навыков программирования.
Как выполнить ревью кода?
Существует четыре способа произвести код-ревью.
Ревью «Из-за Плеча»
Такие проверки выполняются за рабочей станцией разработчика, где опытный участник команды просматривает новый код, выдвигая свои предложения в процессе обсуждения. Это самый простой способ проведения код-ревью, который не требует определенной структуры.
Ревью такого типа проводятся до сих пор, неформально, при этом формальный код-ревью также может иметь место. Просмотр «из-за плеча» традиционно происходил лично, в то же время удаленные команды могут следовать этому методу с помощью коллаборативных инструментов.
Почтовая Рассылка
В таком процессе ревью разработчик отправляет diff изменений всей команде разработчиков, как правило, с помощью системы контроля версий (VCS), которые автоматизируют уведомления. Такое сообщение инициирует обсуждение изменений, где члены команды могут запросить будущие изменения, указать на ошибки или запросить уточнения.
—Почтовая рассылка через Google Groups на каждый новый push
Раньше почта была основным способом коммуникации ввиду ее универсальности. Организации с открытым кодом часто поддерживали публичный список рассылки, который также служил средством для обсуждения и предоставления обратной связи по коду.
Несмотря на приход инструментов для ревью кода, списки рассылок до сих пор существуют, хоть и используются они теперь в основном для анонсов и обсуждений.
Парное Программирование
—Парное программирование порой может быть неэффективно
И хотя это может служить хорошим способом просмотра нового кода и обучения разработчиков, парное программирование потенциально является неэффективным ввиду временных затрат. Такой процесс не позволяет ревьюеру заниматься любой другой продуктивной работой во время такой сессии.
С Помощью Инструментов
Такой вид код-ревью включает в себя использование специализированного программного обеспечения (ПО) в целях облегчения процесса ревью кода. Обычно инструмент помогает со следующими задачами:
Хотя эти широкие требования инструмент проверки кода, современного инструментария может обеспечить несколько других функций. Мы рассмотрим ряд инструментов анализа кода позже в этом посте.
Почему Вам стоит Использовать Инструменты для Код-ревью?
Инструмент интегрируется в ваш цикл разработки для инициации ревью кода перед тем как новый код соединен с главной кодовой базой. Вы можете выбрать инструмент, который совместим с вашим стэком технологий для «бесшовного» внедрения в Ваш рабочий процесс.
К примеру, если Вы используете Git для менеджмента кода, TravisCI для непрерывной интеграции, то убедитесь, что Вы выберете инструмент, который поддерживает эти технологии и подходит для процесса разработки.
Есть два типа тестирования кода в разработке ПО: динамическое и статическое.
Динамический анализ включает в себя проверку кода на следование набору правил и проведение unit-тестов, обычно с помощью предопределенного скрипта. Статическое тестирование кода проделывается после того как разработчик пишет новый код для присоединения к текущему коду.
Теперь давайте рассмотрим одни из самых популярных инструментов для код-ревью.
Более Детальный Разбор 12 Мощных Инструментов для Код-ревью
В этом разделе мы будем обозревать самые популярные статические инструменты для код-ревью.
1. Review Board
—Обзор 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. Она представляет собой коммерческий набор инструментов, позволяющий вам проводить код-ревью, обсуждать планы и изменения, а также обнаруживать баги через множество систем контроля версий.
В обоих случаях вам предлагается 30-дневный бесплатный период без требования данных вашей карты.
Схоже с 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-запросам и завершать ревью. Разработчик, который принял pull request, может также запросить ревью у администратора.
В дополнение к обсуждению на общем pull-запросе, вы можете анализировать diff, писать строчные (inline) комментарии, и проверять историю изменений. Инструмент ревью кода также позволяет разрешать простые конфликты в Git через веб-интерфейс. GitHub даже позволяет интегрировать дополнительные инструменты для ревью через маркетплейс, для большей надежности.
4. Phabricator
Phabricator поддерживает три самых популярных системы контроля версий — Git, Mercurial, и SVN. С его помощью можно управлять локальными репозиториями и отслеживать внешне размещенные репозитории. Также, можете масштабировать его до нескольких серверов.
Свыше стандартного инструмента ревью кода
Phabricator предоставляет детализированную платформу для общения с участниками команды. Вы можете либо совершить pre-commit ревью нового сотрудника, либо провести ревью на недавно представленный код. Также можете провести ревью на присоединенный (merged) код, такая функция называется “аудит”. Вот сравнение между код-ревью и аудитом в Phabricator.
Дополнительные инструменты Phabricator помогают в общем цикле разработки программного обеспечения. Например, он предоставляет встроенный трекер, чтобы отслеживать баги и особенности. Вы также можете создать вики-страницу для своего программного обеспечения через Phriction. Для того чтобы интегрировать инструмент в юнит-тесты, можете использовать инструмент CLI. Помимо этого, вы можете строить приложения через Phabricator с помощью его API.
Подводя итог, Phabricator предоставляет массу возможностей, которые помогут сделать процесс разработки более эффективным. Есть особый смысл выбрать этот инструмент, если проект находится на ранней стадии. Если вы не обладаете необходимыми знаниями, чтобы установить его на своем сервере, следует выбрать хостируемую версию программы.
5. Collaborator
-Collaborator Review Source
Collaborator поддерживает большое количество систем контроля версий как Subversion, Git, CVS, Mercurial, Perforce, и TFS. Он хорошо справляется с интеграцией в популярные инструменты управления проектами и IDE (интегрированные среды разработки), такие как Jira, Eclipse, и Visual Studio.
Этот инструмент также позволяет делать отчеты и анализировать ключевые показатели, характеризующие эффективность код-ревью. Кроме того, Collaborator помогает в управлении аудитом и отслеживании багов. Если ваш стек технологий включает в себя корпоративное программное обеспечение, и если вам нужна поддержка для настройки процесса ревью кода, стоит попробовать Collaborator.
6. CodeScene
CodeScene является инструментом ревью кода, который выходит за рамки традиционного статического анализа кода. Он осуществляет поведенческий анализ с помощью добавления временного измерения для анализа развития вашей кодовой базы. CodeScene в двух формах: облачное решение и локальное решение.
-Анализ в ревью кода CodeScene
CodeScene обрабатывает историю контроля версий для визуализации кода. Вдобавок к этому, он применяет алгоритмы машинного обучения для выявления социальных закономерностей и скрытых рисков в коде.
Через историю контроля версий CodeScene профилирует каждого члена команды, чтобы отрисовать диаграмму их базы знаний и создания внутрикомандных зависимостей. Он также вводит концепцию хот-спотов (hotspots) в репозитории путем определения файлов, которые подвергаются наиболее активной разработке.Эти хот-споты требуют высокого внимания в дальнейшем.
-Knowledge-диаграммы в CodeScene
Если вы ищете инструмент, который выходит за рамки стандартного, диалогового инструмента ревью кода, однозначно попробуйте бесплатную пробную версию CodeScene. Чтобы узнать больше о лежащей в основе логике CodeScene в поведенческом анализе кода, взгляните на этот документ про Сценарии ис пользования CodeScene.
7. Visual Expert
Бесплатная пробная версия доступна, но для этого нужно отправить запрос, чтобы узнать цену.
В дополнение к традиционному код-ревью, Visual Expert анализирует каждое изменение в коде, чтобы предвидеть возможные проблемы с его исполнением в связи с изменениями. Также, инструмент может автоматически генерировать полную документацию приложения из кода.
Если вы используете PowerBuilder, SQL-сервер или Oracle PL/SQL и хотели бы специализированный инструмент для ревью кода для ваших потребностей, стоит попробовать Visual Expert.
8. Gerrit
Gerrit сочетает в себе функциональность багтрекера и инструмент для код-ревью. В ходе ревью изменения отображаются бок-о-бок в едином diff, с возможностью начать обсуждение по каждой добавленной строке кода. Этот инструмент работает как промежуточный этап между разработчиком и центральным репозиторием. Кроме того, Gerrit также включает в себя систему голосования.
Если вы обладаете техническими знаниями для установки и настройки Gerrit и ищете бесплатный инструмент для ревью кода, он станет идеальным решением для ваших проектов.
9. Rhodecode
Rhodecode позволяет команде эффективно взаимодействовать через итеративный, диалоговый код-ревью, для повышения качества кода. Инструмент дополнительно содержит слой управления доступом для защищенной разработки.
Кроме того, визуальный changelog (история изменений) помогает вам ориентироваться в истории вашего проекта в различных ветках. Онлайн-редактор кода также предоставлен для внесения небольших изменений через веб-интерфейс.
Rhodecode легко интегрируется в существующие проекты, что делает его отличным выбором для тех, кто ищет веб-инструмент для код-ревью. Следовательно, комьюнити-версия идеально подходит для людей с техническими знаниями, которые ищут бесплатный и надежный инструмент для код-ревью.
10. Veracode
Veracode предоставляет набор инструментов для код-ревью, которые позволяют автоматизировать тестирование, ускорить разработку, интегрировать процесс обновления и повысить эффективность проекта. Набор инструментов для код-ревью от Veracode позиционируется как решение по безопасности, которое ищет уязвимости в ваших системах. Они представляют собой набор из двух инструментов для ревью кода:
Ревью кода является частью Анализа Состава ПО, и вы можете выбрать демо-версию Veracode перед полным переходом на данный инструмент. Вот ссылка для запроса котировки.
11. Reviewable
Если хотите взглянуть на типичный ревью в Reviewable, можете попробовать демо код-ревью.
Интересный момент в Reviewable заключается в том, что он преодолевает некоторые недостатки ревью кода в pull-запросах GitHub. Например, комментарий на строке кода автоматически скрывается GitHub’ом, когда разработчик меняет строку, потому что GitHub предполагает, что проблема была устранена. Но, в реальности, это не всегда так.
Кроме того, GitHub имеет сравнительно низкие лимиты строк для отображения diff ‘ов в файле.
12. Peer Review для Trac
Если вы пользуетесь Subversion, Peer Review Plugin для Trac предоставляет бесплатный и открытый вариант проведения код-ревью на проектах. Плагин Peer Review интегрируется в Open-source-проект Trac, который представляет собой Вики-страницу и систему отслеживания вопросов (issues) для разработки проектов.
—Обзор Peer Review Plugin для Trac (Источник)
Trac внедряет Вики и issue-трекер в ваши код-ревью, чтобы обеспечить конечное решение. В то время как базовый функционал сравнения изменений и обсуждения всё так же доступен, плагин позволяет создавать настраиваемые рабочие процессы для ваших проектов.
Например, вы можете назначить задачи, которые можно решить, на такие триггеры, как принятие изменения или подтверждение в код-ревью. Вы также можете создавать настраиваемые репорты на свои проекты.
Ревью кода играет ключевую роль, когда речь идет о повышении эффективности деятельности вашей организации. В частности, использование правильного инструмента поможет устранить избыточность в цикле разработки.
Мы присмотрелись к самым популярным инструментам для код-ревью, доступным в 2020 году, и вот что мы нашли:
Теперь ваша очередь: какой инструмент для ревью кода используете? Почему? Расскажите нам в комментариях!