Z některého kódu se mi dělá fyzicky nevolno a mám chuť ho od začátku přepsat, což by se rozhodně dělat nemělo. Další nápad je, přidat refaktorování do backlogu, ale tam nepatří. Ron Jeffries to vysvětluje v článku Refactoring – Not on the backlog! Článek jsem s laskavým svolením autora přeložil do češtiny.

30. července 2014

V nedávné době se objevilo hodně otázek na konferencích a v e-mailových diskusích ohledně toho, zda dávat refaktorovací story do backlogu. I kdyby technický dluh vyrostl, tak to nic nemění na tom, že je to hrozná myšlenka. Vysvětlení proč:

Na začátku projektu je kód čistý. Pole je posekané, život krásný a svět náš. Všechno půjde hladce.

Můžeme snadno a rychle dodávat featury, přesto to musíme pokaždé vzít malou oklikou nebo trochu zabočit. Věci se zdají celkem čisté, navíc spěcháme. Nevšimneme si, že se něco kazí, a tlačíme na rychlost. Přesto občas necháváme na našem téměř perfektní poli kódu nějaké trní. Občas to lidé nazývají technický dluh. Ve skutečnosti to žádný dluh není, je to jen ne úplně dobrý kód. Ale ještě nevypadá tak zle. Nicméně jak tvoříme, musíme obcházet houští nebo se prodrat skrze ně. Především chodíme kolem. To nás nevyhnutelně trochu zpomalí. Jsme tedy o něco méně opatrní než předtím, abychom udrželi rychlost. Takže brzy vyroste další plevel. Nové křoví nás spolu se starým zpomalí ještě víc. Uvědomíme si, že je to problém, ale jsme příliš ve spěchu, abychom s tím něco udělali. Tlačíme víc na pilu, abychom udrželi naši počáteční rychlost. Brzy je polovina kódu, se kterou musíme pracovat, zarostlá plevelem, podrostem a překážkami všeho druhu. Můžou tam někde být dokonce staré plechovky nebo špinavé oblečení. Třeba i nějaká jáma. Každý výlet skrz tohle zaneřáděné pole se stává dlouhou cestou s vyhýbáním se pastím, kterém jsme za sebou nechali. Do některých nevyhnutelně spadneme a pak se z nich musíme vyhrabat. Zpomalujeme ještě víc než kdy předtím. Něco se musí stát. Hustota problémů je pro nás teď velmi viditelná a je zřejmé, že nemůžeme na poli rychle poklidit. Je potřeba mnoho refaktorování, abychom se dostali zpět na čisté pole. Jsme v pokušení požádat našeho product ownera o čas na refaktorování. Často tento čas nedostaneme: žádáme o čas na opravu něčeho, co jsme pokazili v minulosti. Nad tím nejspíš nikdo oči nepřimhouří. Pokud bychom čas dostali, nedobrali bychom se dobrého výsledku. Uklidíme, co vidíme a co lze stihnou v daném čase, který nikdy nebude dostatečný. Trvalo mnoho týdnů, než se kód pokazil, a určitě nedostaneme tolik týdnů na spravení.

To není ta správná cesta. Velké refaktorovací akce je těžké prosadit a když ano, tak s velkým zpožděním dostaneme méně, než v co jsme doufali. To není dobrý nápad. Co bychom tedy měli dělat? Jednoduše! Místo obcházení každého roští si u další featury najdeme čas na to, prorazit cestu skrz některá. Možná jiná obejdeme. Vylepšíme kód, kde pracujeme a ignorujeme ten kód, kde ne. Dostaneme krásnou čistou cestu pro nějakou naši práci. Je šance, že tohle místo někdy znovu navštívíme. Takhle funguje softwarový vývoj.

Možná featura zabere delší dobu. Často ne, jelikož úklid nám pomůže s proražením cesty i pro tu první featuru. Vypláchnout a opakovat. S každou novou featurou vyčistíme kód, který je pro ni potřeba. Investujeme o trochu víc času, než kdybychom pokračovali v zaneřáďování, ale ne o moc a často méně. Obzvláště jak proces pokračuje, těžíme z výhod úklidu čím dál tím více a věci začínají jít rychleji a rychleji. Brzy (často už v tom samém sprintu, kdy začneme uklízet) si všimneme, že následující featura vlastně používá oblast, kterou jsme předtím vyčistili.

Práce jde lépe, kód se stává čistším a my dodáváme víc featur, než kolik jsme byli schopní předtím. Každý vyhrává. Začneme těžit z postupného refaktorování hned. Pokud bychom bývali čekali na velkou várku refaktorování, stálo by nás to víc úsilí a jakékoliv výhody by přišly později, jestli vůbec. Takže by se spíš plýtvalo prostředky, které nám zatím nic nepřináší.

Související