Як зробити кращі огляди коду, коли запити на тягнення великі?

Відмова від відповідальності: Є кілька подібних питань, але я не знайшов жодного, який би торкався конкретно проблем, з якими ви стикаєтесь під час перегляду великого запиту на витяг.

Проблема

Я думаю, що мої огляди коду можна було б зробити краще. Я особливо говорю про огляди великого коду з багатьма змінами в 20+ файлах.

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

У мене виникають проблеми після продуманого процесу автора коду. Досить важко, коли зміни численні і поширюються на кілька файлів. Я намагаюся зосередитись на групах файлів, пов’язаних із певним змін. Потім перегляньте групи по черзі. На жаль, інструмент, який я використовую (Atlassian Bitbucket), не дуже корисний. Щоразу, коли я відвідую файл, він позначається як проглядається, хоча він часто виявляється не пов’язаним із розглянутою в даний час частиною змін. Не кажучи вже про те, що деякі файли слід відвідувати кілька разів, а їх зміни переглядаються по черзі. Також повернення до відповідних файлів, коли ви йдете по поганому шляху, непросте.

Можливі рішення, і чому вони не працюють для мене

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

Звичайно, створення менших запитів на притягнення здається корисним засобом, але воно є тим, що воно є, іноді ви отримуєте великий запит на витяг, і його потрібно переглянути.

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

Використання кращого інструменту може бути корисним, але я не знайшов його.

Запитання

• У вас є подібні проблеми з відгуками про ваш код? Як ви стикаєтеся з ними?
• Можливо, у вас є кращі інструменти?

У нас виникли ці проблеми, і поставлене нижче запитання добре працює для нас:

Чи робить PR одна річ, яку можна об'єднати і яку можна незалежно перевірити?

Ми намагаємось розбити піар одноосібно (СР). Після початкового відштовхування люди з подивом виявили, що навіть щось маленьке, хоч сингл може бути великим.

ЕР дозволяє дуже легко переглянути, а також поширює знання про очікувану реалізацію.

Це також дозволяє наростити рефактори, оскільки додається більше, а час виконання PR різко скорочується!

Я б запропонував розірвати їх за SR, якщо можливо, і побачити, чи працює він для вас. Знадобиться певна практика, щоб зробити це саме так.

Іноді не вдається уникнути великих запитів на тягнення - але ти можеш визначити, хто несе відповідальність.

Я трактую запити на тягнення як переконливі аргументи. Автор намагається переконати мене, що код повинен виглядати і працювати таким чином.

Як і будь-який аргумент, він повинен мати єдине чітке уявлення. Це або:

• рефактор,
• оптимізація,
• або новий функціонал.

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

Ще будуть великі запити на виклик, але з чітким аргументом набагато простіше зрозуміти, що не підходить.

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

Не переглядайте повний запит на витяг, але кожне виконання. Ви все одно отримаєте краще розуміння запиту на витяг, зробивши це таким чином.¹

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

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

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

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

"Часто" нечітко, але якщо ви виявите, що витрачаєте занадто багато часу на перегляд коду, який не знайшов шлях до остаточного перегляду запиту на виклик, ви можете скористатися двома методами:

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

• Погляньте на бік останньої версії файлу (хоча у багатьох випадках для великих комісій (1) файли можуть бути кардинально різними і (2) файли можуть бути перейменовані або великі блоки коду можуть перенести в інше місце, що ускладнює пошук відповідного файлу).

• Або попросіть членів комітету скріпати коміти, коли це має сенс, або встановіть специфічні конвенції про повідомлення про фіксацію, коли одна фіксація скасовує частину іншої, і робіть ваш огляд, беручи до уваги кілька наступних комітетів.

^{¹ Наприклад, уявіть, що ви переглядаєте файл, у якому перейменована певна змінна. Що це вам каже? Як слід переглянути цю зміну? Якщо ви переглядали цю команду, виконуючи команду "комміт", то ви побачили, що одна фіксація перейменовувала ту саму змінну у двадцять файлів, а коментар вказує на те, що ім'я було змінено з метою використання належного терміна бізнесу. Ця зміна має ідеальний сенс і її можна переглянути.}

Ознайомтеся з тим, чого ви намагаєтеся досягти, переглянувши запити на тягнення та перевірте, чи є альтернатива.

Наприклад, ви можете захотіти

• Забезпечити дотримання стандартів
• Перевірте правильність функціональності
• Переконайтеся, що код розуміє більше ніж одна людина
• Тренують юніорів

тощо.

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

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

Якщо мені потрібно розібратися в коді, можливо, виконати парне програмування на великих функціях і обмежити перегляд коду до перевірки стандартів.

Вам не потрібно перевіряти всі речі на кожному піар, доки у вас шаруватий підхід до забезпечення якості