Як визначити ефективність процесу перегляду коду?

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

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

Хто-небудь стикався з цим питанням раніше або має якісь думки щодо того, що добре працює при оцінці коду?

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

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

Різні показники зустрічей також були б доречними. Сюди входить час підготовки, час зустрічі, зчитування рядків коду, виявлені недоліки в огляді тощо. З цих даних можна зробити деякі спостереження. Як приклад може бути, якщо ваші рецензенти витрачають велику кількість часу на читання коду, готуючись до огляду, але знаходять дуже мало проблем. У поєднанні з даними DRE ви можете зробити висновок, що якщо дефекти перевіряються на інтеграційному тестуванні чи на місцях, то вашій команді потрібно зосередитись на техніках огляду, щоб мати можливість знайти проблеми. Ще одна цікава примітка - це рядки коду (або якесь інше вимірювання розміру), прочитані під час зустрічі порівняно з часом зустрічі. Дослідженнями встановлено, що швидкість типового перегляду коду становить 150 рядків коду на годину.

З будь-якою з цих показників важливо зрозуміти їх вплив на процес. Аналіз кореневих причин, використовуючи такі методи, як « чому-тому» , « П’ять Віт» або « Ісікава» діаграми можуть бути використані для виявлення причин, через які огляди коду (або будь-яка інша методика підвищення якості) є (не) ефективними.

Вам також може бути цікава ця стаття про перевірки групи Ganssle та стаття Каперса Джонса в Crosstalk про дефектні потенціали та DRE .

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

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

Як ви хотіли досягти вимірюваної ефективності - ось що я б запропонував:

1. Показник, пов’язаний із кількістю переробленої роботи - Кількість часу, коли переробка застосовується в одному модулі / об'єкті / робочому елементі, є мірою того, наскільки поганий цей код з точки зору ремонтопридатності. Коли застосовується ефективний перегляд коду, як часто ми можемо зменшити запит на повторну роботу на одному модулі?

2. Показник, пов’язаний із сумою змін, що виникає при кожному запиті на зміну. Кожен раз, коли виникає запит на зміну - на погано врахований код завжди впливатиме більша кількість модулів. Захід, ймовірно, вказуватиме на те, що після огляду коду - а чи було зменшення такого поширення змін для подібного запиту на зміну в минулому?

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

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

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