Час, відведений на огляди коду

Якщо ви робите перевірку коду

• Скільки часу ви витрачаєте на огляд коду, порівняно з впровадженням?
• Скільки змін підлягає перегляду коду?
• ти думаєш, що це набагато / має бути більше?

Чи є дослідження щодо ефективності?

[редагувати] дякую всім за відповіді, важко вибрати "переможця" для такого питання, в інших відповідях також є багато цінної інформації.

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

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

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

Що стосується досліджень, то програмне забезпечення Smart Bear безкоштовно надішле вам невелику книгу « Кращі збережені секрети рецензування коду» . У ньому є ряд статей про різні аспекти перегляду коду, включаючи дослідження про те, скільки часу їм потрібно зайняти та наскільки вони ефективні.

У нашому проекті кожна суттєва зміна системи переглядається керівником групи або разом з іншим розробником, який буде головним "споживачем" нового модуля. Ми говоримо по скайпу і використовуємо Rudel в Emacs (плагін для спільного редагування, в основному він дозволяє декільком користувачам редагувати один і той же файл в прямому ефірі), або TypeWith.me (Piratepad), або хтось із нас ділиться екраном у скайпі.

Важко кількісно це оцінити, тому що щоденні зміни, як-от нові перегляди, сторінки тощо, не переглядаються. Ми переглядаємо нові модулі, основні оновлення та рефактори. Що стосується великих змін, то перегляд коду може зайняти від 10% до 30% часу, але воно того варте.

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

Для таких простих речей, як іменування конвенцій та помилок сфери застосування, ми використовуємо власні або відкриті джерела автоматичних інструментів (jslint, pylint, pyflakes, pep8). І ми не обмежуємо комітів і натискань: ми використовуємо Mercurial, який має дуже просте розгалуження та злиття (я повинен сказати, простіше, ніж у Git). Помилки - це не питання перегляду коду.

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

На це немає правильної чи неправильної відповіді. Але, як багато хто з мене раніше, припустив - якщо перевірку коду проводить зовнішній член команди [настійно рекомендований метод], це може становити приблизно 30% до 35% зусиль з розробки. Але якщо це зробить внутрішній член проектної групи, який був частиною команди розвитку [не рекомендується], це може бути завершено приблизно в межах 20% часу, необхідного для зусиль на розробку.

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

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

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