Какой инструмент обеспечивает code review

Code review: вы делаете это неправильно

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

На рынке есть куча инструментов для ревью кода с готовыми сценариями использования, рекомендациями и правилами. GitHub, Phabricator, FishEye/ Crucible, GitLab, Bitbucket, Upsource — список можно долго продолжать. Мы в Badoo тоже в своё время с ними работали: в своей предыдущей статье я рассказывал нашу историю ревью кода и о том, как мы пришли к изобретению собственного «велосипеда» — решения Codeisok.

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

Именно поэтому другую часть айсберга можно и не заметить.

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

После прочтения этого вступления у вас может возникнуть вопрос: а что сложного в ревью кода? Дело-то плёвое. Тем более что большинство инструментов, перечисленных выше, сразу и флоу ревью предлагают (из коробки: поставил, закоммитил/ запушил — и вперёд!).

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

Когда-то давным-давно, когда я работал в другой компании, мне в память глубоко запала беседа о ревью кода с одним из ведущих разработчиков. Это был p1lot. Возможно, кто-то из читателей знаком с ним (p1lot, привет :)). Сейчас он работает с нами в Badoo, и это здорово.

Так вот, PILOT тогда сказал: «Самое сложное для меня в процессе ревью — пойти на компромисс и пропустить готовую и корректно работающую задачу дальше, даже если я знаю другой способ её решения и даже если мой способ мне нравится больше». На мой взгляд, эта мысль является ключевой. И основной посыл всей моей статьи так или иначе вертится вокруг этого постулата.

Зачем нужен процесс ревью кода?

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

Нужно ответить всего на три вопроса:

Сколько времени занимает ревью кода для средней (сферической в вакууме) задачи?
Как вы минимизируете время ревью?
Как вы определяете, что ревью конкретной задачи сделано правильно?

Если вы не знаете, сколько времени потребуется на ревью, и не минимизируете его постоянно, то как вы осуществляете планирование? Возможна ли ситуация, когда исполнитель, который делал ревью четыре часа, не пил чай половину этого времени? Можно ли быть уверенным в том, что от задачи к задаче время на чаепитие не увеличивается? А, может, ревьюер вообще не смотрит код, а просто нажимает «Code is OK»?

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

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

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

Помните про готовые инструменты для ревью кода, предлагающие свои подходы и флоу? Мне, например, интересно, как бы ответили на вопрос разработчики этих инструментов. Будут ли коррелировать их ответы о «правильности» ревью с ответами ваших сотрудников? Не уверен. Иногда я грустно наблюдаю, как кто-то внедряет у себя инструменты ревью, ни на минуту не сомневаясь, что они необходимы. То ли люди делают это «для галочки», то ли чтобы отчитаться, что «ревью кода внедрили, всё хорошо». И в итоге забывают про это.

Не хочу быть Кэпом, но тем не менее. Общаясь с сотрудниками, обращайте внимание на ответы вроде «Потому что так заведено» или «Это же best practice, все так делают». Вы и сами отлично знаете, что не нужно бездумно внедрять какой-то процесс, не понимая, зачем он нужен. Любой процесс должен быть оправдан и внедрён (если необходимо) с поправкой на нужды бизнеса и проекта, а также на проблемы, которые действительно существуют и которые действительно хочется решить. Карго-культу в компании с хорошей инженерной культурой не место.

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

Плохое ревью кода

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

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

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

Обмен знаниями

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

Я не раз спрашивал людей, что они имеют в виду под «обменом знаниями». И в ответ слышал разное.

Во-первых, это демонстрация новичкам (в команде или затронутом компоненте) принятых правил и практик: вот так у нас принято делать, а так мы не делаем, потому-то и потому-то.

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

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

Давайте пройдёмся по всем пунктам и попробуем оценить, насколько они уместны в процессе ревью.

Code review как инструмент обучения новичков

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

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

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

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

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

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

Какой можно сделать вывод? Описанный выше процесс направлен на достижение иной цели: не на обучение, а на контроль. И этот самый контроль необходим не только новичкам, а команде в целом.

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

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

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

Продолжая разговор об обучении новичков в процессе ревью кода, проведём аналогию. Допустим, вы производите какой-то товар, например, торты. Допустим, вы получили заказ на торт для свадьбы VIP-персоны. Доверите ли вы «ревью» готового торта новичку? Готовы ли вы к тому, что новый кондитер возьмёт на себя ответственность за позор или успех всей пекарни на этой свадьбе? А может, вы хотите, чтобы он на этом этапе познакомился с правилами, принятыми в команде (как выпекать коржи, готовить крем и настаивать клюкву на коньяке)? Очевидно, что и процесс знакомства новичка с правилами, и контроль с его стороны — довольно странные вещи на данном этапе: торт-то уже испечён. Так почему же с фичами и кодом мы можем поступать по-другому? Или фичи, которые мы запускаем, не несут за собой позор или успех нашей команды в глазах пользователей и заказчиков?

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

Но во-первых, чему новичок научится на пустяковых задачах, в которых мало изменений кода (и эти изменения не в критичных местах и для бизнеса наверняка не столь важны, раз задача несрочная)? Как он может научиться печь торты, если всё время взбивает сливки? Переход от простого к сложному, конечно, нужен. Но делать это необходимо, тщательно контролируя процесс. Новичков нужно учить, а не бросать учиться самостоятельно.

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

Представим, что мы открыто заявляем, что задачи, которые нам даёт продакт-менеджер, нужны для обучения новичков. Почему? А так же, как с ревью кода: мы ведь поручаем некоторые простые и несрочные задачи новичкам, чтобы они научились работать так, как у нас принято.

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

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

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

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

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

Code review как свежий взгляд на код

Идём дальше. Следующий сценарий «обмена опытом» такой: мы в команде что-то делаем, соблюдая внутренние договорённости, и у нас замылился глаз, а тут пришёл новый человек (из другой компании или из другого компонента) — и, возможно, он увидит недостатки в нашей организации работы.

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

Но опять вернёмся к сроку жизни задачи и наступлению этапа ревью кода. Не поздновато ли? Торт уже испечён, коржи смазаны кремом, розочки приклеены. Цена ошибки очень высока. И тут мы узнаём, что в другой пекарне в коржи добавляют соду, гашенную лимонным соком, для пышности. И что? Что делать? Переделывать?

Очевидно нет, так как: 1) мы всегда делали без соды, и результат был неплохим; 2) возможно, покупатели берут торты именно у нас, а не в другой пекарне, потому что им не нравится привкус соды; 3) торт уже готов, свадьба сегодня вечером, а новый торт испечь мы не успеем.

Тогда зачем это всё? Делиться опытом надо. Свежий взгляд нужен. Но, как мне кажется, на другом этапе. Например, перед тем как печь коржи, можно уточнить у новичка: «А как вы делали это раньше? А почему этот способ лучше?» И, наверное, стоит испечь пару тортов по-старому и по-новому, чтобы дать нашим постоянным клиентам попробовать и узнать их мнение.

Бездумное внедрение best practices, увиденных в статьях или докладах, может нанести вред компании и продукту. «Соду добавляют в коржи все крупные игроки: „Бугл“, „Трейсбук“, „Райл.ру“, „Юмдекс“. Все так делают». И что? Из-за этого Петя должен немедленно взяться за переделку задачи, которая уже готова?

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

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

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

Code review как знакомство с частью кода

Пожалуй, это выглядит как самая разумная и понятная часть, с которой многие согласны. Сценарий тут подразумевается такой: один программист написал код задачи, остальные на него посмотрели, изучили — и теперь знают, как с ним работать. Таким образом мы уменьшаем риск возникновения bus factor: если разработчик уйдёт, другие смогут успешно работать с его кодом. А также мы готовы к тому, что в следующий раз этот код может «потрогать» кто-то другой, и в этом случае он уже будет знать, как с ним работать.

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

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

Допустим, он изобрёл какой-то крутой алгоритм сортировки (может, давно уже изобрёл и постоянно использует, а может быть, только что). Нужно ли, чтобы об этом знали все члены команды? Конечно, да. Нужно, чтобы люди узнали, что крутой программист Вася создал нереально быстрый и эффективный алгоритм сортировки, который будет полезен всем.

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

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

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

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

Чувствуете? То, что я описываю, это не процесс ревью кода — это процесс создания и одобрения общих практик и подходов. Совершенно иной процесс.

И на этом этапе снова могут всплыть best practices от коллег и «В моей прошлой компании это делали по-другому» или «Я читал, что это делают иначе». И что? Best practices в общем случае, для сферической компании в вакууме, могут быть подходящими. Означает ли это, что все они будут полезны в вашей компании? Как минимум не всегда. И уж точно это не значит, что кто-то должен немедленно переписать свой код, на написание которого уже потрачено время.

Соответствие любым абстрактным или внешним best practices, гайдлайнам, модным тенденциям и т. д. — каким-то правилам, которые оторваны от компании/ контекста — ради самого соответствия никому не нужно. «Статические методы считаются плохим тоном», «Такое теперь надо выносить в трейты», «Синглтон — плохая практика, лучше использовать фабрику и DI». Кому надо? Кем считается?

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

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

Во-первых, мало кто готов «прямо сейчас» отвлечься и оценить «грязность» хака, ведь все заняты своими задачами. А во-вторых, никто ничего не запомнит. Да и люди в команде меняются, и, если кто-то в будущем наткнётся на этот хак, у человека так или иначе возникнет вопрос: почему сделано именно так? И оптимальным решением будет добавление комментария прямо в код. Комментария, объясняющего причину, которая вынудила прибегнуть к такому хаку (вспоминаем правила хорошего тона при комментировании кода: мы описываем в комментариях не что мы делаем в коде, а почему мы делаем именно так).

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

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

Ну и, наконец, если мне всё ещё не удалось вас убедить, то у меня вопрос: как понять, что обмен знаниями в процессе ревью произошёл?

— Петя, ты прочёл код, который написал Вася?
— Прочёл.
— Всё понял?
— Всё понял.

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

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

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

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

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

Code review как документация

Ещё один вариант ответа на вопрос «Зачем нужно ревью кода?» был про документирование. Тут может быть не совсем очевидно, что имеется в виду, поэтому поясню.

Сценарий подразумевается такой: разработчик и ревьюер кода о чём-то договорились в комментариях к ревью, и в будущем, если у кого-то возникнет вопрос о том, почему в данном месте сделано именно так, информацию об этом можно будет найти в ревью. То есть по git blame найти коммит, по коммиту найти тикет, по тикету найти ревью, в ревью найти обсуждение, изучить его и понять, почему сделано именно так.

Получается, что разработчик, у которого и так много источников информации — стандарты и соглашения, техническое задание, тикет в багтрекере, сам код (с комментариями или без) — должен лезть ещё в один. И читать весь тред, пытаясь уловить нить беседы и понять причины, побудившие сделать именно так. Причём мнения сторон в этом треде могут измениться несколько раз. Звучит странно, не правда ли?

Но вопросы действительно могут возникнуть. Что делать в этом случае?

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

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

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

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

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

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

Хорошее ревью кода

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

Я думаю, что в данном случае нужно иметь в виду тот факт, что смешивать несколько процессов в один — не всегда правильно. Особенно если речь идёт о процессах, продолжительность которых сложно планировать и контролировать.

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

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

Архитектура и дизайн решения

Насколько предлагаемое решение соответствует задаче? Насколько оно сложно для понимания, поддержки, расширения? Насколько получившаяся архитектура требовательна к ресурсам и какова сложность реализованных алгоритмов? Можно ли было сделать проще, понятнее, дешевле? Сделано ли что-то лишнее, что не относится к задаче? Используем ли мы внешние зависимости и библиотеки? Насколько это оправданно? И так далее.

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

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

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

Соблюдение правил и соглашений, принятых в команде

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

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

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

Корректность решения

Имеет ли решение какие-то недостатки? Опечатки в коде, магические числа и другие неопределённые константы. Магические строки и другие неожиданные данные, которые программист не учёл при решении задачи. Проверки на null и другие места, где потенциально можно «выстрелить себе в ногу». Проверка решения с точки зрения информационной безопасности и так далее.

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

Тестируемость кода и наличие юнит-тестов

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

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

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

Заключение

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

И напоследок дам ещё несколько советов.

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

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

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

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

Но решение, конечно, остаётся за вами.

code review
разработка
программирование
менеджмент
управление разработкой
тестирование

Блог компании Badoo
Программирование
Управление разработкой
Управление проектами
Управление персоналом

Ревьювер. Инструмент для проведения code review

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

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

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

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

Используется более 5 конфигураций, включая ЗУП, БП, УАТ2, ЕРП УХ, КА 1.1.

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

SonarQube используется в работе, но он проверяет только основное хранилище.

Разработчик реализуют задачу в своей базе потом переносит это в общее хранилище.

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

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

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

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

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

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

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

Работа со скриншотами построена на внешней компоненте VanessaExt, работа идет через буфер обмена.

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

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

Для удобства работы с кодом встроен редактор, который многие встречали на просторах 1С, основывающийся на редакторе Monaco. Также было добавлено улучшенное форматирование кода OneStyle, входящее в первую версию Smart Configurator.

Редактор кода используется для добавления решения на уровне ошибки и в самом документе.

Кроме того, разработчики следят за форматированием кода и для этого используют еще один внутренний инструмент ones-formatting на основе двух версий Smart Configurator. Это позволяет существенно упростить работу с кодом в системе 1С и повысить эффективность работы разработчиков.

Справочник «Ошибки» является основным объектом в работе подсистемы. Каждый элемент справочника содержит информацию о типе и важности ошибки, которые знакомы нам по SonarQube.

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

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

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

Из всех настроек стоит отдельно остановится на показателях:

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

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

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

Реализована работа с метаданными проекта.

Для выгрузки метаданных из конфигурации используется специальная обработка «ВыгрузкаМетаданныхПроекта.epf«, которая позволяет выгрузить метаданные в формате JSON. Кроме того, есть возможность частичной выгрузки метаданных.

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

Функционал по работе с метаданными проекта позволяет привязывать замечания к метаданным в документе «Ревью«. Для этого в табличную часть «Замечания» были добавлены два новых реквизита: проект и метаданные.

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

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

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

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

Новый формат комментариев в JIRA: комментарии разделены по проектам и метаданным.

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

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

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

Среди основных добавленных подсистем можно выделить:

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

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

Конфигурацию, разработанную с использованием указанных инструментов, проверяем с помощью SonarQube.

Для написания юнит-тестов используем YAXUnit.

Для расчета покрытия тестами используем Coverage-cli.

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

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

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

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

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

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

FAQ

Что делать, если нужно отразить не ошибку, а предложение по доработке?

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

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

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

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

P.S.

По вопросам и предложениям можете создать issues на GitHub.

Также хотелось бы поддержать проект saby v8unpack – утилита для сборки и распаковки бинарных файлов 1С:Предприятие 8.х (cf, cfe, epf) без использования технологической платформы с максимально приближенной структурой метаданных.

Материалы

Диагностики — BSL Language Server
OneStyle
Чек-листы для проведения Code Review
По следам код-ревью
Красота разработки в 1С, или художественная верстка кода
Распространенные ошибки разработчиков, приводящие к проблемам производительности
Антипаттерны программирования в 1С
Набор стикеров «DevRunner»
Набор стикеров «Разработчик»
saby v8unpack

Инструменты

reviewer
Phoenix bsl
VanessaExt
Консоль кода для 1С 8.3 (Управляемые и обычные формы)
ones-formatting
Smart Configurator
Smart Configurator 2
YAXUnit
coverage-cli
Презентация разработана с помощью редактора Canva
В роли редактора СhatGPT

Другие материалы, которые могут вас заинтересовать

Мобильная разработка:

Переносим HTML интерфейс на 1С
Взаимодействие с NFC через мобильную платформу 1С
Простое мобильное приложение на мобильной платформе 1С

1С Специалист:

[ERP] Бюджетирование. 1С:Специалист-консультант. Часть 2
[ERP] Бюджетирование. 1С:Специалист-консультант. Часть 1
[Специалист-консультант] ERP (Производство и ремонты, Управленческий учет, Бюджетирование) + УТ. Решения и шпаргалки к четырем экзаменам
[ERP] Планирование и выполнение ремонтов
Решение задач и материалы для подготовки в одном архиве для «1С:Специалист по конфигурированию и внедрению торговых решений» / «Специалист УТ 11»

Перенос данных:

Перенос остатков из КА 2.4 в БП 3.0
Перенос документов из УТ 10.3 в УТ 11.4

Интеграции:

Интеграция с InSales. Обновление цен и остатков товаров
Интеграция c lptracker

Прочее:

Подсистема Service Desk для типовых конфигураций
Конфигурация «Стоматологический кабинет» на управляемых формах
[Заметки] Scrum за 5 минут

# Code review

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# Примеры плохого поведения
- Токсичное поведение
  - Переход на личности
  - Сарказм
  - Раздражение
  - Неизвестно, кто должен делать code review
  - Неизвестны критерии прохождения. Процесс может продолжаться бесконечно
  - Список правок не разбит на группы по приоритетам
  - Разработчик долго ожидает code review
  - В merge request приходят огромные фичи
  - Не настроены linter-ы и/или автоматические тесты
  - Разработчики пытаются запомнить список правок
  # Примеры хорошего поведения
  - Адекватная обратная связь
    - Уточняющие вопросы вместо прямого указания на ошибки
    - Нейтральность или доброжелательность
    - Разработчики понимают, что в их интересах делать code review
    - Все знают список требований для прохождения code review
    - Список правок удобным образом приоритизирован. Например, с помощью emoji ��, ��
    - Обратная связь – быстрая, в идеале – в течение дня
    - Merge requests атомарные
    - Используются linter-ы и автоматические тесты
    - Разработчики не пытаются запоминать список правок в уме
    # Способы прокачки
    
    # Практика и способы прокачки
    
    Code review выглядит просто. Проверяете merge request на ошибки и пишете о них, но есть нюанс. Важно понять и принять, что это долгосрочный процесс. Настоящие причины ошибок – пробелы в знаниях, сниженная мотивация. Lead должен включать soft skills, чтобы не стрелять в ногу себе и команде.
    
    Полезно проводить «review» до написания кода, особенно для junior devs. Lead должен убедиться, что разработчик напишет задачу верным способом. Выяснять нужно с помощью уточняющих вопросов.
    
    # Умение критиковать
    
    Умение критиковать – это ключевой навык.
    
    # Как смягчить критику вербально:
    - Задавать уточняющие вопросы вместо прямого указания на ошибки
    - Сперва похвалить, затем – критиковать
    - Хвалите, если всё хорошо
    - Feedback от разработчика о том как прошло review. Да, взять и спросить
    - Не говорите «ТЫ сделал плохо»
    Практиковаться можно «в уме» на merge request. Когда поняли что научились – давать настоящий feedback.
    
    # Как смягчить критику невербально:
    - Следите за эмоциональными состояниями: своим и разработчика
    Практикуйтесь «в уме» на косячных merge request. Вы не должны злиться и раздражаться на «эти тупые ошибки ��». Для настоящих review начинайте с хороших merge requests и постепенно переходите к косячным.
    
    Чтобы не злиться самому помогут:
    - Понимание себя и истинных причин раздражения
    - Понимание что цель не найти баги, а обучить разработчика не делать их снова; или помочь разработчику сменить позицию или компанию на более подходящую
    - Психолог
    - ~~Успокоительное~~
    - Просто будьте проще, от ваших багов навряд ли кто-то пострадает (с) Капитан Очевидность
    Понять что разработчик устал, ненавидит вас, могут помочь:
    - Практические книги по психологии
    - Психологические тренинги
    # Дополнительно
    
    Без невербального общения (переписка в комментариях github) разработчик может додумать ваши эмоции. Старайтесь быть ближе, как минимум – созвонитесь.
    
    # Процесс review фичи
    1. Выяснить, какую бизнес-логику писал разработчик
    2. Рассмотреть ключевые элементы бизнес логики, архитектуру решения
    3. Углубиться в детали
    # Нужно выяснить какую бизнес-логику писал разработчик
    
    Об этом могут рассказать разработчик, менеджер или таска в jira. Feedback выдаётся разработчику и/или менеджеру при проблемах с бизнес-логикой.
    
    Чтобы прокачать этот скилл можно пройтись по задачам с описанием.
    
    Чтобы получить косячные задачи, можно:
    - Зайти в «achieved»
    - Попросить придумать косячные задачи
    - Или попросить придумать задачи косячного менеджера
    Результат – понимание задачи или аргументы что не так с задачей. Возможно – список на исправление.
    
    # Рассмотреть ключевые элементы бизнес логики, архитектуру решения
    
    Об архитектуре решения и ключевых моментах расскажет разработчик. Feedback нужно выдать ему же.
    
    Практиковаться можно на merge request вместе с разработчиком.
    
    Разработчик самостоятельно расскажет о проблемах, если его спросить. Также он сможет аргументировать, почему он выбрал определённое решение.
    
    Результат – понимание и принятие или аргументы:
    - Почему это нужно исправить
    - Что будет, если не исправить
    - Соглашение с разработчиком как исправить
    # Углубиться в детали
    
    На проекте должен быть linter. Он проверяет отступы, использование необъявленных переменных и другую головную боль.
    
    Если это необходимо – пройдитесь по деталям реализации.
    
    Результат – статус задачи «review закончено» или аргументированный список правок.
    
    # Что ревьюить
    
    В зависимости от целей ревью и времени на него:
    - Наиболее критичные задачи
    - Практики безопасности
    - Архитектуру
    - Задачи junior devs
    - Все задачи
    - Выбранное вами
    Вы должны чётко осознавать, что именно и зачем вы ревьюите.
    
    # Настройка и использование software
    
    # Автоматическая проверка кода
    
    Для ускорения процесса нужно настроить проверку кода на:
    - Синтаксические ошибки
    - Стилистические неточности
    - Предполагаемые ошибки во время исполнения (использование необъявленной переменной и тд)
    - Возможные уязвимости в коде и используемых библиотеках
    Это поможет сократить время на поиск проблем вручную.
    
    # Комментарии
    
    Не полагайтесь на память. Git хостинги дают комментировать участки кода, вести дискуссии. Критичные правки можно записывать например в комментарии к merge request.
    
    Можно настроить автоматическую синхронизацию комментариев с мессенджером.
    
    # Интеграции
    - Git хостинги умеют слать на почту сообщения, связанные с code review
    - Можно добавить интеграцию через API, чтобы слать сообщения в мессенджер
      - О новых merge requests
      - Об утверждённых merge requests
      - О merge requests которые долго никто не проверял
      - Комментариях к коду
      # Работа с другими процессами
      - CI/CD. Если встроить code review в процесс CI/CD, то на выходе можно будет получать более надёжный продукт
      # Вопросы для собеседования
      - Blitz
        
        Что такое code review?
        
        Организован ли у вас в команде code review?
        
        Может ли code review помочь найти баги, которые не может найти тестировщик?
        
        Какие плюсы даёт code review в общем и вашей команде?
        
        Можно ли не делать code review? В каких случаях?
        
        Сколько времени можно тратить на code review?
        
        С какими процессами в команде можно интегрировать code review?
        
        Во время code review вы увидели токсичное поведение одного из ревьюеров; например, сарказм, грубость. Нужно ли с этим что-то делать? Если да, то что?
        
        # Консультации
        
        # Теория
        
        # Статьи
        
        Раскрывают тему:
        
        12 лучших инструментов для ревью кода для разработчиков (2020) Перевод
        
        Ревью кода — это часть разработки программного обеспечения, которая подразумевает тестирование исходного кода для идентификации багов на ранней стадии. Процесс код-ревью обычно проводится перед слиянием с кодовой базой.
        
        Эффективное ревью кода предотвращает попадание багов и ошибок в ваш проект путем улучшения качества кода на ранней стадии процесса разработки софта.
        
        В этой статье мы объясним, что такое код-ревью и изучим популярные инструменты, которые помогают организациям с данным процессом.
        
        Что такое процесс ревью кода?
        
        Основная задача ревью кода заключается в проверке любого нового кода на баги, ошибки, а также на соблюдение стандартов качества, установленных организацией. Процесс ревью кода не должен состоять лишь из одностороннего фидбэка. Следовательно, нематериальная польза код-ревью заключается в коллективном улучшении навыков написания кода в команде.
        
        Если вы хотите инициировать процесс ревью кода в вашей компании, вам в первую очередь следует решить, кто будет проводить ревью кода. Если вы — часть небольшой команды, то можете назначить тимлидов просматривать весь код. В более крупной компании с несколькими проверяющими можете внедрить процесс, при котором каждое ревью закрепляется за опытным разработчиком в зависимости от их загруженности.
        
        Далее стоит рассмотреть временные рамки, очередности и минимальные требования принятия запросов на код-ревью.
        
        Наконец, следует учесть как должна даваться обратная связь в процессе ревью кода. Убедитесь, что вы подчеркиваете положительные аспекты кода, попутно предлагая альтернативы в выявленных недостатках.
        
        Ваша обратная связь должна быть достаточно конструктивной, чтобы позволить разработчику понять ваше видение и, при необходимости, начать обсуждение.
        
        -Старайтесь сохранить информативность обратной связи
        
        Проверяющие могут оказаться в «лимбе» достаточно просто, что приводит к более низкой эффективности и даже контрпродуктивности.
        
        Почему ревью кода критичен?
        
        Процесс ревью кода критичен, поскольку он не похож на формальный учебный процесс в школах/университетах. Вы можете узнать нюансы языка программирования и менеджмента проектов, но ревью кода — это процесс, который эволюционирует в то время как компания находится в процессе «взросления».
        
        Код-ревью критичен, потому как призван:
        
        Позволить убедиться в отсутствии багов в коде.
        
        Минимизировать вероятность возникновения проблем.
        
        Подтвердить, что код придерживается заданных установок.
        
        Повысить эффективность нового кода.
        
        Ревью кода впоследствии ведет к улучшению компетенции членов команды. В то время как старший разработчик осуществляет код-ревью, младший разработчик может использовать обратную связь для улучшения своих навыков программирования.
        
        Как выполнить ревью кода?
        
        Существует четыре способа произвести код-ревью.
        
        Ревью «Из-за Плеча»
        
        Такие проверки выполняются за рабочей станцией разработчика, где опытный участник команды просматривает новый код, выдвигая свои предложения в процессе обсуждения. Это самый простой способ проведения код-ревью, который не требует определенной структуры.
        
        Ревью такого типа проводятся до сих пор, неформально, при этом формальный код-ревью также может иметь место. Просмотр «из-за плеча» традиционно происходил лично, в то же время удаленные команды могут следовать этому методу с помощью коллаборативных инструментов.
        
        Почтовая Рассылка
        
        Хотя код-ревью, проводимые «из-за плеча» — это отличный способ проверить новый код, географически удаленные команды по традиции опирались на электронную почту для ревью кода.
        
        В таком процессе ревью разработчик отправляет diff изменений всей команде разработчиков, как правило, с помощью системы контроля версий (VCS), которые автоматизируют уведомления. Такое сообщение инициирует обсуждение изменений, где члены команды могут запросить будущие изменения, указать на ошибки или запросить уточнения.
        
        —Почтовая рассылка через Google Groups на каждый новый push
        
        Раньше почта была основным способом коммуникации ввиду ее универсальности. Организации с открытым кодом часто поддерживали публичный список рассылки, который также служил средством для обсуждения и предоставления обратной связи по коду.
        
        Несмотря на приход инструментов для ревью кода, списки рассылок до сих пор существуют, хоть и используются они теперь в основном для анонсов и обсуждений.
        
        Парное Программирование
        
        —Парное программирование порой может быть неэффективно
        
        Парное програмиирование — это непрерывный процесс ревью кода. Двое разработчиков находятся за рабочей станцией, но лишь один из них активно кодит, в то время как другой предоставляет обратную связь в реальном времени.
        
        И хотя это может служить хорошим способом просмотра нового кода и обучения разработчиков, парное программирование потенциально является неэффективным ввиду временных затрат. Такой процесс не позволяет ревьюеру заниматься любой другой продуктивной работой во время такой сессии.
        
        С Помощью Инструментов
        
        Такой вид код-ревью включает в себя использование специализированного программного обеспечения (ПО) в целях облегчения процесса ревью кода. Обычно инструмент помогает со следующими задачами:
        
        Организация и отображение обновленных файлов при их изменении.
        
        Способствование диалогу между ревьюерами и разработчиками.
        
        Оценка эффективности ревью кода с помощью метрики.
        
        Хотя эти широкие требования инструмент проверки кода, современного инструментария может обеспечить несколько других функций. Мы рассмотрим ряд инструментов анализа кода позже в этом посте.
        
        Почему Вам стоит Использовать Инструменты для Код-ревью?
        
        Главный результат процесса ревью кода — увеличение эффективности. Хотя все вышеперечисленные классические методы ревью кода работали в прошлом, вы можете потерять эффективность, если не перешли на ревью с помощью инструментов. Они автоматизируют процесс ревью кода, так что ревьюер фокусируется непосредственно на самом коде.
        
        Инструмент интегрируется в ваш цикл разработки для инициации ревью кода перед тем как новый код соединен с главной кодовой базой. Вы можете выбрать инструмент, который совместим с вашим стэком технологий для «бесшовного» внедрения в Ваш рабочий процесс.
        
        К примеру, если Вы используете Git для менеджмента кода, TravisCI для непрерывной интеграции, то убедитесь, что Вы выберете инструмент, который поддерживает эти технологии и подходит для процесса разработки.
        
        Есть два типа тестирования кода в разработке ПО: динамическое и статическое.
        
        Динамический анализ включает в себя проверку кода на следование набору правил и проведение unit-тестов, обычно с помощью предопределенного скрипта. Статическое тестирование кода проделывается после того как разработчик пишет новый код для присоединения к текущему коду.
        
        Теперь давайте рассмотрим одни из самых популярных инструментов для код-ревью.
        
        Более Детальный Разбор 12 Мощных Инструментов для Код-ревью
        
        В этом разделе мы будем обозревать самые популярные статические инструменты для код-ревью.
        
        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-дневный бесплатный период без требования данных вашей карты.
        
        Схоже с 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 поддерживает три самых популярных системы контроля версий — 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 в двух формах: облачное решение и локальное решение.
        
        Облачные планы 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 анализирует каждое изменение в коде, чтобы предвидеть возможные проблемы с его исполнением в связи с изменениями. Также, инструмент может автоматически генерировать полную документацию приложения из кода.
        
        Если вы используете PowerBuilder, SQL-сервер или Oracle PL/SQL и хотели бы специализированный инструмент для ревью кода для ваших потребностей, стоит попробовать Visual Expert.
        
        8. Gerrit
        
        Геррит — это бесплатный веб-инструмент с открытым исходным кодом для Git-репозиториев, написанных на Java. Для запуска Gerrit Вам нужно скачать исходный код и запустить его в Java. Вот процесс установки standalone-версии Gerrit.
        
        Gerrit сочетает в себе функциональность багтрекера и инструмент для код-ревью. В ходе ревью изменения отображаются бок-о-бок в едином diff, с возможностью начать обсуждение по каждой добавленной строке кода. Этот инструмент работает как промежуточный этап между разработчиком и центральным репозиторием. Кроме того, Gerrit также включает в себя систему голосования.
        
        Если вы обладаете техническими знаниями для установки и настройки Gerrit и ищете бесплатный инструмент для ревью кода, он станет идеальным решением для ваших проектов.
        
        9. Rhodecode
        
        Rhodecode — это веб-инструмент, который помогает в проведении ревью кода. Он поддерживает три системы контроля версий: Mercurial, Git и Subversion. В облачной версии стоимость Rhodecode начинается от $8 на пользователя в месяц, в то время как локальное решение стоит $75 на одного пользователя в год. Хотя это программное обеспечение предназначено для предприятий, его комьюнити-версия, которая является бесплатной и с открытым исходным кодом, может быть загружена и скомпилирована бесплатно.
        
        Rhodecode позволяет команде эффективно взаимодействовать через итеративный, диалоговый код-ревью, для повышения качества кода. Инструмент дополнительно содержит слой управления доступом для защищенной разработки.
        
        Кроме того, визуальный changelog (история изменений) помогает вам ориентироваться в истории вашего проекта в различных ветках. Онлайн-редактор кода также предоставлен для внесения небольших изменений через веб-интерфейс.
        
        Rhodecode легко интегрируется в существующие проекты, что делает его отличным выбором для тех, кто ищет веб-инструмент для код-ревью. Следовательно, комьюнити-версия идеально подходит для людей с техническими знаниями, которые ищут бесплатный и надежный инструмент для код-ревью.
        
        10. Veracode
        
        Veracode предоставляет набор инструментов для код-ревью, которые позволяют автоматизировать тестирование, ускорить разработку, интегрировать процесс обновления и повысить эффективность проекта. Набор инструментов для код-ревью от Veracode позиционируется как решение по безопасности, которое ищет уязвимости в ваших системах. Они представляют собой набор из двух инструментов для ревью кода:
        
        Статический анализ: инструмент, который позволяет разработчикам выявлять и исправлять недостатки безопасности в коде.
        
        Анализ Состава ПО: инструмент, который управляет процессами обновления и смягчения недостатков в коде.
        
        Ревью кода является частью Анализа Состава ПО, и вы можете выбрать демо-версию Veracode перед полным переходом на данный инструмент. Вот ссылка для запроса котировки.
        
        11. Reviewable
        
        Reviewable — это инструмент для код-ревью для pull-запросов GitHub. Он является бесплатным для репозиториев с открытым исходным кодом. Планы для приватных репозиториев начинаются от $39 в месяц для десяти пользователей. Поскольку инструмент объединен с GitHub, Вы можете авторизоваться при помощи вашей учетной записи GitHub и начать работу.
        
        Если хотите взглянуть на типичный ревью в 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 для код-ревью и не только.
        
        Теперь ваша очередь: какой инструмент для ревью кода используете? Почему? Расскажите нам в комментариях!
        
        Похожие публикации:
        
        H1 как правильно заполнить
        
        Как сделать чат html css
        
        Метод и функция в чем разница
        
        Что такое mainloop в python