[Java J2EE] Onderhoud vs herbouw

[Verwijderd]

Mijn werkgever heeft een erg complex stuk software uit 2003, welke ik moet gaan onderhouden. Al snel was het duidelijk: de software was onnodig complex en gebouwd bovenop buzz-words: een factory bleek het builder-pattern te implementeren en een willekeurige bean was uitgegroeid tot een enorme factory, etc.
Verder zaten er zoveel abstractie lagen in, dat je echt de weg kwijt raakt (tussen de aanroep en de eerste echte functies zitten 5 a 7 classes die niets doen, behalve logica ondermijnen).
Een DAO-laag ontbreekt, die kan prima in de verschillende files ingebouwd worden (lekker bij elkaar). De dependency is een nachtmerrie; updaten naar nieuwe versies van externe libraries is niet mogelijk zonder elke source-file aan te passen. Het mooiste is dat het werkt, behalve dat niemand meer weet hoe het werkt; ook de opdrachtgever niet. Een uitdaging.

Vandaag vroeg ik mijn manager dus maar: "Vraag je me nu super-monteur van een Lada te worden?". Na een korte discussie, kwam het er uit: ja. Ik moet me niet laten verleiden om de code te repareren, want stel je voor dat je het kapot maakt... Het feit blijft dat er fouten in het model zitten, die nu onontdekt zullen blijven. Ik wil dus heel graag stukje voor stukje de software updaten naar een moderner stuk software (IoC enzo), minder code, duidelijke scheiding tussen model, data en context.

Dus in het kort het probleem: de code doet wat ie moet doen, maar de controle en de onderhoudbaarheid zijn erg laag. Ik schaal de kwaliteit in op "laag twijfelachtig" (= kan nog wel een jaartje mee)

Wat zouden jullie doen? Hard maken voor verandering, of gewoon de pap nathouden?

[Kettrick]

Belangrijke reden voor mij zou zijn dat ik heb uberhaubt niet leuk zo vinden om aan dergelijke meuk te werken . Daarnaast is dergelijke software vaak erg riskant, zolang het werkt werkt het, maar wat als er serieus problemen optreden, kan je het dan fixen ?

Ik zou me in dit geval serieus hardmaken voor verbetering

[winkbrace]

Normaal gesproken krijg je nooit budget voor herbouw totdat het goed mis gaat.

Als ik je post lees, lijkt het me dat jouw voorkeur is om de boel te herbouwen. Ik lees er ook in dat het je niet gaat lukken in je eentje naast het behandelen van issues. Of wel?

Dus als ik jou was zou ik de boel eens lekker laten omvallen na een klein business verzoek en/of je zaak escaleren

[RobIII]

Verwijderd schreef op maandag 13 oktober 2008 @ 22:17:
Wat zouden jullie doen? Hard maken voor verandering, of gewoon de pap nathouden?

Het hoeft ook niet zwart-wit he? Ok, het is k*t, maar het hoort gewoon een beetje bij het vak dat je soms andermans puinhoop mag ruimen. Als je daar niet tegen kunt zit je in de ICT heel erg verkeerd want als het ergens ... nou ja, you get my drift
Ik denk dat de mooiste oplossing gewoon de gulden middenweg is; even doormodderen met het huidige systeem en de nodige verbouwingen uitvoeren wanneer nodig, maar wel niet meer dan het hoognodige en ondertussen een nieuwe versie er langs gaan bouwen en tot die (een heel eind) klaar is dus doormodderen met "V1". Maar dat moet wel ook in je planning passen en überhaupt tot je taken behoren en dient sowieso in overleg te gaan met je leidinggevende. Maar dat snap je zelf natuurlijk ook wel Shit happens, live with it.

[Orphix]

Een complete rewrite is in veel gevallen veel te kostbaar en, rara hoe kan dat, blijkt de rewrite toch niet altijd de beoogde elegantie, functionaliteit en performance te hebben. Als de software werkt en nauwelijks hoeft te worden aangepast->lekker zo laten. Als de software met regelmaat wordt aangepast zou ik voor elke wijziging er de driedubbele tijd voor uittrekken dan geschat en beetje bij beetje gaan refactoren.

En wat hierboven wordt gezegd: een crisis is de beste mogelijkheid om veranderingen door te voeren. Maar om nou de crisis zelf op te wekken...

[matthijsln]

Tja, in mijn werk kom ik dit soort dingen ook regelmatig tegen; alleen dan in wat andere vorm zoals enorm slechte datamodellen (ik kom echt bijna nooit foreign keys tegen, hoe moeilijk kan dat toch zijn...), crappy code en overcomplexe zooi.

Wat je eraan kan doen hangt af van wat mogelijk is qua tijd en budget. Een enkele keer heb ik een applicatie helemaal vanaf de grond opgebouwd vanaf php naar java j2se met een db conversie. Een andere keer heb ik stukje bij beetje gedeeltes gerefactored en de tijd die dat kost ingecalculeerd bij de gewenste wijzigingen (je krijgt er wel een frankenstein applicatie van). Soms ontkom je er niet aan om in de bestaande warboel iets te fixen.

Als je resources als infinite stelt zou je uit technisch oogpunt altijd voor een build-from-scratch kiezen als je zooi die jij beschrijft tegenkomt. Ik zou dit vooral technisch onderbouwen en motiveren bij je omgeving. Als er dan toch voor wordt gekozen voor onderhouden of gedeeltelijk refactoren heb je de risico's/problemen duidelijk gemaakt.

Vervelend zijn dit soort projecten wel, vooral omdat je voornamelijk bezig bent met andermans' troep opruimen. Ik denk dat velen dit gevoel wel kennen. Helaas moet je soms nou eenmaal!

Misschien nog een goede tip is om er een mooie submit naar www.thedailywtf.com van te maken en daarnaast veel op de originele programmeur te schelden! Dat lucht toch elke keer weer op

[Verwijderd]

Bedankt voor jullie reacties!
We zijn tot een compromis gekomen. Gelukkig was de reactie een soort test om mij goed aan het denken te zetten en niet een starre houding.
De komende tijd ga ik proberen zo veel mogelijk de requirements op papier zetten aan de hand van de code en de aanwezige documentatie; hier komt een uitslag vasn waar de requirements te vaag zijn of gewoonweg niet overeenkomen met wat ooit de bedoeling was. Daarna gaan we een analyse doen waar de meeste veranderingen zullen komen en waar de meeste problemen zijn bij operations. De uitkomst van dit alles zal een start zijn welk gedeelte vervangen gaat worden; iig komt er een splitsing van het programma, zodat ook een andere programmeur zonder mijn tussenkomst verbeteringen kan aanbrengen aan de frontend.