Який найкращий спосіб переглянути код, перш ніж він буде вкладений у магістраль? (SVN)

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

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

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

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

Це багато в чому залежить від культури команди та досвіду. Чому ви довіряєте моделі, яка головна мета оглядів? Я особисто віддаю перевагу перегляду після здійснення, оскільки це дозволяє відстежувати зміни в результаті огляду. Зараз ми використовуємо Git та Gerrit, оскільки вони забезпечують гарний баланс між двома варіантами.

1. Перед виконанням запустіть 'svn diff', щоб створити файл виправлення.
2. Надішліть файл виправлення рецензенту, який застосує його до чистої копії багажника.
3. Рецензент переглядає зміни, використовуючи переглядач різниці на вибір.
4. Рецензент виконує побудову та запуск тестів.
5. Якщо все піде добре, повідомте розробнику, що він може перевірити їх зміни. Якщо
   є проблеми, розробник повертається до кроку 1.

Там ідеальний світ, і тоді є реальний світ.

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

У реальному світі все інакше. Бізнес хоче, щоби зміни змінилися заразі скаже вам із ідеально прямим обличчям, що так, ви отримаєте час очистити код і додати тестові справи пізніше. Ви, ймовірно, не встигнете переглянути все, і відсоток коду, який охоплюється тестами, постійно зменшується. Основна причина перегляду коду полягає в тому, щоб молодші розробники навчалися у старших розробників (коли на це є час), завдяки тому, що більш досвідчена людина перегляне зміни та запропонує "кращі способи ведення справ (TM)". У вас будуть старші розробники, які здійснюють непереглянений код. Розгалуження лише для огляду коду, а потім об'єднання - це велика витрата часу. Один із способів подолати цю проблему - оголосити чергову щотижневу 2-годинну (або близько того) зустріч команди, на якій ви виберете одну-дві останні зміни, над якими люди працювали в найкоротші терміни, і примусите їх авторів "представити" їх підхід, дивлячись на код разом на проекторі чи щось таке. Це може призвести до цікавих дискусій (як правило, зовсім поза темою), але в цілому покращує розуміння усіма, як це зробити правильно. Плюс тиск, можливо, представляти свій код, змушує деяких людей робити це краще ;-)

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

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

_{Зверніть увагу, тоді ми використовували огляди попередньої фіксації лише для критичних виправлень до коду кандидата на випуск, тому гілок не було багато (рутинні зміни передавались через огляди після завершення).}

Оскільки, здається, ви збираєтесь використовувати огляди попередньої фіксації для всіх змін, можливо, вам доведеться керувати великою кількістю гілок. Якщо ви розраховуєте, що розробник може в середньому внести одну «перевірну» зміну в тиждень, ви матимете близько 50 відділень щороку для кожного розробника в команді. Якщо ви використовуєте менші шматки роботи, як-от такі, що займають 1, 2, 3 ... дні - помножте 50 на 2, 3, 5 ... відповідно.

Нижче наведено кілька інших міркувань, які слід врахувати, якщо ви хочете найкращим чином .

1. Поводження з випадками, коли затримка огляду блокує код, необхідний для інших членів команди

Встановлення, моніторинг та вирішення конфліктів, пов’язаних із термінами перегляду коду. Згідно з моїм спогадом про попередні перегляди рутинних змін, про які я розглядався в одному з минулих проектів, розумний термін - це близько 3 днів, а час, щоб почати турбуватися, - це коли огляд не буде завершений через 1 день після подання.

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

2. злиття конфліктів при поданні переглянутого коду

Що робити, якщо фіксація переглянутого коду блокується конфліктними змінами, здійсненими кимось іншим, поки код чекав на перегляд?

Пара варіантів, які слід розглянути

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

_{Для порівняння, в оглядах після завершення комісій не було б подібних питань (оскільки це стосується коду, який вже об'єднаний за визначенням) - але оскільки ви орієнтуєтесь на огляди, що попередньо здійснюють комісію, це, мабуть, не цікаво.}

3. завантажте розробника, який чекає на перегляд

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

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

Будь-який твір, який потребує огляду, повинен бути в окремій галузі. Отже, філія повинна існувати до того, як настане час для перегляду. Тоді крок повинен бути:

1. Огляд
2. Переглянути (можливо)
3. повернутися до огляду (можливо)
4. Злиття в стовбур

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

Перехресне злиття - можливе рішення. Перш ніж об’єднатись у стовбур (крок 4, або навіть раніше, скажімо, перед кроком 3 чи кроком 1), об'єднайте стовбур у гілку. Розробник може це зробити і протестувати. Потім гілка наздоганяє стовбур і стає легше злити його в стовбур. Злиття в багажник найкраще робити ви, або той, хто відповідає за багажник.

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