Хто повинен робити огляди коду?

12

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

Однак з існуючою системою є дві проблеми:

Архітектор стає вузьким місцем
Розробники не беруть на себе відповідальність за якість коду та архітектуру (що призводить до всіляких проблем).

Як ми можемо вирішити ці проблеми? Чи слід змінити, хто перевіряє код?

code-reviews

— Євген
джерело

1

Можливий дублікат: Чи повинні ваші найкращі програмісти перевіряти код усіх інших у контролі джерела?

— гнат

1

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

— Барт ван Інген Шенау

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

— AakashM

15

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

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

— jmoreno
джерело

2

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

— JensG

@JensG: але це не аналог, який проводить огляд у ситуації з ОП.

— jmoreno

3

Тому я зробив це сміливо.

— JensG

8

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

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

— Альфредо Касадо
джерело

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

— JensG

3

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

Мої переважні [*] процедури перегляду:

Групування змін за вимогою / випуском.
Запросіть на розгляд всіх розробників, архітектора програмного забезпечення та автора вимоги / проблеми. (Вони не всі зобов'язані робити огляд.)
Розглянемо огляд, завершений, коли:
- Два розробники переглянули.
- Усі коментарі відповідають. (Можливо, завдяки архітектору програмного забезпечення приймати рішення.)
- Пройшов один робочий день без подальшого обговорення (або всі запрошені сторони переглянули).

Тому моя коротка відповідь на ваше запитання: Розробники повинні змінити відгуки.

[*] На жаль, не завжди так працюють проекти, в яких я беру участь.

— Яків Спарр Андерсен
джерело

тепер завжди, чи не завжди?

— Мартійн

Як ви вже здогадалися: "не завжди". Дякуємо, що помітили його. Я виправив відповідь.

— Якоб Спарр Андерсен

3

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

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

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

— Роб
джерело

2

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

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

— Міхай
джерело