Я підозрюю, що в моїй команді приховується головний перегляд коду. Занадто багато оглядів коду об'єднано без коментарів.

Мені здається, що немає такого поняття, як огляд коду без жодного коментаря.

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

Оновлення

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

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

Тому я додав бібліотеку під назвою "jscpd" для виявлення копійних паст. Не вдалося зібрати на копіях паст. Це негайно усунуло одну проблему.

далі ми спробуємо кодеклімат.

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

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

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

Але на своєму досвіді я підозрюю, що відбувається щось інше.

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

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

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

Примусовий інструмент поверх зламаного процесу не покращить процес.

Я не люблю публікувати однорядкові відповіді, але ця здається доречною:

Беріть участь у процесі.

Отримайте такий інструмент, як плагін ReviewBoard або Redmine's codereview . Тоді кожен огляд створюється як завдання, яке має хтось закрити чи прокоментувати (подібно до квитка про помилку). Тоді ви маєте простежити, хто створив оглядовий квиток та хто його закрив. Ви можете зв'язати оглядові квитки з реєстрацією вихідних кодів, тобто створити квиток з перегляду.

Кілька речей (якщо чесно, більшість із них висвітлюються у відповідях, але я хотів поставити їх в одному місці)

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

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

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

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

Ви можете задокументувати те, що хоче команда, в оглядах коду, які ви обговорювали та домовлялися з розробниками. Деякі речі, які ви можете розглянути як частина оглядів коду, це:

• Переконайтеся, що код виконує те, що він повинен робити, тобто відповідає вимогам

• Стиль коду для того, щоб розробники кодували послідовний стиль

• Оптимізація, наприклад, кількість викликів функцій

• Архітектура та використання

• Обробка винятків та ведення журналів

• Технічна заборгованість: це код у кращому стані, ніж коли розробник почав працювати над ним

• Ознайомтеся і створіть код (я вважаю це корисним, але інші розробники в моїй команді вважають за краще залишити це тестерам)

• Використання автоматизованого інструменту (я використовував SonarQube ). Мені здається корисним інтегрувати це у свій процес збирання для вдосконалення коду, наприклад, збільшення покриття тесту

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

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

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

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

По-перше, дозвольте задати вам питання. Ви використовуєте систему контролю версій (наприклад, Mercurial, Git)?

Якщо ваша відповідь "так", тоді продовжуйте.

1. заборонити всім натискати що-небудь (навіть невеликі виправлення) безпосередньо на головну гілку (стовбур) *
2. розробляти нові функції (або виправлення) в окремих галузях
3. коли розробники вірять, що галузь готова інтегруватися в майстер, вони створять "запит на витяг"
4. заборонити всім об’єднувати власний запит на виклик *
5. інший розробник оцінить запит на витяг та перегляне новий код
6. якщо код проходить перевірку, добре, запит на витяг можна об'єднати, інакше можна застосувати виправлення
7. повторіть крок 6, поки код не дозріє досить (це можна зробити без запуску) **
8. зроблено, весь ваш новий код перевіряється (принаймні коротко) людиною, що має ім’я

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

Дійте там.

* може бути застосовано автоматично, за допомогою гачків на стороні сервера

** Ця процедура повністю підтримується GitHub (серед інших), і вона досить проста у використанні, перевірте її

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