Що містить стандартний огляд коду?

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

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

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

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

Але коли відбувається щось більш задіяне, це зазвичай відбувається так:

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

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

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

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

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

Також важливо застосовувати стандарти в огляді коду, але не робити їх єдиним фокусом.

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

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

• не фіксуються через часові обмеження
• виявилося більш дратівливим, ніж те, що варті рекомендації

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

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

На мою думку, наприклад, можуть існувати такі:

• загальні вказівки щодо синтаксису та кодування (виберіть те, що вже існує, та використовуйте інструменти, які перевіряються автоматично)
• Правильна обробка виключень
• Правильна лісозаготівля
• Гарне використання парадигм для мови (SOLID для мов OO)
• Очевидні і добре продумані залежності між компонентами (використовуйте такі інструменти, як NDepend)
• Робочий сценарій складання
• Документація присутня (запуск розробника, посібник з установки)
• внутрішні бібліотеки для використання
• політика компанії
• стороннє оснащення, яке не дозволено
• Одиничні тести, наявні та невдалі
• охоплення кодом 90%
• ...

З огляду на це, огляд коду складається з програмного забезпечення, яке перевіряється відповідно до настанов, і:

• обговорюйте порушення з програмістом
• виправити непотрібні порушення
• коментувати необхідні порушення