Хороші вказівки та практики для обов'язкового перегляду коду [закрито]

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

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

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

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

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

1. Зробіть огляди короткими.

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

   Також огляд повинен залишатися оглядом, а не дискусією. Це не означає, що автор коду не може відповісти, але він не повинен перетворюватися на довгий обмін думками.

2. Уникайте перегляду коду, який є занадто поганим.

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

3. Перед оглядом використовуйте автоматизовані шашки.

   Автоматизовані шашки уникають витрачати дорогоцінний час, вказуючи на помилки, які можна знайти автоматично. Наприклад, для коду C #, запуск StyleCop, метрики коду і особливо аналіз коду є хорошою можливістю знайти деякі помилки перед оглядом. Тоді перевірка коду може бути проведена на бали, які вкрай важко зробити для машини.

4. Вибирайте ретельно осіб, які роблять огляди.

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

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

5. Робіть як неформальні, так і офіційні огляди.

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

   • Інжекція SQL,
   • Неправильні припущення щодо мови, які можуть призвести до помилок,
   • Конкретні ситуації, які можуть призвести до помилок, наприклад, пріоритет оператора. Наприклад, у C # var a = b ?? 0 + c ?? 0;може виглядати нормально для того, хто хоче додати два нульових числа з поєднанням у нуль, але це не так.
   • Розподіл пам'яті,
   • Ледаче завантаження (з двома ризиками: завантажувати одну і ту ж річ не один раз, а не завантажувати її взагалі),
   • Переливи,
   • Структури даних (наприклад, з помилками, такими як простий список замість хеш-набору),
   • Валідація вводу та захисне програмування в цілому,
   • Безпека нитки,
   • тощо.

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

6. Поступово регулюйте контрольний список.

   Щоб залишатися конструктивними та корисними протягом часу, контрольні списки, які використовуються в офіційних оглядах, повинні бути відрегульовані з часом залежно від виявлених помилок. Наприклад, перші неофіційні огляди можуть виявити певну кількість ризиків SQL Injection. Перевірка SQL Injection буде включена у контрольний список. Коли через кілька місяців виявиться, що автор зараз дуже обережно ставиться до динамічних та параметризованих запитів, SQL Injection може бути видалений із контрольного списку.

У нас майже як контрольний список:

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

Працює досить добре.

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

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

Друга річ - це автоматизація настільки, наскільки ви можете!

• контроль пробілів
• програмне забезпечення для управління стилем
• автоматизовані побудови перед переглядом коду
• автоматичне тестування перед оглядом коду

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

Багато чого залежить від ваших технологій, але знайти те, що ви зможете перевірити автоматично, чим більше, тим краще.

Ми ще не виграли цю битву, але саме це ми вважаємо корисним.