[Alg]Refactoring van slecht opgezette webapp

[bigbeng]

Ik wilde even iets tegen jullie aanhouden. Ik ben verantwoordelijk geworden voor een webapplicatie die m.i. slecht is ontworpen. De site is opgezet in JSP files, maar ik denk dat het probleem zich vrij makkelijk laat vertalen naar ASP.NET of php.

Oorspronkelijke situatie
ASP programmeur zet (als Proof of Concept) een JSP site in elkaar. Dit is gedaan omdat mijn bedrijf zich ook wilde gaan richten op Java/J2EE technologieën. Omdat de betreffende programmeur hands-on aan de slag is gegaan, is de gehele webapplicatie nu een verzameling van jsp pagina's geworden, zonder goed gebruik te maken van OO concepten. Bijna alle BL zit in de JSP pagina's, evenals aanroepen naar de database. Voor de goede orde, het gaat hier om ongeveer 200 jsp pagina's. Als database wordt er gebruik gemaakt van Oracle 8i. Voor inserts/updates/deletes wordt gebruik gemaakt van een package met stored procedures en ook van triggers voor data-integriteit. Deze worden ook door mijn bedrijf onderhouden. Er zit dus ook een deel van de BL in die package.

Situatie na refactoring stap 1
De belangrijkste jeuk die ik voelde was om de SQL code uit de JSP pagina's te halen. Helaas kon ik dat niet zomaar doen, omdat dit qua budget niet mogelijk was. Dus heb ik de volgende strategie gevolgd: Bij iedere aanpassing die in vervolgtrajecten moesten worden gedaan op bestaande jsp pagina's heb ik alle sql en gerelateerde code uit de JSP pagina's gehaald en in een class file gestopt. Voor het gemak zal ik deze DatabaseFunctions.java noemen. Het enige wat teruggegeven wordt aan de JSP pagina is een resultset.
Ik besef mij dat dit nog steeds geen goed gebruik is van OO concepten, maar op deze manier scheidt ik in elk geval BL en presentatie van elkaar.
Het voordeel van deze strategie is dat aanpassingen vrij eenvoudig te controleren zijn, omdat de aangepaste pagina's sowieso worden gecontroleerd tijdens de testfase. Tevens kosten de aanpassingen vrij weinig tijd, zodat budgetten niet in gevaar komen.

Hoe nu verder?
Inmiddels (na ruim 2 jaar) zijn alle jsp pagina's aangepast en bevatten ze dus geen SQL statements meer. Maar dan is de grote vraag natuurlijk, wat is de volgende stap in de refactoring? Mijn eerste gedachte zou zijn om methodes uit DatabaseFunctions te gaan groeperen en in eigen class files te stoppen en tegelijkertijd value-objects te definieren en via Collections te gaan teruggeven ipv ResultSets. Een andere mogelijkheid die ik zie is het splitsen van de BL en de databaseaanroepen. Maar hoe denken jullie hierover? Gegeven de situatie, wat zou jij doen?

Mijn bedoelingen met dit topic zijn vooral het achterhalen van refactoring strategieën. Wat ik dus niet wil horen is dat de basis van dit project niet goed is en dat ik die eerst opnieuw moet opzetten, dit is bekend, maar vanwege budget niet aan de orde. Zie het maar als een huis dat al gebouwd is, het aanpassen van de fundamenten is kostbaar en gezien de financiële situatie van onze klant echt niet mogelijk.

Verder kan ik inhoudelijk weinig over de applicatie zeggen, omdat het om een product gaat dat relatief uniek is op de markt.

[chris]

Ik weet dat je het niet wil horen, maar toch: het idee van refactoren is dat je geen nieuwe functionaliteit toevoegt. Je moet enkel de bestaande functionaliteit herbouwen. De kans is erg groot dat het mis gaat. Waarschijnlijk is het voor de klant op lange termijn goedkoper om eerst te gaan refactoren, zonder nieuwe functionaliteit toe te voegen, en dan later nieuwe functionaliteit toe te voegen. Het is serieus een goede investering voor de toekomst. Als de klant er echt mee verder wil is dit wel iets om over na te denken. Als de klant niet meer echt verder wil, dan had je dit topic waarschijnlijk niet geopend. Dus probeer toch heel duidelijk de voordelen van refactoren aan de klant/baas door te geven.

Verder, over het inhoudelijke refactoren: misschien is het een idee om O/R-mappers te gaan gebruiken? Dat zijn goed te onderhouden links tussen je objecten in java en je database. Ik heb er zelf nauwelijks ervaring mee in java, maar ik hoor wel veel over Hibernate. Dat zou misschien een grote stap voorwaarts kunnen zijn.

[bigbeng]

Ik ben met je eens dat het refactoren eigenlijk alleen dat zou moeten zijn. Sterker nog, refactoren tijdens het wijzigen van functionaliteit wordt over het algemeen sterk afgeraden, omdat je je wijzigingen niet meer van elkaar kunt onderscheiden. Je zegt dus zeker niet iets wat ik niet wil horen. Misschien is het maken van afspraken met de klant voor refactoring wel een mogelijkheid, mits het met kleine stappen per keer wordt uitgevoerd. De meeste vervolgtrajecten met deze klant lopen in de orde van 10.000 euro, we kunnen dan niet veel extra werk verrichten.
Misschien is het dan wel een idee om de klant te adviseren naast een aanpassing in deel A van de applicatie, ook wat refactoring in deel B van de applicatie te doen. Dat zou een mogelijkheid zijn. En dan dus geen refactoring van deel A maar wel van deel B. Ik neem dit zeker mee.

Maar wat zeker niet tot de mogelijkheden behoort is het doen van een refactoring traject op zichzelf. Helaas ben ik daar na 2+ jaar ervaring met deze klant wel achtergekomen.

En het gebruik van O/R mappers, da's een leuk idee voor als we een OO structuur hebben, maar daar zijn we nog wel even van verwijderd. Als stap 2 bepaald is en achter de rug komt dat misschien aan de orde.

[Verwijderd]

Persoonlijk zou ik het zaakje eerst overzetten naar een MVC applicatie. Je hebt nu de SQL statements eruit gehaald maar de BL zit nog verweven met je representatie. Ook OR mapping is leuk maar IMHO minder belangrijk dan een stricte scheiding van je View en Model.

[Michali]

Wat je heel goed kunt doen is van bepaalde acties in de JSP files transactie classes maken. Zo hoef je de transacties niet eens op een nette manier uit te voeren, maar koppel je het wel al op een redelijk snelle manier los van je JSP files. Je instantieert zo'n transactie instance dan vanuit zo'n JSP file met de nodige data en voert hem daarna uit.