Перегляд до чи після введення коду, що краще?

Традиційно ми проводили перевірку коду перед фіксацією, я сьогодні посперечався з колегою, який віддав перевагу перегляду коду після фіксації.

По-перше, ось дещо

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

Переваги перегляду коду перед фіксацією я дізнався:

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

Але я також мав деякі погані переживання:

1. Низька ефективність, деякі зміни можуть бути переглянуті протягом днів
2. Важко збалансувати швидкість та якість, особливо для новачків
3. Один член команди відчував недовіру

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

ОНОВЛЕННЯ:

1. Ми використовуємо Perforce для VCS
2. Ми кодуємо і робимо в одних і тих же гілках (гілки виправлення стовбура або помилки)
3. Для підвищення ефективності ми намагалися розділити код на невеликі зміни. Ми також спробували оглянути діалог у прямому ефірі, але не всі дотримувались цього правила. Це ще одна проблема.

Як згадує Саймон Уайтхед у своєму коментарі , це залежить від вашої стратегії розгалуження.

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

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

Є мантра, яку, схоже, ніхто ще не цитував: Перевірте рано і часто :

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

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

Моє правило - "заїзд рано та часто", але з застереженням, що у вас є доступ до приватних версій. Якщо реєстрація відразу помітна для інших користувачів, ви ризикуєте внести незрілі зміни та / або порушити збірку.

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

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

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

Є також заява Джеффа Етвуда: Не бійтеся ламати речі :

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

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

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

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

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

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

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

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

Також ви можете розглядати парне кодування (старші пари з молодшими) як інший спосіб надання вбудованого огляду коду. Розгляньте це як перевірку якості на конвеєрній лінії замість того, як автомобіль скотився.

Виконайте обидва:

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

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

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

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

Що стосується самої перевірки коду, я голосую за "під час" комісії.

Така система, як герріт або конюшина (я думаю), може змінити зміни, а потім запропонувати рецензенту скористатися цим контролем джерела (push in git), якщо це добре. Це найкраще в обох світі.

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

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

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

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

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

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

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

Попередній перегляд

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

Немає запущених комітетів під час огляду

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

Ревізії після огляду

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

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

Комітет після огляду

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

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

Згідно з цими напрямками, наявність хорошого процесу ІС та / або заїздів із закритим тиском зменшує потребу в оглядах перед вчиненням комісії (і, мабуть, після здійснення комісії для багатьох із них).

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

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

З них ми отримали наступні евристичні правила:

• Коли у вас є встановлений процес перегляду коду, не турбуйтеся про зміни, його, мабуть, не варто докладати зусиль
  • якщо у вас немає проблем із часом циклу => Перейти до повідомлення
  • Або пропущені проблеми занадто часто порушують ваших розробників => Переключитися на попередньо
• Якщо ви ще не робите відгуки
  • Використовуйте попереднє зобов’язання, якщо одна з цих переваг застосовується для вас
    • Попередній перегляд дозволяє стороннім особам без зобов'язань брати участь у проектах з відкритим кодом
    • Якщо на основі інструментів, попередній огляд виконує певну дисципліну з перегляду в командах, які в противному випадку мають слабке дотримання процесу
    • Попередній огляд легко утримує непереглянуті зміни від доставки, що є чітким для безперервного розгортання / дуже коротких циклів випуску
  • Використовуйте попереднє зобов’язання, якщо ваша команда чисельна, і ви можете жити з проблемами або обійти проблеми протягом циклу
  • В іншому випадку (наприклад, невелика, кваліфікована промислова команда) використовуйте пост-комікс
• Шукайте комбінації, які дають переваги обом світам (ми їх формально не вивчали)

Повний дослідний документ доступний тут: http://dx.doi.org/10.1145/2904354.2904362 або на моєму веб-сайті: http://tobias-baum.de

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

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

Інструмент на зразок Crucible згладить і автоматизує процес огляду. Ви можете вибрати один або кілька наборів змін, які потрібно включити до огляду. На тиглі він покаже, які файли торкалися у вибраних наборах змін, слідкуйте за тим, які файли кожен рецензент уже прочитав (показуючи% повного загального числа), а рецензенти дозволять легко робити коментарі.

http://www.atlassian.com/software/crucible/overview

Деякі інші переваги галузей користувача / функцій:

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

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

І те й інше. (Типу.)

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

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

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

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

100% парне програмування (незалежно від того, яким старшим ви вважаєте, що ви є) з безліччю невеликих комітетів та системою CI, яка базується на ВСІМ комісіях (з автоматизованим тестуванням, включаючи одиниці, інтеграцію та функціонал, де це можливо). Огляди після здійснення комісій для великих або ризикованих змін. Якщо у вас повинен бути якийсь огляд із закритим / попереднім перекладом, Герріт працює.

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

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

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

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

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

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

• Огляд через певний час після заїзду. Відгуки будуть витіснятись далі, коли настане скорочення строку. Код, який залежить від уже скоєного, але ще не переглянутого коду, буде скоєно. Відгуки будуть позначені проблемами, і проблеми будуть розміщені на відсталі, щоб виправити "пізніше". Гаразд, я збрехав: Це не просте рішення, це зовсім не рішення. Огляд в певний час після реєстрації працює, але менш простий, оскільки ви повинні вирішити, який саме вказаний час

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

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

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

ми фактично робимо гібрид на LedgerSMB. Комітети здійснюють зміни, які будуть переглянуті після. Некомітети подають зміни до комітетів, які повинні бути переглянуті раніше. Це, як правило, означає два рівні перегляду. Спочатку ви отримуєте наставника для огляду та наставника. Потім цей наставник отримує код вдруге переглянутого після того, як він або вона підписався на нього, і зворотній зв'язок поширюється. Нові довірені особи спочатку витрачають багато часу на перегляд інших людей.

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

Де чинити? Є філія, яку я створив, щоб виконати якусь роботу. Я беру на себе зобов’язання в цій галузі, коли мені це подобається. Це нікому не справа. Потім в якийсь момент ця галузь інтегрується в галузь розвитку. А десь посеред - огляд коду.

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

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

Залучення людей до автоматичних процесів просто марно.