Чи необхідні огляди коду? Хіба ми вже не переглядаємо код одночасно з розробкою? Якщо я вже використовую рефакторинг як звичайну практику, який сенс перевіряти код ще раз?
Є багато питань, які можуть виникнути у команди розробників, посилаючись на огляди коду. Але ще гірше за запитання викликають занепокоєння чи сумніви ("якщо мій код перевіряється, моя робота буде зіпсована!"). Перш за все, ми почнемо з визначення того, що таке перегляд коду (Перегляд коду).
Визначення перегляду коду
Почнемо зі сценарію, в якому ми працюємо в гнучкій основі, і в різних варіантах виберемо Scrum. Мета цього допису не полягає в тому, щоб заглибитися у роботу цих методологій. Хоча можливо, що в майбутньому я буду говорити про них більше, Інтернет наповнений інформацією про них; Я спеціально рекомендую блог Хав'єра Гарзаса.
Необхідно встановити початкові рамки, щоб визначити спосіб, яким ми підходимо до розробки нашого програмного забезпечення. У Scrum "одиниця розробки" - це історія користувача, а одиниця часу - спринт.
Давайте уявимо тоді, що команда з 4 розробників повинна розділити розробку декількох історій користувачів протягом спринту. Уявімо, що одному розробнику (назвемо його Луїс) призначена історія користувача X (наприклад, “Створити рівень збереження даних”).
Перегляд коду - це процес, за допомогою якого решта команди разом переглядає реалізацію Луїса для цієї історії користувача, пропонуючи ідеї щодо того, як її покращити, можливо, переформатувати, виявити можливі помилки, помилки архітектури, відсутність охоплення тестом для певних випадків та безліч інших речей, які можуть виникнути.
Небажання ...
Будьмо прямими: у нашій професії багато «складних» профілів. Не вдаючись у надто подробиці, певні розробники не відкриті для критики, а тим більше для модифікації коду, який вони заповнили і, теоретично, працює. Якщо хтось із читачів належить до цієї групи, я поставив би їм такі запитання:
- Чи легко зрозуміти ваш код комусь, крім вас?
- Чи зможете ви самі зрозуміти цей код через пару років?
- Чи врахували Ви ВСІ фактори, які впливають або можуть вплинути на систему при розробці вашого коду?
- Якщо ви виявили кричущу помилку в чужому коді, чи не вважаєте ви своїм професіоналом відповідальність за її виправлення? У цьому випадку, чи не краще виявити такі помилки якомога швидше?
Колективність коду. Код не мій
Дійсно, коли ми працюємо над бізнес-проектом, ми розробляємо програмний код, який і надалі розроблятиметься, вдосконалюватиметься та підтримуватиметься доброю кількістю розробників. Я думаю, що в такій галузі немає сенсу говорити про особисте володіння кодом, а навпаки.
Колективне володіння кодом спонукає спритну команду взяти на себе відповідальність за роботу абсолютно всієї поставленої системи. Не вказувати пальцем на винних, коли щось не працює, або припускати, що "мене там не було" або "мене там не було". Я б сказав, що щось подібне очевидно ... але це зовсім не так.
Досвід навчив мене, що огляд коду є найефективнішим способом досягнення цього ідеалу.
Процес
Процес перевірки коду починається, коли розробник збирається завантажити або вже завантажив у центральне сховище (ми припускаємо, що ми використовуємо Git або подібний інструмент контролю версій) всі зміни, пов'язані з реалізацією історії призначених користувач.
Решта команди (у нашому прикладі інші три розробники) або понад 50%, що залишилися принаймні (у прикладі - мінімум 2), переглянуть усі зміни коду, які будуть додані до системи, і за допомогою коментарів У доброзичливому та неформальному середовищі вони передаватимуть свої сумніви щодо певних рішень, пропозицій щодо вдосконалення та, звичайно, "великі пальці" щодо ідей, які можуть бути блискучими чи особливо успішними. Ці коментарі повинні бути зосереджені на висвітленні кількох питань, які я порушував у цій публікації, і переваги є кілька і очевидні:
- Відкрийте інструменти, API, способи вирішення проблеми…, якої ми не знали
- Отримати глобальні знання про систему (не тільки про ті частини, які я розробляю)
- Доведіть зовнішні точки зору та підніміть питання, які, можливо, були пропущені провідним розробником
- Поліпшення якості та читабельності. Іноді робота фрагмента коду, який може бути дуже очевидним для його творця, не такий очевидний для інших
- Досягнення довгоочікуваної "спільноти кодів"
Звичайно, не всі коментарі від решти команди можуть бути точними, і це залежить від них Вся команда досягти консенсусу щодо дій, які слід вжити після завершення розгляду. Загалом, зміни завжди застосовуватимуться. У моїй теперішній компанії ми вважаємо само собою зрозумілим, що після “Перегляду коду” завжди буде завдання “Зміни після перегляду коду”, і ми завжди додаємо оцінку цих завдань до загальної історії користувачів. Насправді ми ніколи не закриваємо (зроблено) історія користувача, поки вона не пройшла перевірку коду.
Его слід залишити на стоянці при перегляді коду. Ми не беремо участь у конкурсі на пошук найяскравішого програміста, ми просто хочемо, щоб наш продукт був найвищої якості.
Результат
Мені дуже подобається ця формула (я виявив її у відео Атласіана, яке я не зміг знайти знову):
- G: рівень індивідуальної вини помилки, виявленої у виробництві
- R: кількість людей, які переглянули відповідний код
Тому ми випливаємо з того, що якщо код не переглядається будь-ким, лише одна людина буде нести відповідальність за збій у виробництві. Тоді як якщо вся команда переглядає код, вину розподіляють по всій команді. Хіба ми не досягли того, чого шукали "колективні властивості кодексу"?
Інструменти
Перегляд коду можна зробити, зібравши команду в кімнаті, або скориставшись інструментом, створеним для цієї мети. На ринку є декілька, як з відкритим кодом, так і комерційні, для проведення перевірок кодексу. У цьому посиланні перелічено декілька з них. Я особисто працював з Crucible від Atlassian, який чудово інтегрується з рештою набору Atlassian (JIRA для управління завданнями, Stash як сховище коду Git тощо), і дозволяє розпочинати розмови з рядка коду, блоку, додати загальні коментарі тощо:
Мій особистий досвід
Я наважусь сказати, що я набагато кращий професіонал, оскільки я є частиною команди, яка постійно використовує огляди коду. Не тільки для всього, що вивчається, коли ваш код випробовується, або коли вам доводиться переглядати код інших, змушуючи розвивати критичний та аналітичний дух, який ми б не використовували так чітко в інших обставинах.
Можна сказати ще один „незручний” фактор, і це те, що, заздалегідь знаючи, що ваш код буде переглянуто, ми програмуємо краще:). Деякі пороки або набуті практики, про які ми точно знаємо, не є правильними, але яких трохи ліниво уникати, безумовно, загнані в кут, коли у нас на огляді коду.
Висновки
Буквально вчора я закінчив проект, над яким працював 11 місяців (фактично сьогодні розпочинаю відпустку:)), провівши за цей час 75 оглядів коду. Я думаю, що це на сьогоднішній день найвища якість продукції, яку я поставив на сьогоднішній день, і я б повністю підпалив його за це. Я впевнений, що решта розробників проекту думають точно так само, як і я. Без “Перегляду коду” ми ніколи не досягли б таких високих стандартів, навіть віддалено.
Спробуйте огляди коду, ви більше ніколи не повернетесь.