В ІТ-індустрії, де технології розвиваються із шаленою швидкістю, якість програмного забезпечення стає не просто важливою, але й часто вирішальною для успіху ІТ-проєкту. Однією із практик, що допомагає забезпечити високий рівень якості коду, є code review.
Рев’ю допомагає не тільки виявити та виправити помилки чи баги на ранніх стадіях. Це — ціла культура якості, де кожен рядок коду перевіряється, аналізується та вдосконалюється, щоб досягти оптимального рішення, скорочення часу та витрат на виправлення помилок у майбутньому.
Також рев’ю коду сприяє обміну знаннями та досвідом між членами ІТ-команди, побудові позитивної атмосфери, зростанню професіоналізму та підтримці високих стандартів кодування.
У цій статті розглядаємо, що таке та навіщо потрібен CR, як підготуватися та як виконувати код-рев’ю, ділимося кращими практиками огляду коду. Оскільки одна й та сама людина може одночасно виступати і як автор коду, і як ревʼюєр, стаття буде корисна з обох боків.
Що таке code review
Для кожної фічі, кожної частини ПЗ розробники пишуть окремий код. Щоб переконатися, що робота виконана правильно, програмісти перевіряють якість коду одне одного під час code review.
У цьому процесі беруть участь автор коду та рев’юер. Автор готує код (фрагмент коду) для перевірки, а рев’юер надає фідбек за результатами огляду коду.
Навіщо потрібен code review
1. Для перевірки відповідності коду стандартам кодування
Якби кожен програміст писав свою частину коду у власному стилі, працювати над таким проєктом було б складно. Колегам довелось би витрачати час, щоб прочитати та зрозуміти код.
Коли ж усі дотримуються встановленого в ІТ-компанії стандарту, вони набагато швидше можуть розібратися у чужому коді. Працювати з таким кодом легко та зручно.
2. Для навчання та обміну досвідом
Жодні курси чи туторіали не порівняються із унікальним бекграундом кожного ІТ-спеціаліста. Коли на ваш код дивиться людина з іншим досвідом, в іншій сфері, на інших проєктах, вона може внести свіжі ідеї та рішення. Навіть якщо це буде щось тривіальне на зразок «101 спосіб відцентрувати div».
Також обмін досвідом допомагає бути на одній хвилі з членами ІТ-команди. Коли ви знаєте код колег, ви легко зможете перейти в ту ж зону роботи, якщо буде така потреба.
3. Для покращення якості коду
Задача рев’юера — перевірити код на відповідність стандартам, корисність, читабельність, консистентність, наявність помилок, багів на ранніх стадіях розробки, а також порадити, що та як можна покращити.
Основні етапи code review
У найпростішому вигляді код-рев’ю виглядає так:
- автор написав свою частину коду,
- передав на перевірку (Pull Request або Merge Request),
- отримав фідбек,
- вніс правки,
- отримав підтвердження змін,
- відправив на подальше тестування.
Робота рев’юера складається із таких етапів:
1. Підготовка
Підготуватися до проведення код-рев’ю — це не тільки взяти зручне крісло і чашку кави (хоча це теж важливо). Підготовка передбачає ознайомлення із вимогами, цілями проєкту та специфікаціями, розуміння контексту задачі, яку вирішує код.
2. Загальний огляд коду
Швидкий перегляд коду, мета якого — отримати загальне уявлення про його логіку та архітектуру.
3. Детальний аналіз
Тут рев’юер відтворює для себе послідовність і логіку дій розробника. Він вже звертає увагу на конкретику: назва змінних та класів, дотримання принципів чистого коду (SOLID, DRY, KISS), кодстайлу розробника загалом, оптимальності рішень, правильності використання бібліотек та фреймворків, потенційних помилок, вразливостей, проблем із продуктивністю та місць, які можуть стати причиною багів у майбутньому.
4. Підготовка коментарів
Рев’ювери записують свої коментарі та зауваження щодо якісних аспектів коду.
5. Обговорення фідбеку
Мета рев’ювера на цьому етапі — уточнити незрозумілі, спірні моменти, прийти до спільного знаменника та, зрештою, допомогти колезі покращити код.
6. Виправлення помилок та оптимізація коду
На основі отриманих зауважень автор коду вносить необхідні зміни. Цей етап може включати як просте виправлення помилок, так і рефакторинг коду.
7. Затвердження змін
Після того, як зміни внесені, рев’ювери знову переглядають код, щоб переконатися, що всі зауваження враховані або пояснені, і що код тепер відповідає вимогам якості.
Якщо ні, процедура може повторюватись декілька разів, доки рев’юер остаточно не заапрувить написаний код. Після цього процес code review офіційно завершений. Далі код поєднують із основним кодом проєкту і переводять завдання на QA.
Як підготувати код до ревʼю
Завдання автора коду під час проведення код-рев’ю не зводиться суто до написання коду. Підготуйтеся до CR так, щоб він був максимально корисним і для вас, і для колеги, що оглядає код.
1. Проведіть авторське code review
Ви як автор маєте самі собі стати ревʼюером, перш ніж передавати код далі. Будьте прискіпливими, не давайте собі поблажок та абстрагуйтеся від того, що цей код написали ви самі.
Оглядайте свій код так, як це зробив би ревʼюєр. Зверніть увагу на читабельність: чистий код полегшує його підтримку на вашому боці та на боці замовника.
2. Опціонально — проведіть демо
Якщо працюєте з якоюсь новою технологією, в якій інші розробники ще не розібралися, або це дуже важлива фіча, добре було б провести CR демо, що допоможе колегам краще розуміти ваш код.
3. Мінімізуйте витрати часу рев’юера
В описі Pull Request намагайтеся максимально включити відповіді на всі можливі питання: бізнес-логіка коду, його завдання, на що він впливає, які проблеми розв’язує тощо. Також можна додати коментарі, що пояснюють певне рішення.
4. Проведіть тестування коду на staging
Помилка навіть в один знак може зламати всю верстку, і навіть досвідчений рев’юер може не помітити її з одного рядка в CSS.
5. За можливості спрощуйте та автоматизуйте все
Ви не тільки підвищите якість своєї роботи, але й полегшите перевірку коду колегою, заощадивши його час на рутину. Адже автоматизація допомагає більше сконцентруватися на оцінці відповідності коду бізнес-вимогам, ніж суто перегляді коду.
Наприклад, при підготовці до code review використовуйте CircleCi, щоб перевірити, чи відповідає код стандартам, чи проходять тести успішно, чи білдиться код тощо.
6. Зменшуйте пул реквести
На перевірку великих завдань може піти багато часу. Бажаний розмір для огляду коду — не більше 500 рядків. Навіть 300 рядків бізнес-коду перевірити якісно, без відволікання доволі складно.
На початку мозок буде намагатися вчитуватися, але згодом буде все складніше аналізувати великий масив інформації, і вже припускатися помилок може рев’юєр.
7. Подавайте на рев’ю коду тільки те, що прописане у task
Не плутайте колегу. Надавайте для огляду лише те, що прописано в тасці, адже на ревʼю все має бути пов’язане. Тож якщо ви раптом побачили баг, який не стосується вашого коду, зробіть для нього окремий таск та пускайте його на окремий code review.
Основні правила перевірки коду
Перевірка коду — це не змагання двох розробників, а можливість для росту як автора, так і того, хто проводить ревʼю.
Дотримуйтесь таких принципів та кращих практик:
1. Тримайте у голові завдання, яке має виконувати код
Кінцева мета проведення code review — довести фічу до продакшену. Орієнтуйтесь на те, чи запропоновані зміни наближають код до його завдання.
2. Скористайтеся пірамідою ревʼю для перевірки коду
Основа піраміди — це обов’язкові характеристики коду, далі йдуть менш важливі характеристики, але вони теж наближають код до ідеалу.
- Коректність: чи виконує код те, що повинен виконувати? Його можна протестувати? Він справляється з edge кейсами? А з конкретним Use Case?
- Безпека: чи є в коді вразливості? Чи безпечно зберігаються дані? Чи правильна input validation? Важливо виявити vulnerabilities якомога раніше, до релізу, щоб запобігти можливому витоку даних у подальшому.
- Читабельність: чи легко читати та розуміти код? З кодом будуть працювати ще довгий час, тому він повинен бути зрозумілим: відображати прописане в бізнес-вимогах, правильно використовувати назви класів, змінних та функцій.
- Елегантність: чи простий та зрозумілий код? Чи використовуються загальноприйняті паттерни? Чи приємно та цікаво з ним працювати?
- Альтруїзм: чи надихає код інших інженерів поліпшувати свої коди після вашої оцінки та запропонованих патернів?
3. Визначте час для код-рев’ю
Час огляду коду залежить від обсягу та якості коду. Це можуть бути й щоденні пул реквести, і раз на тиждень. Важливо разом із ІТ-командою сформувати свій ефективний підхід (наприклад, виділяти щодня по одній годині вранці) і намагатися дотримуватися його.
Не забувайте про пріоритети та зважайте на поточну ситуацію проєкту. Якщо сьогодні кінець спринту, не варто просити колегу зробити масштабні зміни в коді, щоб він став ще кращим. Відкладіть рефакторінг на інший спринт.
Якщо немає жорстких рамок на виправлення, уточнюйте у колег статус пул реквесту, інакше мердж на основну гілку може затягнутися надовго.
4. Встановіть чіткі стандарти
Наявність стандартів гарантує, що будь-який продукт буде відповідати бізнес-вимогам.
5. Встановіть метрики для оцінки якості коду
Продумайте, як можна оцінити ступінь підвищення якості коду.
6. Складіть чек-лист для перевірки коду
Він допоможе забезпечити організований підхід до перевірки коду. Наприклад, у чек-листі можна зазначити:
Структура коду:
- Форматування, відступи
- Правила іменування класів
- Правила коментування та документації
Продуктивність:
- Оптимізація коду
- Уникнення ресурсомістких операцій
Безпечність коду:
- Захист від поширених загроз (XSS, SQL- ін’єкції тощо)
- Правила авторизації та валідації користувача
Функціональність коду:
- Очікувана поведінка коду
- Обробка помилок
- Відлагодження помилок
Покриття тестами
- Правильні тест-кейси та умови тестування
Стандартизація коду:
- Дотримання стандартів та кращих практик кодування
- Обробка помилок та винятків
- Повторне використання, масштабованість
- Обмежуйте кількість рядків для рев’ю
Щоб перевірка коду проходила більш ефективно, розділяйте код на декілька рядків для перегляду за один раз.
7. Обмежуйте кількість рядків для рев’ю
Щоб перевірка коду проходила більш ефективно, розділяйте код на декілька рядків для перегляду за один раз.
8. Автоматизуйте code review
Інструменти автоматизації (PVS-Studio, AppRefactoring, SonarQube та інші) дозволяють скоротити час на перевірку коду. За лічені хвилин вони аналізують код, виявляють дублікати, перевіряють помилки, встановлюють вразливості та інші проблеми, а також пропонують способи виправлення.
9. Виділіть час, щоб детально обговорити помилки
Досвідчені інженери, що беруть участь у кількох проєктах одночасно, часто не мають ресурсу, щоб детально пояснити помилки новачкам. Виходить щось на зразок: «Зроби як добре, а як погано не роби».
Але знайти час на розгорнутий фідбек все ж треба. Без нього джун буде розвиватися повільніше. Та й згодом у нього може скластися думка, що всі code review проходять саме таким чином, тож і він наслідуватиме подібну модель. Як результат — неякісне рев’ю.
10. Залиште письмові коментарі
Базові питання можна вирішувати у листуванні: ви переглянули код і залишили поради, розробник отримав повідомлення про нові коментарі і далі починає працювати над виправленням помилок.
Щоб переконатися, що повідомлення точно дійшло до адресата, напишіть у робочому чаті або відразу в особисті колезі, відповідальному за код.
11. Обирайте формат коментарю залежно від складності ситуації
Розгорнуті коментарі потрібно надавати у складних, особливо — у спірних ситуаціях, коли колега має схожу з вашою експертизу і власну точку зору. Тут потрібно надати розгорнутий, аргументований коментар із конкретними пропозиціями, прикладами, поясненнями переваг та недоліків.
Якщо ж, приміром, колега залишив зайвий рядок, ви можете його видалити самі замість того, щоб додатково писати коментар «Видали цей рядок».
Коли пишете коментар, варто взяти до уваги і характер колеги. Так, бувають дуже вперті люди, що готові довго відстоювати свою правоту. В цьому випадку краще написати максимально розгорнуті коментарі з аргументами: що і чому вам не подобається, які можуть бути наслідки рішення колеги, що ви пропонуєте і чому.
12. Проговоріть коментарі в особистій розмові
Текстових коментарів може бути недостатньо, потрібна дискусія, живе спілкування. Зідзвоніться або зустріньтесь, щоб все проговорити. Будь-які спірні питання набагато легше розв’язувати особисто. Та й критика легше сприймається, коли вона зроблена під час розмови.
13. Розрізняйте необхідні та бажані коментарі
Зосередьтесь на дійсно важливих виправленнях. Якщо ви побачили рішення, яке зробили б інакше, але це не критично, можна так і написати: «Це краще зробити так, але твій спосіб теж підходить».
Приклади коментарів
- Підвищення ефективності: «Спробуй використати словник замість циклу, щоб перевірити наявність елементу в списку».
- Покращення читабельності: «Назва змінної info неінформативна. Будь ласка, дай більш зрозуміле ім’я».
- Обробка помилок: «У цьому випадку не варто повертати None. Спробуй викинути виняток».
- Безпека: «Спробуй використати замість модулю sha256 бібліотеку hashlib для більш безпечного хешування паролів».
- Стандарти кодування: «Краще уникати використання глобальних змінних. Більше підійдуть властивості класу».
- Покриття тестами: «Додай, будь ласка, негативні тестові випадки. Так можна буде перевірити поведінку коду в непередбачених ситуаціях».
14. Будьте відповідальними
Виконуйте якісний code review. Пройтися по коду поверхнево, вкласти в нього мало часу буде недостатньо (краще тоді вже взагалі від нього відмовитися). Після того, як ви його заапрувили, ви стаєте відповідальними за нього не менше, ніж автор.
15. Ефективний code review має розвивати
Огляд коду — це активний діалог, коли обидва співрозмовника на одному рівні: обмінюються думками, шукають рішення. Діалог допомагає «витягнути» думки у менш досвідченого фахівця. Часто через невпевненість джуніори бояться висловити свої ідеї, навіть якщо не згодні із рішенням більш досвідченого програміста.
Тож варто допомогти, підштовхнути колегу, дати можливість розкритися. Замість «Зроби так» скажіть: «Як думаєш, тут можна переписати так, щоб стало краще»? Новачок розуміє, що його думка важлива, а це стимулює розвиватися і надалі.
16. Ставтеся до колеги з повагою
- Початківці в IT сфері часто чутливі до негативних коментарів. Якщо не хочете демотивувати джуна, давайте фідбек тактовно, з повагою та вдячністю за виконану роботу, навіть якщо вона не дуже високої якості.
- Ви працюєте з кодом, а не з людиною. Критика має бути спрямована саме на роботу, а не на людину. Не переходьте на особистості. Замість «ти/твій підхід можна покращити» використовуйте «це рішення/підхід можна так-то покращити».
- Коли критикуєте, пояснюйте, у чому помилка, і завжди пропонуйте, як це покращити. Порівняйте: «Перероби це» і «Можливо, краще зробити це ось так».
- «Мені це не подобається» — так собі аргумент, щоб переробляти код. Зрештою, може бути декілька підходів, щоб реалізувати одне й те саме. Не варто сперечатися, якщо ви пропонуєте інший спосіб. Головне, щоб код працював і його було легко читати.
- Звертайте увагу на настрій колеги після рев’ю. Якщо помітите якусь напруженість, ще раз обговоріть із ним усе: чому ви залишили стільки і такі коментарі, чому тут ви акцентували увагу тощо. Так ви ще раз продемонструєте, що поважаєте колегу і бажаєте йому тільки добра.
- Підтримайте співробітника: «Всі колись були новачками і робили багато помилок. Головне — все ж можна виправити». Порадьте почитати документацію — так початківець зможе краще осягнути зауваження. Якщо помилки повторюються, зверніть на це увагу колеги.
- Підбадьорюйте і за хороший код, за цікаве рішення. Процес code review включає не тільки пошук помилок, але й заохочення за справну роботу.
Типові помилки під час код-рев’ю
Всі можуть припуститися помилок — не тільки джуніори, але й навіть досвідчені розробники. Найбільш розповсюджені:
1. Неуважність
Початківці можуть пропустити деталі: поставити зайві пробіли або не поставити крапку з комою.
2. Орфографічні помилки
Зазвичай це неправильні назви функцій, класів чи змінних англійською. Наприклад, якщо написати IsDisabled замість Disabled (є неактивним — неактивне), згодом можуть бути труднощі під час виконання програми.
3. Недотримання стандартів оформлення коду
У результаті код стає нечитабельним, його важко зрозуміти та вносити зміни.
4. Нехтування оптимізацією коду
Неоптимізований код впливає на продуктивність та ефективність програми.
5. Некоректне використання бібліотек та фреймворків
Якщо вибрані неправильні бібліотеки та фреймворки, це може вплинути на безпеку та ефективність програми.
6. Помилки в Git
До прикладу: програміст-початківець може випадково викликати в терміналі якусь програму, через що видалилися дані.
7. Нехтування перевіркою коду
Джуни не дуже люблять або забувають провести тестування коду на відповідність вимогам, через що можуть виникнути баги.
Кілька слів наостанок
Мета code review — не в тому, щоб знайти якомога більше помилок, а в тому, щоб допомогти один одному створювати кращий код. Якісний code review — це, перш за все, можливість для початківців навчитися чомусь у більш досвідчених ІТ-спеціалістів. Для рев’юера ж перевірка коду — це також можливість прокачати свої навички і знайти якісь прийоми, про які він не знав.
Будьте терплячими, відкритими до діалогу та готовими вчитися в процесі. З правильним підходом і належною увагою до деталей, code review може стати не тільки корисним, але й приємним процесом для всіх учасників.
ІТ-компанія Eastern Peak бажає вам якомога більше апрувів. І якщо ви зараз перебуваєте у пошуках роботи, маємо декілька вакансій. Відправляйте резюме та давайте разом створювати рішення, що перетворять цифровий світ на краще.
Читайте також:
