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 refak­to­rování do backlogu, ale tam nepatří. Ron Jeffries to vysvět­luje v článku Refac­toring – 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 konfe­ren­cích a v e-mai­lových diskusích ohledně toho, zda dávat refak­to­ro­vací story do backlogu. I kdyby technický dluh vyrostl, tak to nic nemění na tom, že je to hrozná myšlenka. Vysvět­lení 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šim­neme 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 nevyh­nu­telně 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 praco­vat, zarostlá pleve­lem, 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 nevyh­nu­telně spadneme a pak se z nich musíme vyhra­bat. Zpoma­lu­jeme 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 pokli­dit. Je potřeba mnoho refak­to­rování, abychom se dostali zpět na čisté pole. Jsme v pokušení požádat našeho product ownera o čas na refak­to­rování. Často tento čas nedosta­neme: žá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 dosta­tečný. Trvalo mnoho týdnů, než se kód pokazil, a určitě nedosta­neme tolik týdnů na spravení.

To není ta správná cesta. Velké refak­to­ro­vací akce je těžké prosadit a když ano, tak s velkým zpožděním dosta­neme méně, než v co jsme doufali. To není dobrý nápad. Co bychom tedy měli dělat? Jedno­duš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 pracu­jeme a ignoru­jeme ten kód, kde ne. Dosta­neme 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 softwa­rový 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ách­nout a opako­vat. S každou novou featurou vyčis­tíme kód, který je pro ni potřeba. Inves­tu­jeme o trochu víc času, než kdyby­chom pokrač­o­vali 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ásle­dují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 postup­ného refak­to­rování hned. Pokud bychom bývali čekali na velkou várku refak­to­rová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í