arrow-left arrow-right brightness-2 chevron-left chevron-right circle-half-full facebook-box facebook loader magnify menu-down rss-box star twitter-box twitter white-balance-sunny window-close
"goeie code" een mythe ?
2 min read

"goeie code" een mythe ?

Deze post gaat over een leuk dilemma in het ontwikkelen van projecten, meer bepaald het schrijven van code. Iedereen die al eens geprogrammeerd heeft aan een groter project (neen ik heb het niet over de myspace pagina van jouw neefje’s reggae band) kent het dilemma “goeie code” vs “snelle code”. Bij elk groter project komt er een bepaald moment waar je moet kiezen : de snelle (& dirty) oplossing of tijd investeren in de perfecte code ? Er zijn zeer weinig projecten waar de duurzame oplossing, maar vaak komt het hierop neer “if it works, it works”, niets is minder waar.

Elke die-hard developer weet dat de wereld beter zou worden van “goeie code”. Applicaties (in mijn geval web applicaties) zouden niet alleen doen wat ze horen te doen, ze zouden ook nog eens sneller zijn ! Het project process zou vlotter verlopen, en het eindresultaat zou voldoen aan alle eisen vooropgesteld in de analyse, right ? Spijtig genoeg is de realiteit anders.

Het eindresultaat is niet altijd afhankelijk van tijd/resources, er zijn ook andere factoren.

Ik heb in het verleden al aan tal van internet applicaties gewerkt, en altijd had ik de beste intenties voor de realisatie van het project. Altijd ! Beginnend met de analyse, alle actoren en processen zo goed mogelijk in kaart brengen en begrijpen hoe al die zaken uiteindelijk moeten samenwerken. Het resultaat was (meestal) duidelijke en gedocumenteerde code die gestructureerd, onderhoudbaar, leesbaar en uitbereidbaar was…tenminste toch tot de klant zich besloot te “moeien” :-)

Indien je al aan grotere projecten gewerkt hebt ken je zeker deze regel : “klanten weten nooit wat ze willen”. Zelfs als ze beweren van wel. Na het tonen van de eerste demo zijn ze verbaast en enthousiast zodat ze onmiddelijk idee’en beginnen te opperen om de applicatie “nog beter” en “nog cooler” te maken. Nu dit is niet echt een probleem zolang je de klant onder controle hebt (analyse document, project specificaties), maar dit niet het geval is : “let the bad code in” ! :-)

Op 90% van de reeds gerealiseerde projecten kwam er een moment waarop we keuzes moesten maken. Mogelijk kan er uit de eerste demo maar één voorstel van functionaliteit komen wat de klant geintegreerd wil zien. De kans is groot dat net deze functionaliteit zal botsen met alles wat je daarvoor al hebt geschreven. Daarom is het extreem moeilijk om “goeie code” te behouden. Het vereist oefening, ervaring en skill om dingen te schrijven die flexibel genoeg zijn om te voorzien aan de toenemende eisen van de klant.