Як поступово вводити огляди коду?


26

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

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

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


Я недостатньо наголосив на питанні, але "поступово" тут був ключовим елементом. Я не думаю, що перегляд 100% змін взагалі неможливий. Але якщо переглядати лише частину, як вибирати її? Просто виберіть "улюблені зміни"? Щось випадкове? Вибір свинцю? Відповіді тут чудові, але насправді не потрапили в «поступову» частину моєї думки.
Філіп

Відповіді:


16

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

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

Це важка робота.


38

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

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


10
"Гей, я не задоволений цією конструкцією, чи можу я отримати другий набір очних яблук?" Це чудовий перший крок. ++
RubberDuck

4

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

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

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

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


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

4

Чи є хороший спосіб представити відгуки?

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

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

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

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

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

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

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

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

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

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

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


-2

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

Цей підхід працює, але він не ідеальний.

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


3
Сидіти всі години годинами, щоб переглянути весь код, сформований під час ітерації після її закінчення (і законно занадто пізно) звучить як прекрасний спосіб змусити всіх ненавидіти ідею Code Reviews.
RubberDuck

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

моя команда із 7 додає / видаляє / модифікує кілька тисяч рядків коду за ~ 3 десятки, що виконуються кожні два тижні. Якість огляд реципієнтом займає близько 15-60 хв. Середній PR - 3-4 коміти. Так, так. Якби ми зробили це все відразу як команда, це займе 8 годин X 7 devs замість 8 годин, що поширюються по команді. Я обурююся вашою інсинуацією, що ми робимо щось не так. Ми ходимо продавати кілька разів на тиждень . Чи ти?
RubberDuck

Ми робимо один раз кожну ітерацію
Пелікан з низьким польотом
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.