Digital Customer Experience Blog

Digital Customer Experience Blog

Meningen op deze blog weerspiegelen de opvattingen van de schrijver en niet per definitie die van de Capgemini Group

Je code stinkt

Als programmeur ken je het wel; je begint aan een project en jouw taak is het opzetten van een eerste framework waar de rest van het project op gebouwd gaat worden. Je hebt er zin in en vol goede moed bouw je een prachtige architectuur waar alle componenten in harmonie met elkaar samenwerken. Alle componenten hebben een afgebakend stukje verantwoordelijkheid, er zijn geen componenten die dezelfde taak doen en de code ziet uit als een prachtig gedicht wat zelfs je oma nog kan begrijpen; "It just makes sense". Je leunt achterover, neemt een slok van je slechte automaten-koffie en je bent erg tevreden met jezelf. Life is good.
 

En toen ging het mis

Een aantal maanden zijn voorbij, en het project is in volle gang; er werkt een team van developers aan het project en uit alle hoeken komen nieuwe requirements aangevlogen. Je denkt bij jezelf, "geen probleem, er ligt een goede basisarchitectuur waar iedereen op verder kan bouwen".  Daar kan niks misgaan, toch? Nog een aantal maanden verder besluit je eens een kijkje te nemen naar het framework wat je met zoveel zorg hebt ontworpen en ziet dat het een totale puinzooi is geworden; componenten zijn op een verkeerde manier gebruikt en aangepast, overal  is 'jouw code' veranderd en heel de boel is een onhoudbare zooi geworden. Life: not so good anymore!

Te laat!

Waarschijnlijk klinkt dit verhaal veel mensen bekend in de oren. In veel gevallen, vooral in gedistribueerde teams, kom je vervuiling van je code-base pas in een latere fase van het project tegen en vaak is het dan al te laat. In de meeste gevallen is het erg lastig om de code achteraf op te schonen. Sowieso gaat dit erg veel tijd kosten. En probeer dat maar eens te verkopen aan je klant. De applicatie werkt immers volgens specificatie en hoe de code uit ziet is voor de klant vaak geen reden om een complexe herstructurering te betalen.

Advies: neem het op in je proces

Voorkomen is in dit geval dus beter dan genezen. Er zijn een aantal goede gereedschappen om zulke scenario’s vroegtijdig te ontdekken en de kop in te drukken. Regelmatige code reviews zijn erg nuttig en worden vaak vergeten; de reviews houden jezelf scherp en wijzen je op mogelijke 'slechte' code of redeneringen, maar een ander bijkomend voordeel is dat andere mensen kunnen leren van jouw code en vice versa. Aan alle scrum masters: neem code reviews op in je ‘definition-of-done’.

Er zijn ook een aantal goede software tools die bij elke compilatie de code checken of die nog voldoet aan standaarden en ‘best practices’. Als je dit opneemt in je ontwikkelproces ben je verzekerd tegen het langzaam afglijden van je code kwaliteit.
 

Herken jij jezelf in bovenstaand scenario en hoe heeft jouw team dit opgelost? Laat het ons weten in de comments.

Over de auteur

Timo Leenen
Timo Leenen

Plaats een reactie

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *.