Защо не правим refactoring?

От време на време ми се случва да чувам неубедителни причини защо във фирмата на познат да не се рефакторира. Неща като „клиентът не иска“ или „няма време“. Повечето се свеждат до няколко грешни схващания за 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 – качеството на кода не е сред ценностите на екипа. Ако сте заварили лош код, но искате да го подобрите, не е нужно да зарежете всичко за месеци в преработка. Достатъчно е да правите по нещо малко всеки ден. Нужно е само всички замесени да придобият тази нагласа.

4 thoughts on “Защо не правим refactoring?

  1. бих искал да поправя „не носи пряка бизнес стойност на проекта“. Но ти го каза в последния абзац. Променяемостта и поддръжката просто не се измерват при създаването на продуктите. Не съм чел как сключват мениджъри договори за създаване на приложение но мисля че такива неща не се включват.

    Надявам се ме разбрахте :)

  2. Бахти, 15 години работя с програмисти и един път не съм чул някой да каже „Рефакториране“. Всеки идва и казва „балсъмговмизериятадетсанатворилитияпредимен“ и се почва всичко от нулата. Което мен ме устройва – ако ще дам Х пари за сложна дума (Рефакториране), по-добре да ги дам за нов продукт!

  3. @Боби, не е толкова сложна дума даже изобщо. Съгласен съм, по-добре да ги дадеш нов продукт, но ако новия няма общо или има малко общо със стария.

    Но ако става дума само за надграждане и много малко (5-10%) премахване на функционалност тогава определено не е по-добре да ги дадеш за нов продукт.

  4. Работил съм във фирми където кода е поддържан и във такива където кода е шит и никой не полага усилия да го подобри (даже обратното не им пука и го засрат още повече с предтекста , че така или иначе било орано )

    За мен най приятната част от програмирането и точно refactoring-а , не мислиш как ще стане (не го мислиш много) и в теб остава задоволството че си оставил нещо читаво

    Най противоречива и шарена е темата за това дали си струва да се плаща за refactoring (наистина няма мерило и начин за доказване че рефакторинга е полезен и че се изплаща в дългосрочен план , може би единствено в случаите когато всичко е тотално о*рано в продължение на години ,

    работил съм за такива дето са давали за няколко години сумарно чували с пари за сайт който е писан без mvc с простички include от файл във файл във файл във файл където SQL, PHP, HTML , JS и дори CSS са забъркани във сочна и тлъста чорбичка )

    Работил съм и във фирми където кода е изключително еднотипен , изчистен и всяка заплетеност се преправя рано или късно (eми работата там ми беше супер приятна и дори този дето ми даваше заданията повтаряше на майтап да съм намалил темпото че нямало кво да ми дава да работя)

Вашият коментар

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани с *