Problémy při přepisu aplikace na novou verzi

Rozhodli jste se přepsat starou verzi systému do nového? Buďte opatrní, může to být nebezpečnější, než tušíte! Prohlédněte si několik úskalí přepisování aplikace na novou verzi.

Článek původně vyšel na autorově blogu. Jiří Knesl pomáhá IT firmám k vyššímu zisku pomocí zvyšování kvality a produktivity vývojářů a IT managementu. Více se o něm dozvíte na www.knesl.com.

Špatným procesem se znovu dostanete ke špatnému výsledku

Důvody, proč potřebujete přepsat aplikaci, můžou být různé. Někdy proto, že musíte změnit technologii (např. celá firma migruje z JVM na .NET nebo naopak), proto, že se firma vydala natolik novým směrem, že stávající systém už vůbec neodpovídá potřebám (např. přerod z B2B do B2C), tím, že je systém morálně zastaralý (ještě pořád máte kusy zdrojáků v PHP4). Nebo jste taky mohli dojít k bastlu, a to proto, že váš vývojový proces je neudržitelný a automaticky k takovým výsledkům vede.

Špatným procesem vývoje se znovu dostanete k bastlu. Můžete začít se vším, co znáte a umíte, můžete použít nejmodernější jazyky, frameworky. Můžete psát testy. Pokud váš proces vede k vysokému technologickému dluhu, nakonec budete mít stejně špatný výsledek.

Jaké jsou rizikové faktory?

  • micromanagement; samá operativa, žádná strategie (flexibilita nerovná se operativa)
  • nedostatek času na refaktoring
  • nedostatek kompetencí (ať už v developementu nebo v product managementu)
  • špatná prioritizace
  • nedostatečný budget
  • není produktová vize (což souvisí s absencí strategie z prvního bodu)

Než se pustíte do přepisu, ujistěte se, že ničím z toho netrpíte, popřípadě problém vyřešte (nebo napište a něco vymyslíme).

Stará databázová struktura a nové potřeby

Málokterý podnik je ochoten přijít o dosud vytvořená data. Většinou spíš uchovává i ta data, na která nikdo nekouká. Mezi starou a novou strukturou můžou být zásadní rozdíly – zejména pokud dochází k výraznému posunu businessu, např. z B2B do B2C.

Na stole pak leží možnost dočasného souběžného provozu obou systémů, podpora obou variant, nebo ztráta dat (a třeba i souběžný život s tím, že někde data nejsou). Taková věc může výrazně ztížit procesy a firmu to může nemálo zdržovat.

V takovou chvíli je na místě udělat jen minimální transfer data, vygenerování excelové tabulky (nebo něčeho podobného) se seznamy dat, které je potřeba doplnit, a jednorázový náročný úkol doplnění. Je to jednorázová investice, která může hodně stát, ale jinak bude firma navždy zpomalována.

Stará workflow

Nový systém často bývá jednodušší. První release se často dělá v době, kdy ještě nejsou zreplikovány všechny vlastnosti starého (což je v naprostém pořádku a sám to doporučuji).

S tím se ale pojí ta věc, jak uživatelé udělají workflow, na která byli zvyklí. Mnohdy se může stát (mám zkušenost, že se to opravdu děje), že uživatelé budou nový systém špatně přijímat, byť je nový systém jednodušší a logičtější. Klasik by asi řekl: „Každá velká změna je k horšímu.“

Lidé si zvyknou, naučí se fungovat novým způsobem, dovedou dočasně obejít snížené možnosti, ale je nutné počítat s tím, že budou mít horší produktivitu. Ujistěte se, že i tak dovedete novou verzi software prodat.

Nepomeňte na staré klávesové zkratky, finty ve vyhledávání, ale třeba i staré URL. Nezapomeňte, že i v informačním systému, do kterého nemůže Google, můžou lidé chodit prostřednictvím záložek a rozbité URL jim rozbijou aplikaci. SEO mágové se mnou nebudou souhlasit, ale není podstatné, jestli máte url ve formátu /action/id, ?action=action&id=id nebo /54n984v9ar7g8s4, podstatné je, aby byla URL dál platná i v novém systému (a to i když změníte jazyk, takže můžete paradoxně routovat /post.php na aplikaci napsanou v Pythonu).

Tahle podmínka je zbytečná…

K častým průserům se dochází tehdy, když se navrhuje nová verze bez prostudování toho, jak funguje současná verze. Při přepisu se pak zapomene na spousty hraničních, ale důležitých případů.

Všechny úspěšné e-shopy, které jsem viděl, mají kód pro výpočet ceny na tisíce řádek (někdy i v 1 funkci). Žádný e-shop, který jsem poznal, nemá algoritmus výpočtu ceny někde zanesený. To je know-how, které nikde není vidět, je pouze ve zdrojácích. Když by se pak pokusil kdokoliv jen tak z hlavy celý výpočet postavit, obvykle se mu to nepodaří. Při přepisu jakéhokoliv systému doporučuji rozkrýt a dostat na papír alespoň ty věci, které jsou kritické pro fungování systému (což bude u e-shopu např. objednávkový proces, výpočet cen, práce se stavy skladů).

Používání technologií bez skutečné potřeby

Ve volném čase je naprosto v pořádku zkoušet si naprosto cokoliv. Taky usínám u Idrisu.

Pro stavbu aplikace, na které stojí firma, to chce ale pádný důvod, proč použít nějakou technologii. Mnohdy objemy dat nejsou tak velké, aby bylo potřeba Mongo. Mnohdy aplikace nedělá tolik I/O, aby uživila node.js. Tím neříkám, ať se nepoužívají nové věci, ale dejte si na jednu stranu má dáti a na druhou dal.

Před asi rokem a půl jsem přešel ve vývoji na Clojure (hlavně proto, že dělá některé věci, které jsem potřeboval, jako je vyšší výkon, dlouho běžící aplikace). A přesto některé zakázky dělám v PHP, pokud se to hodí víc. Někde mám Angular, ale někde mám i jQuery. I v roce 2014 na tom není nic špatného, pokud se to použije správně. Někde používám transpiler (LiveScript), někde mám čistý JavaScript atd.

Efekt 2. systému

Většina přepisů funguje tak, že druhá verze toho umí méně, ale je mnohem čistší a časem se funkčně dotáhne. Někdy se ale rozhodne firma jít do přepisu, který toho bude umět víc. To je dost nebezpečné. Jedna z věcí, kterou jsem se naučil, že se nesnažím vyvíjet za každou cenu znovupoužitelná řešení, abstrakce, „co kdyby“ apod. Místo toho vyvíjím konkrétní a minimalistické řešení, a pokud potřebuju něco jinak, tak daný kód zrefaktoruju.

Buďte u druhé verze opatrní s novými vlastnostmi. Samozřejmě nejsou tabu – ostatně nové vlastnosti budou nejspíš i důvod, proč systém přepisujete. Ale nepřestřelte, nesnažte se „zobecnit“ vše, tj. abyste místo svého e-shopu neprogramovali obecný e-shop pro všechny. Abyste místo konkrétního CMS nedělali CMS pro všechny.

Na závěr

Obecně, když mluvím se zákazníky, doporučuji spíš refaktorovat existující řešení, je-li to možné. Občase se ale stává, že je systém tak vzdálený kýženému výsledku, že je rychlejší napsat to znovu. Buďte ale opatrní, přepis je těžší, než se zdá.

Jiří Knesl se zabývá hlavně Scrumem a správným vývojem software (prevence chyb, vyšší produktivita).

Zatím nebyl přidán žádný komentář, buďte první!

Přidat komentář
Zdroj: https://www.zdrojak.cz/?p=13920