Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

7 советов, как сделать Code Review легким и полезным

Приветствую! Меня зовут Михаил и я фронтенд-разработчик с опытом коммерческой разработки более 6 лет. Я разрабатывал веб-приложения для стартапов, финтеха и продуктовых компаний. На данный момент я тружусь в компании Miro. Наша компания разрабатывает сервис бесконечной доски (endless whiteboard) для совместной работы распределенных команд, проведения воркшопов и многого другого.

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

Что такое Code Review

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

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

Почему Code Review — это сложно и долго

Входной точкой для ревью является Pull Request (PR). PR — это запрос на слияние ваших изменений кода, которые расположены в отдельной ветке, в главную ветку проекта. Именно в этом запросе и происходит ревью вашего кода, поэтому простота и качество Code Review зависит не только от самого кода, но и от того, как оформлен PR.

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

Пример того, как не нужно называть пул-реквесты

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

В дополнении к первой проблеме, важно выделить историю разработки. Любой крупный проект со временем обрастает легаси-решениями, с которыми работают новые программисты. Одним из способов понять, зачем был написан тот или иной код, это посмотреть, кем он был написан и каким пул-реквестом влит в кодовую базу (Blame view). Очень печально в таком случае сталкиваться с пустыми PR с названиями по типу — «Small fix» или «Update module».

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

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

1. Главное правило — цените время ревьювера

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

Первый ревьювер — это вы

Просто представьте, как будто вы читаете свои изменения первый раз. Для этого достаточно открыть git diff changes вкладку (поддерживается большинством популярных IDE).

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

2. Оформите Pull Request

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

Название

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

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

Описание

В описании к PR напишите кратко, что ваш код привносит или какое решение содержит.

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

Пример отличного Pull Request

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

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

Loom видео или любой скриншотер поможет быстро создавать такие демо.

3. Минимизируйте изменения

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

10000 новых строк потребуют огромных усилий для ревью

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

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

4. Делайте рефакторинг отдельной задачей

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

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

5. Отделяйте важные шаги разработки в отдельные коммиты

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

Но не стоит создавать коммиты на каждый новый файл или небольшой фикс. Для этого используйте Squash или Amend, перезаписывая старые коммиты с новыми изменениями или сливая несколько коммитов в один.

6. Не смешивайте изменения стиля кода с функциональным изменением

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

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

Пример нефункционального изменения кода

7. Ваш PR — это письмо в будущее

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

Как пример, существует чудесное расширение для VSCode под названием GitLens, которое позволяет посмотреть историю изменений в редакторе.

Просмотр истории коммитов по каждой строке

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

Это косвенно относится в ревью, но очень полезно в будущей работе. Представьте, если вы будете читать полное описания коммитов, PR вместо «small fix», «chore: update» и т. д.

Заключение

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

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Code Review — это процесс проверки кода на ошибки, проблемы и стиль оформления

Дальше не читал...

Извини, ушел сразу в комменты.
Но по этому пункту:
Code review (и в том числе PR documentation) — в первую очередь это инструмент Knowledge sharing, который в современных системах привязывается по идентификатору к конкретному коду.

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

Knowledge sharing

Да, это часть PR, о котором я в статье говорил, но не думаю что это именно в первую очередь.
Важный Knowledge мы заносим в Confluence. А в PR, если разработчик что-то делает не так, то просто даем ссылку.

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

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

Советую пройтись по статье все таки 😉

На додачу до ваших рекомендацій, додам коментар про емоційну складову код-рев’ю.

Агресивний код-рев’ю

Як програмісти можуть проявляти агресію до колег?

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

Як розрізнити агресивні коментарі від резонних зауважень та цінних рекомендацій? Це видно по сукупності факторів — тон коментарів, чи є бажання розібратись, чи нав’язати свою думку. Агресивний тон відчувається відразу. Ось гарний матеріал, де описано як варто робити рев’ю коду.

Що робити у випадку, коли ви відчули на собі агресивне рев’ю? Перше — не переходити на агресію самому. Ввічливість перемагає будь-яку грубість, особливо якщо ввічливість підкріплена твердістю та силою)

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

В залежності від причини, ви зможете вибрати адекватну стратегію протидії. Для прикладу, залучити третю сторону, ввічливо розжувати своє рішення, проігнорувати чи відповісти мемом, тонко натякнувши, що ви добре розумієте, що приховує ваш колега за своїми «впевненими» та «мудрими» коментарями.

Агресивний код-рев’ю

Якщо я бачу, що воно може викликати таке враження — я пропоную 1-to-1 з скріншейром або патчем, який можна або зааплаїти, або ні.

ічливість перемагає будь-яку грубість, особливо якщо ввічливість підкріплена твердістю та силою

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

Відокрмелю СІ засоби. Наприклад лінтер налагоджений за code convention прибирає з рівняння необхідність підіймати питання

форматування

те ж саме й про тести/доки та умовний `Danger`

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

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

Старожилы помнят ещё времена, когда комменты писались прямо в код — чтобы когда делаешь ревью (а когда и не делаешь небо на землю не рухнет) — было понятно, что именно делает код, вернее, что планировалось, что он будет делать. У хорошего кода комменты могут до 2/3 его объёма доходить.

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

Бывало, что в PR, где нужен был аппрув от одной команды, вносились правки, которые растекались мелкими фиксами по проекту и в итоге codeowners bot подтянул 6 команд на ревью. И теперь иди расскажи им всем что это и для чего. Особенно когда команды в 8 часовых поясах =)

Опять же та же самая правка, без боли прошла бы ревью хоть 10 команд, если была бы отдельной таской (и PR)

Я бы таким не занимался, если на проекте 5 человек, которые все в одном офисе сидят.

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

Бывало, что в PR, где нужен был аппрув от одной команды, вносились правки, которые растекались мелкими фиксами по проекту и в итоге codeowners bot подтянул 6 команд на ревью. И теперь иди расскажи им всем что это и для чего. Особенно когда команды в 8 часовых поясах =)

Если брать решение по-классике:

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

А, если действительно брать «по-классике» (пусть это будет и рунет), то при каждом ПР стоит для начала его самому проревьювить. И задаться вопросом «А не мудак ли я?». И в случае, если «я — мудак», добавить объяснение почему. В реквест, в комменты, в доку со ссылкойи отдельным ревью. Ну или исправить

Старожилы помнят ещё времена, когда комменты писались прямо в код

это уже объявлено пороком

«Код должен быть самодокументируемым, а потому не нуждаться ни в каких коментах!»

У хорошего кода комменты могут до 2/3 его объёма доходить.

старожилов этих — на свалку истории!
они не умели писать самодокументируемый код, а потому вот так покрывали свое уродство и рукожопость такими объемными комментариями!

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

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

А ещё по делу откомменченный код можно отдать на написание тестов другому человеку.

это уже объявлено пороком

Но там есть лазейка в виде

documentation comments
и
autodoc
У хорошего кода комменты могут до 2/3 его объёма доходить.

Лол

Тем не менее, это так. Вера, что всё будет понятно из кода, когда он реально несёт на себе логическую нагрузку, а не 100500 обёрток — дичайший наивняк. Потому что это подразумевает, что код абсолютно правильный и написан без ошибок в этой самой логике. Да-да, конечно же покрытый на 100% тестами, притом покрыта именно логика, а не мусор, и конечно же тесты тоже вот прям понятны.

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

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

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

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

До сих пор пишу комменты/или тесты (с комментами откуда он такой, длины имени не хватит иногда) на спорные участки которые «так надо» сделать. Могу подтвердить, небо на землю не падает. Но тесты лучше себя рекомендуют в этом плане. Они по рукам бьют — и приходится читать что там вообще изначально оговаривалось.

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

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

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

лишний рефакторинг кода

Лишним он никогда не бывает. Бывает непонимание необходимости рефакторинга как со стороны менеджмента так и со стороны разработчиков.

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

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

Мне нравится эта цитата Джеза Хамбла из книги о Continuous Delivery:

if it hurts, do it more often, and bring the pain forward.

По топику. Думайте о каждом своем коммите как о вашей подписи на официальном документе: он идет либо в hall of glory либо в hall of blame. Минимизируйте антирекламу на свою персону для последующих разрабов, ведь с ними еще может быть прийдется работать. Never know...

Полностью с вами согласен! 👍
А «лишний рефакторинг» именно из-за непонимания его ценности в данную минуту.

Можно конечно и отдельными PR-ми

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

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

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

Проблема не в эстимейтах, а в том, что его удобнее делать, когда разбираешься в коде. А когда разбираешься? Когда надо что-то менять. Соответственно рефакторинг можно сделать тогда же. И вроде как правильно — отдельно рефакторинг, отдельно изменения, притом и протестить это всё тоже отдельно. Но тогда рефакторинг нужно выполнить СНАЧАЛА, перед тем как делать фичу — поди докажи менеджменту, что из фичи на неделю ты 5 дней делал рефакторинг и 2 часа фичу. Да тебе все мозги за*бут, что ж ты такой гад фичу не сделаешь — и вот этот вынос мозга во время рефакторинга чреват такими проблемами, что проще откатиться и НИЧЕГО не делать, ни таску, ни рефактор, иначе будет ещё хуже.

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

Разумеется, без рефактора фича не делается за 2 часа. И за неделю не делается. И за две. А если и делается, то порождает полную жопу. Хотя индус бы сделал за день — не ему ж потом разбираться с тем, что натворил.

По моему опыту — через год нормальной работы с рефакторингом код уменьшается в 2 раза. Ещё через год — ещё в 2 раза. Разумеется, за это время дописывается новый, проект обрастает свистелками и пукалками, но факт, что от прежнего кода мало что остаётся не только по мусору, но и по логике. Фичи могут пропадать даже из ТЗ, когда задаются вопросы «а зачем это» — и оказывается, что так было в проекте-предшественнике, что это старый алгоритм, который вообще запрещено применять.

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

Но тут прибежал эффективный вахтёр

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

И вроде как правильно — отдельно рефакторинг, отдельно изменения, притом и протестить это всё тоже отдельно.

Тут нет единого «правильно». Это как с командой решите. Чисто процессуальное. Регрессионные тесты должны всегда зелеными быть.

Но тогда рефакторинг нужно выполнить СНАЧАЛА, перед тем как делать фичу — поди докажи менеджменту, что из фичи на неделю ты 5 дней делал рефакторинг и 2 часа фичу

Лично я предпочитаю continuous refactoring. Всегда. Статью об этом писал: danylomeister.blog/...​1/continuous-refactoring

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

Кстати, есть конкретные парактики по разруливанию технического долга для больших кодовых баз: www.youtube.com/...​b_channel=GOTOConferences

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

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

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

И потом обижаются, что я называю это своими именами, когда они приходят свои половые письки на ДОУ нахваливать. Вместо того чтобы хотя бы одним глазком подсмотреть чужой опыт. И не в историях успеха (там 100% ложь), а в историях конфликтов и историях фейлов.

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

Предпочтение отдаю Continuous Delivery и частым коммитам по trunk base development модели.

1. Каждые 30-60 минут PR в основную ветку (максимально информативные коммиты, чем чаще тем лучше). Фича-брэнчи имеют максимальный срок жизни не более суток (extreme case)
2. Тесты! Перед пушем PR локально регрессии проверять и покрывать новый функционал
3. Настроить git pull на ребейз. Часто ребейзится с транка, подтягивать изменения других разрабов.
4. Прятать фичи под feature toggles. Branch by Abstraction ваш друг.
5. По максимуму используем линтеры и стат. анализ кода
6. Держать основную ветку всегда в боевой готовности и готовной к релизу.

Философия такая что deployability важней чем полная готовность фичи. Итеративность и мелкие шаги ключевое. Конфликтов по такой схеме минимум. Большинство проблем с длинными PR-ами отпадает само собой.

1. Каждые 30-60 минут PR в основную ветку (максимально информативные коммиты, чем чаще тем лучше). Фича-брэнчи имеют максимальный срок жизни не более суток (extreme case)

Сложно себе представить, что вы там такое разрабатываете. Я в лучшем случае не видел сроков меньше 2 часов. Типовой — 2-3 дня. Потому что реально думать надо.

В остальном в принципе согласен, но вот сроки реально удивляют...

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

Так что разряжаем обойму как можно чаще.

Тоже не делаем длинных веток на фичи, никакого GitFlow, но таких времён не было...
хотя если фронтэнд — да, может быть... всерьёз таким никогда не занимался.

У нас на фронте ± 100 разрабов. Примерно такой же флоу как вы описали, но только бранч под каждую таску. PR этой ветки идет либо в мастер, либо в отдельную ветку в зависимости от случая. Но чаще master, а breaking changes скрываем фича флагами.

Да, но не прям полностью. Бэк и клиент в отдельных репо.

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

Поднастроить среду под репорт «stale» PR до двух дней. Поднастроить тиммейтов (что сложнее до обновления их ветки до одного дня. В этом случае я за интерактивный rebase полиси, кстати)
могут делать вначале/вконце каждого «дня», как удобнее

Оставлю кросс-ссылку на похожую статью тут чуть раньше.

По сказанному:

> Один Pull Request должен содержать как можно меньше изменений кода и файлов.

Это ой не абсолют. Коммит должен быть аккуратен и решать более-менее одну задачу, но вот делить одну смысловую задачу на много коммитов и тем более PRов плохо. Например (утрирую для демонстрации) переименовывается функция и 500 мест её вызова. Делить порциями по 10 или даже по 100 мест — нет смысла. (Хотя если счёт идёт на тысячи, лучше таки поставить временный алиас и делать порциями в несколько сотен.)

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

А где-то наоборот, лучше, если правки не сильно сложны, сделать их сразу. Потому что иначе проблемный код будет мозолить глаза и делать нервы.
Например, я вот вижу код вида string getX() { return x_; }
По всем канонам должно быть (почти всегда; там — точно) const string& getX() const noexcept { return x_; }
Почему бы не поменять сразу? (выставить в отдельный коммит, лучше перед основным)

К советам я бы добавил следующее:

1. Более технические и автоматические изменения должны быть раньше в цепочке коммитов, а удаления (тут уже нестрого) раньше добавлений/правок.
При наличии 1) форматирования, 2) рефакторинга и 3) добавления функциональности, их лучше подавать именно в этом порядке.
Обоснование: при поиске по истории просмотр почти всегда идёт от более нового, и поэтому чем меньше крупных тяжело читаемых изменений приходится разгребать, тем лучше.

2. Автоматические правки надо отделять от ручных в отдельные коммиты. Для автоматических писать команды и параметры, которыми сделаны, в сообщении коммита.

3. Сообщение коммита — на нём не экономить! В общем случае, чем больше подробностей, тем лучше, но если основное вверху, расшифровка внизу. Среди программистов сильно больше ленивцев, чем графоманов, поэтому совет надёжен на 95% :)

Ну а ещё — люблю Gerrit, в нём можно сравнивать версии (патчсеты, в его терминах) одного и того же коммита в развитии. Со всякими github/bitbucket это сложно или неудобно.
Жаль, что его мало используют.

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

Это, если работают синьоры.

О каком пункте речь?

И лучше внедрить правило минимизации изменений.

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

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

или хотя бы тудушку в коде сделать, вольным стилем

эта мелочевка, а особенно такая что
вроде ок, но как-то попахивает что ли... или не попахивает...

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

или хотя бы тудушку в коде сделать, вольным стилем

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

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

Угу, встречалось раза три... потом вскрываем а там черти смолу гонят...

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

тут главное не столько место — а то что это должно быть «письменно» зафиксировано

хоть на бумажном стикере чиркани и поцепи себе на край монитора :)

а за лишний тикет бьют ногами, слышал и про такое

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

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

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

Так PR лучше один, конечно, но в разные коммиты.

Настройте линтер на код стандарт проекта. Уменьшит необходимость комментариев в стиле Use tabs instead of spaces
Поставьте на ПР-е quality gate на минимальное покрытие и максимальное дублирование. Это также уменьшит комментарии стиля Please add tests for this class.
Quality gate на статическом анализаторе — вообще лучший друг ревьюера, выставляешь максимальную сложность кода на 10 — и методы на миллион вложений просто не доходят до код ревью.
Используйте флаг Draft, в таком случае вы можете исправлять ошибки выявленные на предыдущих шагах не тратя время ревьюера. В то же время более сеньорные члены команды могут заметить, что вы идете куда-то не туда раньше и вы потеряете меньше времени.
Советы для ревьюера:
Убивайте неактуальные ПР-ы, не давайте накопиться слишком большому ревью-листу, не ставьте аппрув тому, чего вы не понимаете.

Не везде настолько развито, но согласен.
Единственное, что стат анализатор, как и линтер, должны поддерживать «исключения» — бывает такой код, который проще исключить, чем оптимизировать. Например когда n=10 и это простые операции.

или линтер для line_length — можно энфорсить ворнинг/эррор для кода, но для комментов имеет смысл оставить только ворнинг. Если нет внутренней полиси по настройкам редактора и переносу строк

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

тут идеально и про Draft — идеально

Підписатись на коментарі