Tipy na refaktorizace legacy kódu rubrika: Programování: PHP
7
onelook
Zdravím, dostal jsem se k jednomu (nejmenovanému) projektu v PHP. Rozsah jádra je asi 200000 řádek zdrojáku v PHP souborech (nezapočítávám vendor věci, assety apod.). Nikdo detailně neví, co to vlastně dělá. Je to z větší části psané spaghetti způsobem a za hojnéno používání různé magie ($$name, $self->$method(), eval(), extract(), $this->$var, callStatic, get, set, call apod. (velké stovky těchto výskytů), někde lineárně nestruktorovaně, někde produrálně, někde s použitím objektů (objektově by bylo příliš nadnesené). Menší část je již psaná slušně. DB obsahuje asi 500 tabulek a 4000 sloupců a je též ve velmi špatném stavu (nenormalizovaná, nedokumentovaná, bez integritních omezení, s nevhodnými typy, zavádějícími názvy sloupců apod.). Je to v principu webová aplikace - částečně s GUI, částečně poskytující nějaká API pro další interní systémy a částečně i externí (ty externí jsou už lépe dokumentované).
Nicméně to nějak funguje, stojí na tom (nejmenovaná) firma.
Otázka je, co s tím.
- Jedna možnost je do toho pokud možno nehrabat a dělat jen to nutné. To ale moc daleko nikam nevede. Je třeba tam provádět nějaké změny, přidávat nové funkce apod. A každý zásah je velmi obtížný a nejistý a nikdo se neodvažuje sáhnout zásadním způsobem do toho legacy kódu.
- Druhá možnost je zkoušet to postupně nějak refaktorovat, což je velmi obtížné. Nelze moc předvídat, co změna může obvlivnit, co to má dělat se zjišťuje reverzním inženýrstvím, ...
- Třetí možnost je to napsat znova vedle, ale nikdo neví, co to vlastně dělá nebo dělat má. Kód je v detailech jediná (a hrozná) dokumentace.
- ?
Máte s něčím podobným zkušenosti? Podle čeho jste se rozhodovali? Máte nějaké tipy na postupy, nástroje, ..., které pomůžou s pochopením, dokumentací stávajícího stavu nebo refaktorizací?
8
rmaslo
Pokud chtějí zachovat nějakou historii (jakože asi chtějí) tak bych se jako první vrhnul na data. Takže zmapovat (třeba do nějakých pomocných tabulek nebo do nástroje na kreslení relačních diagramů), co který sloupec vlastně znamená, co jsou primární data a co jenom nějaké cache a hlavně který sloupec je odkaz kam. Z těchto tabulek generovat dotazy, které budou kontrolovat referenční integritu a co bude odporovat je potřeba zjistit proč odporuje a opravit.
V okamžiku, kdy bude jasná struktura dat a tyto data budou vyčištěná už bude dost informací o tom jak se rozhodnout co dál:
- Celé přepsat znova, včetně změny struktury db, jednorázový převod dat (script na něj). Což je dost riziková operace v ten D, kdy se to dělá a nemám to rád.
- V principu nechat strukturu db a napsat nad ní nového klienta. Ti dva klienti mohou jet paralelně, takže převod bývá ve větším poklidu
- Upravovat a přepisovat klienta .... strašná práce.
Údajů je málo, nicméně vzhledem k tomu, že klientů je více (myslím ty API) to vidím nejspíš na variantu 2 tj. data opravit program přepsat.
Ale to jsou všechno jen dohady. Za čím si stojím je to, že ten problém je potřeba si (v hlavě) rozdělit na dva menší problémy "klient" a "data" a ke každému přistupovat zvlášť.
Pro zobrazení všech 9 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře