Перегляд коду - остаточний посібник

Найкраще керівництво для побудови процесу перегляду коду вашої команди

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

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

Давайте швидко викладемо кілька простих причин, чому слід робити огляди коду:

  1. Може допомогти зменшити помилки в коді.
  2. Переконайтеся, що всі вимоги до кодування виконані.
  3. Ефективний спосіб вчитися у однолітків та знайомитися з базою коду.
  4. Допомагає підтримувати стиль коду у всій команді.
  5. Згуртованість команди - заохочуйте розробників говорити один з одним про найкращі практики та стандарти кодування.
  6. Покращує загальну якість коду завдяки тиску з боку однолітків.

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

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

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

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

Взагалі, вам потрібно мати чітко визначені вказівки як для рецензента, так і для рецензента, перед тим, як створювати запит на витяг і поки він переглядається. Більш конкретно:

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

Я виявив, що наступне значно зменшує тертя:

  1. Переконайтесь, що код успішно компілюється.
  2. Читайте і коментуйте свій код.
  3. Створюйте та запускайте тести, які перевіряють область дії вашого коду.
  4. Весь код в кодовій базі повинен бути протестований.
  5. Пов’яжіть відповідні квитки / предмети у вашому інструменті управління завданнями (наприклад, JIRA) із вашим запитом на витяг.
  6. Не призначайте рецензента, поки ви не завершите вищезазначене.

Визначте обов'язки рецензента

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

  1. Спілкуйтеся зі своїм рецензентом - повідомте рецензентам про своє завдання Оскільки більшість із нас автори запитів вже були рецензентами, просто поставтесь на місце рецензента і запитайте: "Як це може бути простішим для мене?"
  2. Робіть менші запити на витягування - Надсилання менших запитів на витяг - найкращий спосіб пришвидшити час перегляду. Зберігайте свої запити на витягування, щоб ви могли швидше та точніше повторювати запити. Загалом, менші зміни коду також легше перевірити та перевірити як стабільні. Коли запит на витягування невеликий, рецензентам легше зрозуміти контекст та причини з логікою.
  3. Уникайте змін під час перегляду коду - основні зміни в середині перегляду коду в основному скидають весь процес перевірки. Якщо вам потрібно внести серйозні зміни після подання рецензії, можливо, вам доведеться надіслати існуючий огляд та подальші дії з додатковими змінами. Якщо вам потрібно внести серйозні зміни після запуску процесу перегляду коду, обов’язково повідомте про це рецензента якомога раніше на початку процесу.
  4. Відповідайте на всі відгуки про перевірку коду - навіть якщо ви не реалізуєте їхні відгуки, дайте відповідь і поясніть свої аргументи. Якщо ви щось не розумієте, задайте питання всередині або поза переглядом коду.
  5. Огляди коду - це обговорення, а не диктування. Більшість відгуків про огляд коду можна сприймати як пропозицію, а не як замовлення. Добре не погодитися з відгуками рецензента, але вам потрібно пояснити, чому, і дати їм можливість відповісти.

Визначте обов'язки рецензента

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

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

Також уникайте багатьох коментарів і використовуйте замість цього огляд Github (див. Приклад нижче).

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

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

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

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

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