Java frameworks: "If it ain't broke, don't fix it"

Vind maar eens het beste tijdstip om te upgraden

Voor een goede Java ontwikkelaar is er, naast de kennis van de taal, ook de ervaring met de meest gebruikte frameworks nodig. Daarom houd ik van Java: als ontwikkelaar heb ik de vrijheid om te kiezen.

Een probleem kan meestal op verschillende manieren en met gebruik van diverse frameworks opgelost worden. Zal ik het zelf doen of zal ik gebruik maken van een overweldigend aanbod van bestaande frameworks? En welke consequenties heeft mijn keuze voor de applicatie? Een dilemma.




Auteur: Olga Maas



Olga is Application Specialist bij APG, hecht aan uitdaging, ontwikkeling en diversiteit. Specialist in JAVA. Motto: Anders kijken geeft andere oplossingen.



Programmeurs zijn lui en houden van gadgets

Waar komt eigenlijk deze overvloed aan frameworks vandaan?

Ik denk dat wij programmeurs voor het merendeel lui zijn, selectief lui. Daarom zijn we ook gaan programmeren - om de computers dingen te laten doen die wij zelf te saai vinden. Daarnaast vinden wij nieuwe gadgets leuk. En wat zou er leuker kunnen zijn dan ons werk door het gebruik van gadgets makkelijker te maken? Daarom introduceren we plugins, frameworks en buildtools en laten we die elkaars gegevens delen en vervolgens aan elkaar doorgeven. Bijvoorbeeld mijn huidige Eclipse is volgepropt met handige plugins zodat die langzamerhand op een cockpit begint te lijken: de enige reden waarom ik nog mijn IDE moet verlaten, is om een kopje koffie te halen.

Dat zou trouwens een idee voor een leuk hobbyproject kunnen zijn: Ik stel me het 'Koffieknopje' voor direct naast de "Debug" knop. Voor liefhebbers natuurlijk ook met een toetsenbordcombinatie uitvoerbaar. Eén Raspberry Pi op een Lego-robot zetten, de tweede op de koffieautomaat aansluiten, twee wifi ontvangers en voilà een nieuwe plugin is geboren! Hoe langer ik erover nadenk, hoe meer ik ervan overtuigd raak dat ik niet de enige ben die zich laat betoveren door de mogelijkheden om iets te versnellen. Ik denk dat deze gedachtegang de oorzaak zou kunnen zijn van de overvloed aan frameworks.

Die Qual der Wahl

Als er een nieuwe functionaliteit gevraagd wordt, onderzoeken we eerst of er al bestaande frameworks aanwezig zijn die wij kunnen gebruiken. Verder beoordelen wij of de tijdsbesparing opweegt tegen de afhankelijkheid die het introduceren van een nieuw framework met zich meebrengt. Elk nieuw framework vergroot de complexiteit van het systeem en vormt een extra risico in de lifecycle van een applicatie: een kleine, schijnbaar onschuldige verandering kan een domino-effect veroorzaken en voordat je je het goed realiseert, sta je midden in een bouwput...

De volgende vraag die naar voren komt is: Welk framework? Bij voorkeur één waar alle kinderziektes al uitgekristalliseerd zijn en waarvan regelmatig nieuwe releases verschijnen. Daarnaast is een brede inzet in de community voor ons belangrijk. Als wij tegen een specifiek probleem aanlopen, is iemand anders ons waarschijnlijk al voor en is er al een oplossing beschikbaar.

If it ain't broke, don't fix it

Als het framework eenmaal genesteld is in onze code, treedt het principe "If it ain't broke, don't fix it" in werking. Elke update betekent een mogelijkheid om nieuwe bugs in je applicatie te introduceren en het is frustrerend de code door te spitten om daarna te ontdekken dat de schuldige een nieuwe framework-versie is. Maar het strak vasthouden aan het bovengenoemde principe veroorzaakt vroeg of laat problemen door achterstallig onderhoud. Daarom zijn we soms inconsequent als we tegen een bug aanlopen die in een nieuwere versie gefixed is of als in die versie eindelijk de functionaliteit zit waarop wij wachten.

Een andere reden voor een upgrade, of zelfs een vervanging, kan ook gebrekkig support zijn: Dat is vaak een signaal dat de status 'end-of-life' nadert en 'riding a dead horse' is voor niemand prettig. Zonder deze upgrades kan het gebeuren dat het draaiend houden van wat ooit de modernste applicatie was, veel duurder wordt dan een nieuwe bouwen. Het blijft een van de onderbelichte capaciteiten van een Java-specialist om het geschiktste tijdstip voor een upgrade te vinden.