Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

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

2 <h3>Советы для автора</h3>

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

4 Конечно, гораздо проще добавить кучу несвязанной работы в один-единственный пул-реквест, и все же постарайтесь этого не делать.

5 Пользуйтесь<a>ярлыками</a>.Неважно, что именно вы используете - префиксы перед темой сообщения или встроенное тегирование - главное, щедро этим пользуйтесь! Такие пометки нужны, чтобы сообщить о статусе работы, объеме ревью или указать, к какому<a>этапу</a>относится пул-реквест.

6 Обеспечьте ясный контекст.В<a>описании проекта</a>укажите, над какой проблемой вы поработали и какое решение предложили. Тогда и код-ревью проще делать, и других будет легче ввести в курс дела.

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

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

9 Полезное код-ревью - это доброжелательное код-ревью. С этими словами перейдем к советам для ревьюеров.

10 <h3>Советы для ревьюера</h3>

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

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

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

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

15 <h3>Советы для команды</h3>

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

17 Сделайте код-ревью доступным. Обеспечьте новичков своевременным код-ревью. Я видел команды, которые добиваются этого через установление конкретных сроков, некоторые даже прописывают их в<a>SLA</a>(соглашение об уровне сервиса).

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

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

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

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

22 Обеспечьте стабильную сборку. Проверьте, все ли работает, если запустить проект локально. Я не знаю, что вы предпочитаете - pre-commit, статический анализ кода или тесты - но знаю, что вам просто необходимо обеспечить стабильную сборку<a>в одно касание</a>.

23 К черту совершенство. Помните, что важнее всего для разработчика - это не совершенство, а здоровая кодовая база, понятная всей (всей!) команде. Поэтому не стоит расстраиваться, когда с новичками возникают трудности; вместо этого сфокусируйтесь на общем росте и развитии, которое обеспечивает практика код-ревью.

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

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

26 <ul><li>Ясные взаимные ожидания - это основа плодотворного сотрудничества.</li>

27 <li>Новички могут стать основными контрибьюторами вашего проекта.</li>

28 <li>У код-ревью есть бонусы - это отлов багов и цельный код.</li>

29 </ul><h3>И наконец...</h3>

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

31 Это перевод статьи Дага Аркури (Doug Arcuri). Оригинальная статья:<a>Be a Rock Star at Pull Requests. Tips for a successful collaborative code review</a>.

32 Я сохранила все ссылки Аркури из оригинальной статьи. Ссылки по github milestones и SLA - от меня.

33 Любая критика перевода - велкам!