Як вибрати який код для перегляду?

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

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

Ось деякі фактори, які я можу вважати, що можуть вплинути на вибір:

• Мова: C, Java, SQL, PL / SQL
• Вік коду: новий код проти старого коду
• Використання коду: часто використовуваний код проти (фактично) мертвого / мало використовуваного коду
• Важливість коду: Критичний код проти некритичного коду
• Розробник: Код молодшого розробника проти Старший код розробника

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

Деякі питання, пов'язані з периферією:

• Підходи до перегляду коду (згадки про перегляд критичних розділів та нового коду розробника)
• Чи варто спробувати переглянути весь наш код?

Загалом, ви повинні все переглянути . Якщо свіжа заявка містить 2000 LOC, всі 2 000 LOC необхідно переглянути.

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

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

• на кодовій базі (один монолітний код було б складніше переписати / переглянути, ніж набір окремих компонентів тощо),

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

• тип огляду, який ви робите (чи є у вас контрольний список рецензувань? Залежно від пунктів контрольного списку, ви можете спочатку переглянути деякі частини).

Якби я був ти, я би:

• дотримуйтесь принципу 80% -20%, згаданого в першому коментарі другого питання, з яким ви пов’язані.

• враховуйте, що 100%, будучи ідеалом, не варто того. Це як 100-відсоткове покриття коду для одиничних тестів, за винятком того, що таке покриття коду здебільшого неможливо або надзвичайно дорого.

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

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

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

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

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

Перегляньте всі нові зміни, які були внесені до того, як вони перейдуть у виробництво. сценарії встановлення, вихідний код, зміни бази даних, все! Вся суть перегляду коду полягає в тому, щоб не допустити, щоб поганий код став його виробництвом. Будь це погана організаційна схема або просто введена помилка, тому що щось пропущено.

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

Якщо ви невблаганно рефактор, то перегляд коду стає корисним. Інакше це марна трата часу.

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

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

Почніть з перегляду всього нового коду та модифікацій існуючого коду.

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

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

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

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

Мета огляду коду - покращити та виправити помилки, які ви зараз робите, та поділитися цими знаннями серед команди.

У моєму проекті ми включаємо перегляд коду як обов'язковий у більшості випадків для будь-якого завдання / історії користувача / помилки, що розробляється. Ми використовуємо scrum / agile процеси, і квиток / історія не переміщується до побудованої (тобто відставання для QA), поки не будуть написані одиничні тести та не буде завершено перевірку коду.

Для цього ми використовуємо аналіз Atlassian FishEye з оглядом коду Crucible, інтегрованим з JIRA + SVN.

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

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

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

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