Код огляди
Автор: Маттіас Карлссон
Ви повинні робити огляди коду. Чому? Тому що вони підвищують якість коду і зменшують частоту дефектів. Але не обов’язково з причин, які ви можете подумати.
Оскільки, можливо, вони мали поганий досвід з оглядами, багато програмістів схильні відхиляти огляди коду. Я бачив організації, які вимагають, щоб весь код пройшов офіційний огляд перед тим, як перейти на виробництво. Часто цей огляд робить архітектор або керівник проекту, практику, яку можна описати як архітектор, який переглядає все. Це написано в посібнику з процесу розробки програмного забезпечення, тому програмісти повинні цього дотримуватися. Деякі організації можуть потребувати такої жорсткості та формальних процесів, а багато - ні. У більшості організацій такий підхід не є продуктивним. Обшукуваний може відчувати, що над ними пробує суд з достроково звільнення. Рецензентам потрібен як час, щоб прочитати код, так і час, щоб бути в курсі всіх деталей системи. Рецензенти можуть швидко стати вузькими місцями в цьому процесі, і процес швидко вироджується.
Замість того, щоб просто виправляти помилки в коді, метою оглядів коду має бути обмін знаннями та встановлення загальних правил кодування. Надання спільного коду іншим розробникам дає змогу колективно володіти кодом. Не обмежуйте їх потік, нехай будь-який член команди переглядає код разом з рештою команди. Замість того, щоб шукати помилки, вам слід переглянути код, намагаючись його вивчити та зрозуміти.
Будьте обережні під час перегляду коду. Переконайтесь, що ваші коментарі носять конструктивний, а не їдкий характер. Представляйте різні ролі на дошці огляду, уникаючи того, щоб старші в команді впливали на огляди коду. Приклади ролей можуть включати деяких рецензентів, орієнтованих на документацію, інших на винятки та третю сторону, яка шукає функціональність. Цей підхід допомагає розподілити тягар відгуків серед членів команди.
Переглядайте код регулярно, один день на тиждень. Проведіть пару годин на дошці огляду. Обертайте щотижневі реєстрації за простим круговим шаблоном. Не забувайте також змінювати ролі між членами команди на кожній оглядовій зустрічі. Залучайте початківців до огляду коду. Вони можуть бути недосвідченими, але їхні останні знання в коледжі можуть дати інший погляд. Він залучає експертів за їхній досвід та знання; вони ідентифікують код, схильний до помилок, швидше та з більшою точністю. Перевірка коду буде проходити легше, якщо команда має правила кодування, які перевіряються інструментами. Таким чином, формат коду ніколи не обговорюватиметься під час зустрічі з перегляду коду.
Зробити огляди коду веселими - це, мабуть, найважливіший фактор успіху. Відгуки стосуються людей, яких перевіряють. Якщо оглядова зустріч болюча або нудна, мотивувати когось буде важче. Зробіть це неформальним переглядом коду, основною метою якого є обмін знаннями між членами команди. Залиште примхливі коментарі і принесіть замість них обід з торта або коричневої сумки.
Переклад: Еспартако Пальма
Компіляція Еспартако Пальма (@esparta).
З гордістю розміщений на github