Як заохотити молодших розробників брати участь у перегляді коду?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процес: хтось хоче здійснити свої зміни. Хтось призначений рецензентом і переглядає зміни. Потім переглянуті та виправлені зміни переходять до тестування.

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

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