что такое code review в github
Ревью кода системы средствами git
Бывает нужно оставить отзыв об исходном коде в репозитории в целом, например при приемке кода на поддержку от других разработчиков или подключаясь к новому проекту.
Процессы ревью в Github и аналогах построены вокруг вносимых изменений, а в нашем случае комментарии нужно дать к состоянию всего кода системы на момент комментирования.
Как это сделать средствами самого git: зафиксировать состояние в ветке для ревью, затем в merge request к этой ветке оставить свои замечания.
В общем суть метода уже изложена, ниже лишь немного подробностей.
Проблематика
Представьте ситуацию: вам передают репозиторий с кодом и просят вынести свое мнение о нем. Обычно в подобных случаях замечания составляются в отдельном документе/таске/страничке в конфлюенс и т.п., что не очень удобно так как:
Метод ревью кода системы
Итак, нам нужно проделать следующее: зафиксировать состояние в ветке для ревью, затем в merge request к этой ветке оставить свои замечания.
На примере подготовленного для заметки репозитория https://github.com/oktend/system-review-example проделаем эти шаги:
Теперь наши ветки выглядят примерно так: 
https://github.com/oktend/system-review-example/network
Результат
В созданном merge request можно увидеть все собранные в ходе ревью замечания, даже обсудить их.
Состояние, для которого были выдвинуты замечания будет зафиксировано пока ветку явно не удалят.
Замечания можно делать как в отрыве от кода:
https://github.com/oktend/system-review-example/blob/c80b03710059b235347ec781bf08dca9c0e68f7d/review-1march2020-goodman.md
так и в контексте кода:
https://github.com/oktend/system-review-example/blob/c80b03710059b235347ec781bf08dca9c0e68f7d/foo.js
Замечания можно просматривать в веб-интерфейсе github (или аналогов), в IDE, или средствами самого git.
К ревью можно будет вернуться в будущем сохранив замечания и контекст, в котором они были выдвинуты.
Примечания
Вполне допускаю возможность, что переизобрел велосипед и что для подобных случаев есть лучший метод, тогда буду благодарен за указание на лучший путь.
Идею для этого метода придумал не я, а предложил один разработчик, если Артем изъявит желание, укажу как автора.
Automating Code Reviews on GitHub
Code reviews are part of the daily activities of software engineers and a key process in release management. With engineers spending 10% to 20% of their time on code reviews, automating code reviews (at least part of) allows them to focus on other tasks.
In addition, automating code reviews guarantee consistency across reviews and unblocks developers waiting for a review. It significantly increases developer velocity while reducing engineering costs.
Automate Code Reviews
In this article, we will explain step by step how to automate code reviews on Github using Code Inspector, a code analysis platform that empowers developers to write better software. Code Inspector offers a function to automate code reviews that detect design, security, safety, good practice enforcement issues in code, as well as duplicates of complex functions.
Step 1: Install the GitHub App on your repository
Go on https://github.com/marketplace/code-inspector and install the application. Click on “Install for free” as shown below.
Then, click on “Complete order and begin installation” as shown below.
Finally, choose the repository you want to enable the automated code repository and select “Install & Authorize”, as shown below.
Step 2: Push a Pull Request
To demonstrate the capabilities, we will start with a small Python project that has just a few lines of code. We will voluntarily put some errors.
In the terminal, go in an empty repository. We will assume you have a repository, all the commands below must be typed in the directory that contains the repository.
Before we start to write any code, let’s switch to a new branch, called code-review-demo
Let’s write a very small Python program that sums two numbers. We write the following code in the file main.py.
Then commit and push our changes to our Github repository.
We pushed the branch to the remote repository on GitHub. Now, we need to create a pull request that will formally ask to push the branch on the master. The URL to create the pull request is provided when we pushed the branch and we just need to visit it: https://github.com/codeinspectordemo/demo/pull/new/code-review-demo
When you open the link, you need to put a title and message for the Pull Request. Click on “Create pull request” below to create it.
Step 3: Check the results in the Pull Request
The pull request will then be analyzed. Once the analysis is finished, you will see the summary of the analysis in the pull request. To see the result for each analyzed file, click on the File tab as shown below.
Code Inspector adds comments on each coding issue and explains what is wrong with the code.
Step 4: Fixing and Validating Code does not have an issue
We can fix and address the issue reported in the automated review.
In the present case, according to the review, we need to:
In the present case, to fix the issues reported by the Code Inspector, we added documentation for the module to make sure the function uses the snake_case rule. We also added a final newline after the print statement.
This is how the correct code looks.
Once you modified the code, update it on the remote repository.
The pull request status will be automatically be updated and we have the guarantee that the updated code has been verified and is correct. Looking at the history of commits, we can see that the first commit did not pass the automated code review while the updated code passes all verification.
Wrapping Up
In this tutorial, we explained how to automate code reviews on GitHub with Code Inspector. While the example we took in this tutorial is basic, code Inspector supports more than ten languages and can be used on multiple platforms, including GitHub, Gitlab or Bitbucket. The Code Inspector engine includes rules for code duplicates, complexity or even readability. You can also integrate our analysis engine in your Continuous Integration pipeline in order to block merge or code that does not meet a given quality standard.
Code review без ревьювера: 8 инструментов, которые помогут улучшить код
Авторизуйтесь
Code review без ревьювера: 8 инструментов, которые помогут улучшить код
Автор перевода Мария Багулина
Все любят конструктивные code review. Они помогают улучшить качество кода, что в конечном счёте повышает надёжность продукта. Но многим не нравится, что процесс code review часто затягивается и pull request’ы принимаются крайне медленно.
Мы уже писали о том, как эффективно проводить code review, но не всегда достаточно одних знаний — важно, чтобы у вас были правильные инструменты. В этой статье расскажем о нескольких хороших продуктах для code review, рассмотрим плюсы и минусы каждого из них.
Эти инструменты будут полезны не только тем, кто проводит code review, но и разработчикам, которые хотят улучшить свой код и найти в нём слабые места или возможные проблемы. Многие из продуктов доступны в GitHub Marketplace и бесплатны для opensource и частных проектов.
AccessLint
Насколько хорошая доступность у вашего программного обеспечения?
Скорее всего, вы не знаете ответ. Хотя стандарты веб-доступности хорошо документированы, они редко являются частью code review.
Исправить это призван AccessLint, который автоматически запускает серию тестов и комментирует ваш pull request, предлагая решить проблемы с доступностью (если они есть). Сюда также входят проверки доступности для людей с временными недугами (например сломанной рукой) или незначительными заболеваниями.
Если вы ещё не задумывались о доступности вашего продукта, то самое время начать. Во многих странах это является юридическим требованием. В США подают иски против веб-сайтов, которые не соответствуют рекомендациям ADA (Americans with Disabilities Act). В Великобритании доступность веб-ресурсов защищается Законом о равенстве (Equalities Act).
А теперь к преимуществам и недостаткам AccessLint.
Плюсы
Минусы
Стоимость
Imgbot
Когда вы сосредоточены на написании кода в установленный срок, легко забыть об оптимизации изображений.
Иллюстрации меньшего размера (имеется в виду размер файла, а не самой картинки) будут быстрее загружаться и повысят коэффициент конверсии. Поэтому очень важно не упускать это из виду.
Imgbot — простой и эффективный инструмент, который позволяет без потерь сжимать все изображения в ваших репозиториях.
Плюсы
Минусы
Стоимость
LGTM — платформа для анализа кода, которая фокусируется на поиске критических уязвимостей и предотвращении проблем.
LGTM проводит более чем 1600 тестов, и, находя проблему, автоматически помечает её в pull request.
LGTM очень хорошо справляется со своей работой благодаря исследованиям команды в области безопасности, которая на текущий момент нашла более ста CVE (Common Vulnerabilities and Exposures) в таких больших проектах, как UBoot, Apache Struts, ядро Linux, Memcached, VLC и Apple XNU.
Среди анализируемых проблем — внедрение регулярных выражений, XSS-уязвимости и низкое качество кода, приводящее к снижению безопасности.
Плюсы:
Минусы:
DeepSource
DeepSource используется такими компаниями, как NASA, Uber и Slack. Он автоматически обнаруживает уязвимости и проблемы с документированием кода.
Примеры анализируемых проблем:
DeepSource автоматически добавляет аннотации и комментарии к pull request’ам, облегчая обнаружение проблем и гарантируя безопасность конфиденциальных данных. Это ускоряет процесс code review и обеспечивает более высокое качество проекта.
Плюсы
Минусы
Стоимость
Codelingo
После того, как вы установили стандарты качества кода, необходимо убедиться, что они выполняются. Большинство команд используют для этого линтер, но есть и другой вариант.
Codelingo позволяет устанавливать и проверять стандарты качества программно в файле codelingo.yaml.
Основное преимущество Codelingo перед стандартными инструментами в том, что вы можете гибко задавать правила, которые использует именно ваша команда, а не ограничиваться универсальным линтером.
Если в pull request’e не соблюдаются правила, Codelingo автоматически оставляет комментарии и отправляет уведомление.
Плюсы
Минусы
Стоимость
DeepScan
DeepScan — усовершенствованный инструмент статического анализа, который поддерживает JavaScript, TypeScript, React и Vue.js.
Он автоматически определяет возможные ошибки во время выполнения и потенциальные проблемы с качеством кода. DeepScan также предоставляет полезные показатели производительности участников команды и показывает, насколько точно они следуют стандартам кода. Это помогает менеджерам обеспечивать конструктивную обратную связь.
Система оценивания DeepScan присваивает проектам оценки: «Плохо», «Нормально» или «Хорошо».
Плюсы
Минусы
Стоимость
CodeScene
CodeScene — инструмент автоматического анализа кода. Его основное отличие от традиционных методов в том, что CodeScene учитывает историю изменений и оценивает эволюцию всей системы. Это позволяет определять проблемы с качеством кода в зависимости от подхода к его написанию. CodeScene фиксирует, какой программист написал определённый фрагмент кода, что даёт ему возможность оценивать эффективность команды, отслеживать межгрупповые зависимости и находить узкие места в координации.
Плюсы
Стоимость
FeaturePeek
FeaturePeek — инструмент для предварительной сборки и развёртывания ПО.
Один из самых утомительных этапов code review — локальный запуск ветвей ваших коллег для проверки корректной работы их кода.
Правда, этот шаг иногда просто пропускается теми специалистами, которые не разбираются в Git или фронтенд-разработке (например дизайнерами или менеджерами по продукту).
Благодаря автоматическому предварительному развёртыванию каждого pull request’а те, кто выполняет code review, смогут просто нажать на ссылку и посмотреть, как работает код, прежде чем выполнить merge.
FeaturePeek предоставляет инструменты для совместной работы, среди которых комментирование, регистрация новых проблем с помощью шаблонов, запись экрана и многое другое. Эта функциональность входит в стандартную комплектацию FeaturePeek и не требует никаких изменений в стеке фронтенда.
Плюсы
Стоимость
А какими инструментами для code review пользуетесь вы? Пишите в комментариях.
Почему мы для code review выбрали Bitbucket, а не GitHub
В нашей небольшой компании (6 backend + 4 frontend разработчика) для code review (далее CR) мы использовали Gerrit. Gerrit используется, например, для разработки Android. Это инструмент, дающий очень много свободы в настройке процесса CR, но мы от него отказались. Почему? Он прекрасен для суровых backend парней, который легко делают interactive rebase, merge, resolve conflict, amend commit и т.д. Люди из frontend команды по ночам плачут в подушку от тягот рабочего процесса в Gerrit.
В попытке организовывать наш рабочий процесс так, чтобы все были счастливы, мы выбирали одно из популярных решений, которое бы подходило всем. Другими словами, решение не должно содержать критических недостатков для всех разработчиков.
Мы пришли к Bitbucket. Под катом ответы на вопросы почему Bitbucket и почему не GitHub.
1. Unlimited private repos
Тарифные планы GitHub основываются на количестве приватных репозитериев. Тарифные планы Bitbucket — на количестве разработчиков в команде. Т.е. GitHub больше подходит для больших команд с малым количеством проектов, а Bitbucket — малым и средним командам с большим количеством проектов. Мы как раз являемся вторым вариантом и платим 10$ в месяц вместо 100$ в случае использования GitHub.
2. Side-by-side diff
После Gerrit side-by-side diff является необходимым условием, Bitbucket им обладает:
Здесь есть несколько некритичных недостатков, таких как невозможность комментирования кода в модальном окне side-by-side diff (issue).
3. Запрет push-а в master ветку (issue)
4. В ногу со временем
На днях Bitbucket выкатили новый резиновый интерфейс. Конечно, есть недочеты, но хорошая тенденция очевидна.
5. Приятные мелочи
Организация хранения кода в GitLab и интеграция код ревью в GitFlow
Не так давно на одном из проектов нашей компании было принято решение наконец отказаться от использования Subversion для хранения и версионирования кода в пользу Git.
Основными целями перехода были следующие:
Обязательным условием для достижения поставленных целей было использование GitLab (этот сервер Git уже использовался у заказчика и там даже уже жил код, относящийся к фронтовой части решения) и Jira (также уже использовалась у заказчика).
В качестве целевой модели разработки было предложено использовать Git Flow, добавив в неё процедуру код ревью. Данная модель разработки де факто стала стандартом в разработке программного обеспечения с открытым исходным кодом и используется большинством гигантов индустрии. Именно поэтому её поддержка встроена во многие популярные средства работы с Git. На тему его использования написано большое количество материалов, приведу наиболее удачные из них для первоначального ознакомления: раз и два.
Сама по себе эта модель предлагает лишь общие принципы ведения кода, оставляя за рамками процессы, сопутствующие его написанию. Поэтому реализация всего остального, в том числе код ревью, зависит от конкретного сервера Git. В этом плане наиболее удобен GitHub: он изначально строился как платформа для совместной работы большого количества независимых разработчиков и позволяет ограничивать права на отправку коммитов (Push) в репозитории с возможностью создания запросов на отправку кода. Помимо этого, GitLab предлагает свой рабочий процесс для ведения кода под названием GitLab Flow, заточенный под использование GitLab CI. Поэтому в GitLab функционал по созданию запросов на отправку кода не реализован и для проведения ревью кода изменений предлагается использовать запросы на слияние веток. Для сборки и установки артефактов на проекте уже использовался Jenkins, позволяющий гибко создавать и настраивать задачи сборки и развёртывания, и на GitLab CI было решено не переходить, попутно отбросив идею использования GitLab Flow.
Также отмечу, что для проекта были настроены интеграции в Jira и Git. В Jira в плагине Git был добавлен для отслеживания репозиторий, созданный для хранения исходного кода, а в GitLab у данного репозитория была настроена интеграция с Jira в разделе «Интеграции» репозитория.
Для решения данной задачи был разработан рабочий процесс для работы с кодом, по своей структуре схожий с Git Flow, но позволяющий производить ревью кода при каждом выносе изменений в основные ветки процесса (develop, release-n и master) средствами GitLab. Далее будет описан получившийся процесс, а также смежные с ним этапы непрерывной интеграции и доставки ПО на стреды. В скобках приведены соответствующие команды для выполнения.
Репозиторий, созданный для хранения исходного кода, выкачивается в локальный репозиторий (git clone) и в нём инициализируется Git Flow (git flow init) — помимо ветки master (для создания тегов с целью хранения стабильных релизов) создаётся ветка develop (основная ветка разработки, в которую интегрируются ветки функций, релизов и исправлений), задаются маски для веток функций, релизов и исправлений, а также совершается переход в ветку develop.
При разработке загружается актуальная версия ветки develop и из неё создаются ветки для разработки новых функций (git flow feature start MYFEATURE) в соответствии с кодами задач Jira, в рамках которых ведётся разработка.
Чтобы обеспечить непрерывную интеграцию в репозитории GitLab, в разделе «Интеграции» настраивается Web Hook, который осуществляет вызов в Jenkins задачи для сборки и установки нового функционала на тестовую среду. Jenkins с помощью плагина для работы с Git выкачивает исходный код, получает из него название задачи и с помощью API Jira запрашивает список компонентов, которые были изменены и должны быть собраны, запускает процесс сборки, осуществляет прогон Unit тестов и при их удачном прохождении загружает созданные артефакты в Sonatype Nexus и устанавливает их на тестовую среду. Если же на одном из этапов произошёл сбой или Unit тесты завершаются неудачей, то с помощью плагина для Telegram команда разработки оповещается об исходе сборки. Если же установка прошла успешно, то команда QA оповещается о готовности задачи к тестированию.
Для запроса на слияние разработчик разрешает конфликты слияния (в случае наличия) и производится code review, в ходе которого возможно создание дополнительных коммитов с исправлениями полученных замечаний. После успешного завершения ревью производится слияние веток. Сразу после переноса исправления в ветку develop также срабатывает Web Hook для вызова задачи в Jenkins для сборки, прогона Unit тестов, загрузки созданных артефактов в Sonatype Nexus и установки исправления на тестовую среду. Для исправлений работает аналогичный механизм оповещений.
Если все дефекты исправлены, то производится загрузка актуальной версии ветки develop и от коммита слияния ветки hotfix-MYFEATURE с веткой develop создаётся ветка release-m.n (git flow release start RELEASENAME [BASECOMMIT]).
Создание релизной ветки также инициализирует запуск Web Hook для вызова задачи в Jenkins, которая выкачивает исходный код из Git, получает из него название релизной ветки и с помощью API Jira запрашивает список компонентов, которые были изменены в рамках задач релиза, выкачивает актуальные версии из Sonatype Nexus и устанавливает их на среду регрессионного тестирования. Вслед за установкой релиза на среду регрессионного тестирования запускаются скрипты подготовки среды к тестированию (перезапуск приложений, очистка БД и пр.) и производится прогон регрессионных автотестов для проверки работы основного функционала системы, по результатам которого формируется отчёт с помощью плагина Allure Reports для Jenkins. После установки команда QA оповещается в Telegram о результатах прогона автотестов и готовности релиза к ручному регрессионному тестированию.
Когда все дефекты исправлены, производится установка релиза на продуктивную среду. Для этого производится слияние ветки release-m.n с ветками develop и master, а также создаётся релизный тег.
При его создании инициализирует запуск Web Hook для вызова задачи в Jenkins, которая выкачивает исходный код из Git, получает из него номер релиза и с помощью API Jira запрашивает список задач, которые вошли в релиз и компонентов, которые были изменены в рамках этих задач, после чего выкачивает актуальные версии артефактов из Sonatype Nexus и устанавливает их на продуктивную среду.
С хотфиксами для прода было решено использовать процесс, аналогичный релизному – в противном случае теряются стадии тестирования выносимых изменений.
При внедерении процесса также было проведено обучение для сотрудников, не имеющих практики работы с Git и GitLab, для которого была разработана соответствующая программа обучения. С её помощью вы сами сможете проводить обучение по использованию Source Tree и Intellij IDEA для работы с Git, а также GitLab для проведения ревью кода. В следующем посте приведу её, дополнив иллюстрациями.