Як виправдати час рефакторингу коду?

Майте дуже великий проект понад 70 тис. LOC.

Проект, безумовно, потребує певного рефакторингу коду в Core Framework та інших частинах. На початку проекту для рефакторингу не було встановлено часу. Однак з часом і більше 40 розробників спільно і покинули проект. З моєї точки зору, це незамінно.

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

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

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

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

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

Якщо це не робиться невеликими кроками, то це насправді не рефакторинг, так?

Тут усі відповіді хороші - але чи можу я додати до цього бізнес-аспект. Дозвольте запитати вас ЧОМУ / Так-що? (подумайте про свого чіткого шефа для волосся (PHB) :)

PHB: чому?
Ви: Це полегшить виправлення
PHB: Так що?
Ви: Це збільшить пропускну здатність - ми швидше отримаємо нові конструкції з дверей?
PHB: Так що?
Ви: Помилка ... Корисніші клієнти?
PHB: WTF?
Ви: я маю на увазі збільшення рекомендацій, більшу задоволеність, 
     більший прибуток швидше через низький оборот
PHB: О! Звучить красиво. Але це тільки "звучить" приємно, я це бачу?
Ви: WTF?
PHB: Покажіть мені гроші! (тобто цифри, будь ласка)
Ти: О! Brb ... (перейдіть і покладіть кілька номерів у просту електронну таблицю, щоб зробити свій випадок)

В основному ви повинні зробити діловий випадок - запустіть кілька цифр, щоб уточнити свій розумний процес, і отримайте цифри, щоб об'єктивно відображати «користь». Ви також дізнаєтесь, скільки часу це займе, приблизні витрати тощо. Це має мати сенс. Якщо воно того варте, ви отримаєте зелений сигнал і, можливо, теж очолите ініціативу :)

Якщо ви думаєте, як я можу виміряти все, спробуйте цю книгу

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

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

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

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

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

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

Або ви переробляєте стіну для того, щоб побудувати двері, або об’їжджаєте її.

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

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

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

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

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