Starý software podle nových pravidel

Konečně jsem se zase po dlouhé době odhodlal k přečtení nějaké knihy. Bohužel nejsem velký čtenář a tak se zmůžu jen na technickou literaturu – Robert C. Martin, Čistý kód. Slyšel jsem o této knize z mnoha stran a všichni (programátoři) říkali, jak je dobrá. Měli pravdu. Knihu ale nelze považovat za nějaké dogma, nicméně obsahuje velkou spoustu myšlenek a rad, kterými by se měli řídit nejen programátoři.

Hned v úvodní kapitole se mi líbí přesný příklad toho, co znám z vlastní zkušenosti. Tato část je dobrá i pro manažery a vedoucí vývojářských týmů.

Bylo, nebylo

Vyvíjíme software, ten netestujeme, protože na to není čas, všechno se řeší velmi rychle a ono to funguje, občas nějaká ta chyba, tak se to hledá a opravuje, někdy poměrně dlouho. Software se s novými požadavky  postupně zvětšuje, až se stane neudržovatelným. Tzn. bojíme se opravovat a vylepšovat existující kód, protože nevíme, co ta změna udělá a proklikat celý systém je nereálné a nikdo nám to nezaplatí.

Takže se zrodí myšlenka o novém systému a ten se začne vyvíjet. Musí se stále udržovat ten starý, protože musíme něco prodávat a z něčeho žít, je na to všechno potřeba víc lidí, vývoj nového stojí hodně času (peněz), protože se chce vyrovnat tomu starému, který má v sobě několik let programování.

Celé to může skončit třeba tak, že se ten nový systém nedokončí a používá se stále ten starý, neudržovatelný, napsaný starým způsobem, který se těžko inovuje. Může to skončit i tak, že nový sice existuje, ale převedení dat ze starého systému do nového zákazník nikdy nezaplatí a my to zadarmo dělat nebudeme.

Programátory práce na starém systému nebaví, protože je otravná a zdlouhavá, stejně tak to nemusí bavit ani obchodníky, protože veškerá nová funkcionalita má vysoké odhady a taková práce se těžko prodává.

Pokud by snad tento článek četl někdo z neprogramátorských kruhů, tak bych to přirovnal ke stavění starého dřevěného domečku, který má na začátku malá okna a malé dveře, protože tak se to dřív dělalo. Postupně se na domeček přistavovalo něco do výšky, ale ten domeček už to téměř neunesl. Veškeré opravy v domečku se museli dělat ručně, protože stroje jsou příliš velké a neprojedou dveřmi. Na zvětšení dveří si nikdo netroufne, protože by celý domek mohl spadnout. Správce domu tak dělá všechny opravy a ručně a je naštvaný, protože mu to jde pomalu a soused, který stavěl o 10 let později už má široké dveře a může používat stroje, které mu práci zjednodušují. Majitel domu je taky naštvaný, protože kdyby byla údržba jednodušší a opravy rychlejší, tak by už dávno mohl pronajímat ten domeček turistům. Nakonec i stavění nového domu občas může skončit podobně jako vývoj nového software paralelně s udržováním toho starého. Prostě se dům nedostaví a bydlí  se dál ve starém, protože .na ten nový nejsou peníze.

Znám různé typy programátorů

• Někteří programátoři věci naprogramují, aby to nějak fungovalo, shrábnou na začátku možná víc peněz za pochybnou práci a když se to pak bude upravovat, tak se to přeci vždycky nějak udělá. Tito lidé to ale nemusí dělat proto, že by to chtěli odfláknout. Můžou to být lidé, kteří nemají dostatečné znalosti, zkušenosti a nadhled. Ale můžou to dělat taky proto, protože na to nemají vytvořené  prostředí, ve kterém by mohli pracovat lépe.
• Někteří vývojáři to dělají pořádně včetně testů a promyšlených návrhů, samotná funkcionalita jim možná neroste tak rychle, ale na konci mají dílo, pod které se nebojí podepsat a když dojde na úpravy/opravy, tak se nebudou bát, protože mají testy a promyšlenou architekturu, která s rozšířením a se změnami počítá.

Věřím tomu, že při vytváření nových aplikací to obě skupiny baví, ovšem když přijde na opravy a vylepšení, tak to ty „flákače“ začne pěkně otravovat. Jejich práce se stává nekonečnou, protože by po úpravách měli proklikat celou aplikaci ve všech možných kombinacích, což samozřejmě neudělají, protože programátor je člověk líný a navíc mu to zase nikdo nezaplatí. A tak dostává zákazník produkt, který snad bude funkční.