Перегляд коду робочого процесу, де автор запиту на виклик повинен злитися

Кілька команд моєї компанії практикують перегляд коду, який я ніколи не бачив. Я намагаюся зрозуміти мислення, яке стоїть за ним, з думкою, що є цінність у тому, щоб зробити цілу компанію послідовною. (Я беру участь у кількох базах кодів, і мене викликали відмінності в минулому.)

1. Автор коду подає запит на тягу
2. Рецензент вивчає код
3. • Якщо рецензент схвалить, вони залишають коментар у рядку "Виглядає добре, сміливо зливайтеся"
   • Якщо рецензент має занепокоєння, вони залишають коментар на кшталт "Виправте незначні проблеми X і Y, потім об'єднайте" (Для великих змін поверніться до кроку 2)
4. Автор коду вносить зміни, якщо це необхідно, а потім об'єднує власний запит на витяг

У мене є такі проблеми:

• У разі схвалення на етапі 3 цей робочий процес створює, здавалося б, непотрібний перекрут для автора запиту на тягнення. Рецензент, який уже розглядає код, може просто його негайно об'єднати.

• У разі змін, які вимагаються на кроці 3, агентство для об'єднання запиту на виклик тепер покладається виключно на автора PR. Ніхто, окрім автора, не буде дивитись на зміни перед об'єднанням.

Які ще є переваги чи недоліки цього робочого процесу? Чи поширений цей робочий процес для інших інженерних команд?

У першому випадку це зазвичай ввічливість. У більшості організацій злиття розпочинають серію автоматизованих тестів, з якими потрібно негайно вирішувати, якщо вони не спрацьовують. Особливо, якщо була значна затримка між подачею запиту на витяг та переглядом, він ввічливо дозволить об'єднати його за графіком автора, тому вони встигають вирішити будь-який несподіваний випадок. Найпростіший спосіб зробити це - дозволити їм самі це злити.

Крім того, інколи автору пізніше стає відомо про причини, що запит на витягнення ще не повинен бути об'єднаний. Можливо, інший PR-розробник має більш високий пріоритет і спричинить конфлікти. Можливо, вона подумала про незакритий випадок використання. Можливо, коментар з огляду викликав мозковий штурм, який потребує подальшого дослідження, перш ніж питання буде повністю задоволено. Автор знає найбільше про код, і є сенс дати йому чи їй останнє слово, коли він зливається.

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

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

Маючи переважний робочий процес у невеликих колективах, коли початковий автор об'єднує власний запит на витягування. Крім технічних переваг, про які вже говорилося (наприклад, у вирішенні конфліктів злиття, наприклад,), я думаю, що це додає цінності на культурному рівні: це формує почуття власності.

Я вказав початкового автора для (рідкісного) випадку, коли інший розробник додав би зобов’язання до відкритого запиту на витягнення (витягнення гілки функції незавершеного виробництва та повернення до неї). Це трапляється не часто, і це буде результатом особистої розмови або над Слак: ​​Ці додаткові зобов’язання (кимось іншим) не повинні приземлятися там зненацька! У цьому контексті під початковим автором я маю на увазі того, хто подав запит на тягу.

У моїй організації ми є абсолютно новими в запитах на виклики, і ваше запитання - це те, про що я думав сам.

Хочеться додати одне спостереження: У деяких інструментах (ми використовуємо TFS) може бути робочий елемент, пов’язаний із запитом на витяг.

Якщо це так, стає клопотом відслідковувати, коли рецензент здійснив злиття. У цьому випадку розробник повинен переглянути PR, відкрити запит про помилку або змінити і позначити його як "вирішено". Якщо ми позначимо це "вирішеним" занадто рано, тестери вважають, що виправлення вже є частиною поточної збірки.

TFS 2017 покращився при здійсненні запиту на витяг. Тепер розробник може подати запит на витягнення автоматично об'єднатись, якщо всі умови виконані (конфлікт злиття, схвалення рецензентів та відсутність зламаних збірок). YMMV.

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