Коли робити перегляд коду

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

Ми використовуємо VS та TFS 2010, і ми команда з 6 осіб.

Наразі ми розгалужуємо функції, але працюємо над переходом на розгалуження для scrum.

Наразі ми не використовуємо полиці і не хочемо реалізовувати, якщо є інші методи.

Як ви рекомендуєте реалізувати перегляд коду для історії користувача?

Це залежить від характеру розповідей користувачів.

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

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

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

В кінці спринту ви об'єднуєте свою галузь розробника в інтеграцію / виробництво тощо.

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

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

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

Ви можете повністю уникнути огляду коду шляхом спарювання.

Усі в команді місцеві? Якщо так, просто попросіть когось зайти і ознайомитись, перш ніж код буде зареєстрований. Не локальний? Запустіть улюблену програму спільного використання екрана та зателефонуйте комусь. Я особисто це роблю часто. Іноді я роблю це просто, щоб сказати "Гей, подивись, що я зробив!"

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

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

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

Ви повинні використовувати кодові (або інші конкретні) зміни переважно для покращення своєї команди, очікуючи результатів на середньо / довгостроковій основі. Це вплине на ваші ПРОЕКТИ, але в довгостроковій перспективі буде результатом вдосконалення TEAM.

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

Чи не очевидно робити огляд коду, перш ніж перевірити свій код?

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

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