Як визначити пріоритетність та суворість «поліпшення коду»?

У нашій системі відстеження помилок є поля "пріоритет" та "серйозність". Ми визначаємо суворість як "як це впливає на користувача", а пріоритет - як "як це впливає на продукт".

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

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

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

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

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

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

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

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

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

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

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

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

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

Цікаве запитання.

Думаю, вам доведеться оцінити, скільки рядків коду і скільки модулів може змінити зміна.

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

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

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

Почнемо тут з двох припущень.

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

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

Я би вкрав голосування від рухливого руху:

Введіть помилку, зробіть грубі здогадки щодо суворості та пріоритетності,

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