Думки про pull request assignee
Уважно обирай авдиторію
В кінці запису про створення pull request’у, я мимохіть згадав assignee
Додай в assignee зацікавлених колег (будь то окремі люди або цілі команди)
Нібито це настільки легко та настільки малозначно…
Серія записів про code review:
Англійською: On Code Reviews
You are Reviewer Zero
Нульовим ревʼювером є сам автор pull request’у. Звичайно, ніхто не заважає забити і переключитися на іншу задачу після того, як передав естафету колегам, але перегляд знайомого коду в новому середовищі (UI code review вместо UI code editor’а) або через деякий час (коли усі «очевидності» забулися) допоможе самостійно помітити помилку або який-небудь дивний момент
Я иногда делаю ещё так - после публикации своего PR я сам же ему делаю Review (в Github можно прокомментировать свой PR, но без Approve). Это позволяет добавить комментарии/контекст конкретно к тому коду, которого это касается
— гарний коментар до попереднього запису
Особливо зручно це робити у чорновому pull request’і, який нібито вже створено та має перевірки на CI, але ще не повідомив про своє існування code owner’ам
Кому дивиться
У невеликих проєктах з щільною командою, питання «кому кинути на ревʼю» вирішується сам собою — ти або кидаєш усім (тому що вас небагато), або ти знаєш відповідальну за ту чи іншу частину коду і кидаєш їй
В більш… динамічних проєктах та командах, через розміри та поганий звʼязок, ситуація може бути складнішою. Найчастіше, це вирішено згадкою у code owner’ах або цілих команд, або «володарів думки» (тімліди/техліди/сініори/тощо). Обидва шляхи створюють свої проблеми
Команди у code owner’ах
Команда у ревʼюверах створює ризик того, що кожен учасник команди вважатиме що перегляд твого pull request’у — чуже завдання. Наявність «чергових»/«oncall» в команді не рятує — якщо pull request було створено у вечір пʼятниці, коли я був черговим, то у понеділок я думатиму «тепер це проблема сьогоднішньої чергової Олени» і забити. Олена, в свою чергу, також може справедливо забити — pull request же пʼятничний, а в пʼятницю чергувала не вона
Плюс, новачки в команді можуть соромитися коментувати — раптом щось не помітять або поставлять «дурне» питання. А якщо в ревʼюверах уся команда, то можна причаїтися і перечекати
Команда в assignee може мати і протилежний ефект, коли усі-усі-усі поспішають зробити коментар, не вдаючись у подробиці1. В теорії, автор pull request’у може вкласти час та зусилля на відповідь усім "роззявакам", але це складно, виснажує, і може потребувати виправдань начальству, якщо воно вважає що «твоя задача — вирішувати проблеми з кодом, а не вчити джунів в інших командах»
Володарі думки у code owner’ах
Наявність когось, через кого будуть проходити усі pull request’и, звичайно, має свої плюси, наприклад, більш консистентний стиль і вища шанс помітити конфлікт з неявним припущенням в проєкті
Але безглуздо очікувати (або вимагати), що одна людина буде уважно пропускати через себе увесь контекст з тією ж швидкістю, з якою решта команди пише код. У трикутнику «багато/швидко/уважно» обрати усі три неможна. Навіть два не завжди вдається…
Я не знаю, як однозначно вирішити обидві проблеми. Але впевнений, що:
- на кожен окремий pull request краще призначати не усю команду, а окремих людей, навіть якщо єдиний їх внесок буде «перепризначити більш відповідній людині»
- дуже важливо уникати створення людини-bottleneck’а, яка недовго протримається під тиском начальства та колег
- дивитись pull request’и мають не лише ліди/сініори, але і джуни. Інакше без джунівського «що тут відбувається?» усе відлетить у стратосферу на абстракціях, а спростити код у момент code review набагато простіше, ніж після нього
Після цієї примітки, тепер точно можна говорити про процес з точки зору ревʼюверів