От време на време ми се случва да чувам неубедителни причини защо във фирмата на познат да не се рефакторира. Неща като „клиентът не иска“ или „няма време“. Повечето се свеждат до няколко грешни схващания за refactoring-а, най-честата от които: трябва да се отдели специално време за него. Писах за нещо подобно преди време – рефакториране тип „чистене на гараж“ и тип „чистене на кухня“. С този пост ще се опитам да разкажа няколко неща, които биха помогнали за „убеждаването“ на колеги, мениджъри или клиенти, както и за имплементирането ѝ.

Следват няколко проблема с рефакторирането тип „гараж“ т.е. отделянето на по-дълъг интервал от време (ден-седмица) за преработка на част от системата.

Аргументацията е трудна

Представете си, че правите дълъг ремонт вкъщи. Един от майсторите ви казва:

Ще свалим всички керемиди от покрива и ще ги пренаредим. Няма да ги сменяме с нови или да променяме каквото и да е друго – просто ще ги разместим. Някои може да се счупят и ще трябва да се заменят. Ще отнеме седмица, през която няма да пипаме нищо друго. Ще ни платиш за тази работа.

Не звучи като нещо, което бихте приели. Вероятно клиентът/product owner-ът се чувства по същия начин, когато чуе „ще рефакторираме админ панела“. Седмица, която не носи бизнес стойност на проекта, изглежда като лоша инвестиция. Има сериозна разлика между възприятието на техничарите и на нетехничарите – за първите нуждата от refactoring е очевидна, докато вторите трудно могат да я проумеят. Или поне на пръв поглед.

В един момент човек си казва „Уф, този код трябва да се рефакторира“ и той идва по различно време при различните хора. Едни са склонни да тръгват да преработват рано, докато други – да отлагат дълго. Едни са ОК с по-сложен код, докато други държат на максимално простия. За едни е достатъчно да забележат неконсистентност или лош дизайн, докато други имат нужда емпирично да се убедят, че се работи трудно. Затова двама членове на един екип могат да са на коренно противоположни мнения, въпреки че работят с един код.

Цената е висока

От гледна точка на бизнеса, екипът трябва постоянно да доставя нова стойност. Ако следвате идеите на Lean Startup, искате редовно да ship-вате нова функционалност, които да валидират предположенията на бизнеса (например, че потребителите имат нужда от нея или как биха я използвали).

Дори да сте в по-инертна организация, времето прекарано в преработка на системата изглежда просто като загубено време. Основната аргументация е short-term vs. long-term gain – ако не оправим кода сега, в бъдеще ще сме много по-бавни (и бъгави) в произвеждането на нова функционалност. Колкото повече отлагаме, толкова по-лошо ще става. Това е прост и разбираем аргумент (технически дълг) – представен така, кара хората се вслушват. Но квантификацията е трудна – почти невъзможно е да се измери дали си е струвало.

Качеството е култура

Основната цел на рефакторирането е качество. Качеството е важно – прави кода разбираем, прави новата функционалност по-лесна за писане, позволява на нови хора да влязат по-лесно в екипа и дава повече гъвкавост на бизнеса. Все неща, които намаляват най-голямото перо в бюджета – поддръжката. Да не говорим, че прави работата по-приятна, което сигурно ще доведе до подобрения.

А качеството е подход. Ако веднъж сте го изтървали, няма да го възстановите и поддържате само с няколко дни на месец. Това ми напомня на следния цитат от „Зен и изкуството да поддържаш мотоциклет“:

You want to know how to paint a perfect painting? It’s easy. Make yourself perfect and then just paint naturally. […] The making of a painting or the fixing of a motorcycle isn’t separate from your existence. If you’re a sloppy thinker the six days of the week you aren’t working on your machine, what trap avoidances, what gimmicks, can make you all of a sudden sharp on the seventh? It all goes together.

Ако качеството е ниско, това е защото за екипа не е важно да го поддържа. Решението на проблема е промяна на възгледите и изграждане на навици, а не да се сещате за него само когато ножът опре до кокъла. Заменете „качество“ с „хигиена“ и ще получите по-убедителен аргумент – един ресторант се поддържа чист когато се чисти постянно, а не когато се чисти „само в неделя“.

Аргументите дотук

Какво излиза? Такава преработка е трудна за продаване, трудна за измерване и най-вероятно няма дългосрочен ефект. Нищо чудно, че немалко хора „не рефакторират“. Но както споменах в началото, това се дължи на схващането му като „чистене на гараж“. А далеч по-ценното е „чистенето на кухня“. И се прилага по-лесно.

Може да следвате следните простички правила:

• Рефакторирането става само покрай добавяне/промяна на функционалност и само на код, който е свързан с нея. Ако рефакторирането не помага на текущата работа, значи може да почака.
• Не се прекарва повече от определен коефицент време във рефакториране (например 20%). По възможност, той е разпределен из другата работа, а не наведнъж. По 20 минути през няколко часа е по-добре, отколкото по един ден на седмицата.
• Boy Scouts’ Rule: Всеки път оставяте кода в по-добро състояние от това, в което сте го заварили. Няма значение колко малки са подобренията – достатъчно е да направите едно име по-ясно или да оправите малко форматиране.

Първите две правила държат scope-а на рефакторирането малък, а третото се опитва да насърчава постоянни малки подобрения (Kaizen). Така качеството бавно и постепенно се подобрява – без големи паузи в разработката, без осезаеми забавяния и без long-term trade-off.

Защо наистина?

И стигнахме до истинската причината защо някой не прави refactoring – качеството на кода не е сред ценностите на екипа. Ако сте заварили лош код, но искате да го подобрите, не е нужно да зарежете всичко за месеци в преработка. Достатъчно е да правите по нещо малко всеки ден. Нужно е само всички замесени да придобият тази нагласа.