Рефакторинг — це не завдання в Backlog

Деякий час тому було досить багато шуму в Інтернеті і питань на конференціях з приводу того, чи є завдання по рефакторінгу коду такого ж роду завданнями, як і всі інші, з необхідністю описувати їх, поміщати в Backlog, а потім переміщати в новий спринт. Я вважаю що це поганою ідеєю, навіть у разі непомірно розрісся «технічного боргу» проекту. І ось чому:
image
Коли починається новий проект — його код чистий і прекрасний. Саме час проектувати красиві абстракції, писати гарні інтерфейси і професійні реалізації. Життя прекрасне! Наш проект теж.

image
Ми продовжуємо додавати функціонал, все йде гладко. Потім в певний момент нам доводиться трохи зрізати кут, трохи звернути з наміченої доріжки, додати зовсім-зовсім маленьку обробку одного окремого випадку… ні-Ні, ніяких «милиць»! Просто трохи необхідного коду, майбутнього красиву теорію до працюючої практичної реалізації. Ніщо не віщує біди і розробка йде досить бадьоро.
image
Тим не менш, на полотні нашої ідеальної картини коду все-таки виникають невеликі плями. Деякі люди називають їх «технічним боргом». Це не означає, що ви дійсно комусь щось заборгували: це просто не дуже хороший код. Але він як-то працює, вирішує свої завдання.
image
По мірі продовження розробки ми будемо натикатися на подібні місця в коді все частіше і кожен раз у нас буде вибір: кинутися грудьми на амбразуру і переписати все начисто або обійти проблемне місце заради вирішення іншого завдання (тієї, над якою ви працюєте в даний момент). Іноді ми кидаємося у бій, але все-таки частіше ми вибираємо варіант з обхідним шляхом.
image
У кожному окремому випадку це уповільнює нас лише трохи. Але, оскільки по мірі наближення дедлайну вимоги до швидкості розробки лише ростуть, нам доводиться поступово знижувати планку своїх вимог до якості коду — і це призводить до зростання кількості «плям».
image
Ці нові проблемні місця (у додаток до старих) гальмують нас все більше і більше. Ми усвідомлюємо наявність проблем, але поспіх у плані вирішення поточних завдань не дозволяє сфокусуватися на чому-небудь ще. Ми змушені працювати більше, просто заради збереження колишньої швидкості.
image
В якийсь момент раптом виявляється, що половина коду, який ми пишемо, призначена для підпор, обходів, хаків і подолання інших типів перешкод, створених нами ж раніше. Тут хороший код, там поганий, а тут рибу загортали.
image
Кожна прогулянка по цьому мінному полю замість прямої лінії від точки А до точки Б раптом стає заплутаним маршрутом по лабіринту, без жодної гарантії досягнення кінцевої мети. Навіть над-зусилля вже не дозволяють вам рухатися до мети з тією ж швидкістю, що і раніше.
image
Важливість проблем тепер видно неозброєним оком. І їх не можна виправити, просто викинувши все і почавши проект з нуля. Нам потрібно виконати багато завдань по рефакторінгу коду, а на ці завдання нам потрібно час, який доведеться просити у замовника. Часто цей час нам не буде виділено: адже ми просимо час для того, щоб виправити власний код, на розробку якого вже виділялося час раніше і про готовність якого ми ж самі і заявляли.
image
Навіть якщо і буде виділено, не варто розраховувати на швидкий результат. Ми зможемо виправити лише ті проблеми, які бачимо конкретно зараз і лише в тому обсязі, на який вистачить виділеного часу (а його не буде багато). Ми писали цей поганий код багато тижнів (або місяців), і у нас точно не буде стільки ж часу щоб переписати цей код.

Це не той шлях, яким нам треба йти. Довгі періоди рефакторінгу не приносять великий і помітною відразу користі проекту. Їх дуже важко продати замовнику, оскільки він не побачить, за яку функціональність у нього просять грошей. Тобто це погана ідея. Що ж робити?
image
Спрощувати! При одержанні кожної наступної завдання, ми розробляємо план її реалізації. Якщо по ходу цього плану ми впираємося у «пляму» технічного боргу, то завдання по його рефакторінгу стає частиною реалізації поточної фічі. Звичайно, ми не можемо взятися відразу за всі погані місця в коді. Але цього робити не потрібно! Якщо по ходу реалізації якої-небудь нової функціональності ви виправите більше старих «плям», ніж створите нових підпор та милиць — загальна якість коду проекту підвищиться. Наступного разу, коли при роботі над новою задачі вам раптом доведеться звернутися до вже виправленому місцем — ви з задоволенням відзначили, що воно більше не вимагає полірування напилком, а відразу працює добре і виглядає приємно. Так і відбувається розробка програмного забезпечення.

Можливо, розробка кожної окремої фічі таким чином займе трохи більше часу, ніж ви припускали спочатку. Але розробка всього набору функціоналу з таким підходом займе менше часу, оскільки на останніх етапах перед дедлайном ви будете мати можливість працювати з відносно чистою кодової базою, додавання нового функціоналу не буде забирати час на пошуки обхідних шляхів. Крім того, такий особисто ваш підхід до розробки добре позначиться і на продуктивності всієї команди.
image
Повторення — мати навчання. З кожною новою фичей ми робимо код трохи чистіше. Лише трохи, але кожен раз. Багато разів по «чуть-чуть» в якийсь момент дозволять зі спокійною душею написати нову, добре працюючу фічу, за яку не соромно, замість того, щоб рвати на собі волосся і боротися з бажанням видалити взагалі весь цей сміття.
image
Момент усвідомлення корисності безперервного рефакторінгу не так далеко, як вам може здатися. Деякі люди починали помічати його вже до кінця того ж спринту, в якому вони почали використовувати цей підхід. Сили безперервності і инкрементальности процесу дають про себе знати дуже швидко. З якогось моменту на виконання нового завдання з рефакторінгом починає йти МЕНШЕ часу, ніж на виконання цієї задачі без рефакторінгу (в силу витраченого раніше часу на поліпшення супутнього коду).

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

Так що рефакторинг — це не завдання в Backlog, це частина кожної задачі в ньому.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.