Чи варто спробувати переглянути весь наш код?

Наразі ми змінюємо процес розробки, і мені цікаво, чи варто намагатися тримати 100% перевірених нами зобов’язань.

Який ваш досвід щодо коду?

• Ви схильні витрачати на них «багато» часу (скажімо, 1/2 години на день), або просто скупітесь максимум на 5/10 хвилин?
• Чи є у вас фіксований час, який потрібно витратити на день / тиждень / спринт / проект?
• Найголовніше, чи вважаєте ви, що цільовим завданням має бути 100% коду для перевірки, або 100% не потрібно?

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

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

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

До речі, важливо, щоб хтось переглядав код ..

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

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

Огляди повинні виконуватися не тільки за кодом, але і за дизайном.

Також огляди не замінюють тести та інструменти:

• Відгуки можуть сушити запуск коду
• Відгуки можуть включати аналіз коду
• Відгуки вивчають можливість повторного використання та читання
• Огляди можуть вивчити деякі аспекти ефективності, однак це не замінює фактичного вимірювання часу роботи та виявлення шийок пляшок
• Існують інструменти для аналізу статичного коду
• Існують інструменти для тестування умов кодування, не витрачайте на це перегляд часу
• Код, системний та інтеграційний тести код мокрого запуску
• Тест блоків, системних та інтеграційних тестів може бути повторений автоматично, огляд коду зазвичай одноразовий
• Тестові одиниці повинні мати високе покриття коду і перевіряти як основні сценарії успіху, так і кінцеві умови, огляд коду може це зробити лише частково
• Інтеграційні тести перевіряють здатність підрозділів або систем працювати разом, огляд коду не може замінити це
• Системні тести перевіряють функціональність всієї системи, огляд коду не може замінити це

Спробуйте присвятити оглядам задану кількість часу на місяць (або за спринт). Виберіть код, який ви хочете переглянути в наступному виділеному слоті, використовуючи евристику, наприклад:

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

І пам’ятайте, ви переглядаєте код (або дизайн або тести), а не автори.

Рекомендую наступні матеріали для читання:

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

Це залежить.

Це залежить від вашого програмного забезпечення:

• Якщо він керує електронним кардіостимулятором або космічним човником, то, безумовно, так.

• Якщо це викидний прототип, то, ймовірно, ні.

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

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

Спочатку потрібно відповісти на це запитання: Чому ви переглядаєте код?

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

Деякі огляди коду виконують саме те, що робиться чи було б тестування. Якщо це мета ваших відгуків, то наближення до 100% - це гарна ідея, якщо у вас мало тестування. Однак, дозволяючи тест-інструментам це зробити, це зменшило б необхідність перегляду всього коду.

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

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

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

Що стосується часу, це все переходить до того, наскільки пріоритетним є компонент. Були випадки, коли я витрачав 10-15 хвилин на перегляд, та інші випадки, коли кілька людей читали код окремо, потім зайшли в кімнату, щоб зробити більш офіційний процес перевірки, який триває 30-45 хвилин (залежно від розміру модуль).

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

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

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

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

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

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

По мірі того, як ви робите нулі в процесі, ведіть замітки. Що ти знайшов? Що QA знайшов пізніше? Що знайшли ваші клієнти? Чому ті клопи втекли від вас?

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

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

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

Перегляд коду, IMO, потрібен. Ви 99,999 ...% часу не завжди будете правильно, тому вам потрібно переконатися, що це правильно. У мене встановлений час? Ні. Але я забираю час, щоб перевірити свій код. Зазвичай у мене колега робить те саме.

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

Що стосується того, скільки часу витратити на експертні огляди, хороша практика - це залишити 5-10% від загального розрахункового часу на розробку та відповідь на перегляд коду.

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