Geplaatst op 13 November 2009, 00:26 door László van den Hoek in java, testing, nljug

Een 5-sterren project, wat is het en hoe kan ik het bereiken?

Ik associeer het predicaat "5 sterren" met de hoogste kwaliteit, en ook wel met decadente luxe. Voor allebei is hier wel wat te zeggen.


In de eerste sessie na de lunch (lastig timeslot!) vertelde Eric Bouwers van Software Improvement Group (SIG) over de nieuwe certificering die het bedrijf aanbiedt, in samenwerking met het Duitse TÜViT. Een groot deel van het publiek moet in de veronderstelling hebben verkeerd dat het een breed verhaal zou worden, vol gouden projectmanagement-tips die (mits vanaf het begin gevolgd) een goede afloop van elk project zouden garanderen. De zaal zat immers, tot blijde verrassing van de spreker, bomvol - waarschijnlijk met late beslissers die zich enkel door de titel lieten verleiden. Want wie wil er nu geen vijf sterren? Luxe kent zijn prijs, en in deze tijden van onder druk staande tarieven is elke manier om je te onderscheiden welkom.


Het gaat wat ver om te zeggen dat deze vluchtige koppensnellers bedrogen uitkwamen, maar het verhaal had in ieder geval een duidelijke focus: onderhoudbaarheid van code. SIG bepaalt met hun (niet-publieke) tools een aantal code metrics, en stelt aan de hand hiervan een rapport op. Dit rapport gaat naar TÜViT, die een certificaat opstellen. Dit certificaat dekt het onderhoudbaarheidsaspect van de ISO-9126 standaard, die een aantal kwaliteiten van code definieert, zoals betrouwbaarheid, efficiëntie, usability en dergelijke. Onderhoudbaarheid is op zijn beurt weer onder te verdelen in analyseerbaarheid, veranderbaarheid, stabiliteit en testbaarheid, en de mate waarin de code deze eigenschappen beïnvloedt bepaalt het aantal sterren dat per onderdeel verdiend wordt. Waar een toprestaurant zich in de handjes mag knijpen met één ster, ligt de lat hier wat hoger: met een gemiddelde van minder dan 3 sterren ga je zonder certificaat naar huis, en op elk afzonderlijk onderdeel dienen ook minstens 2 sterren gescoord te worden. De grenswaarden voor de sterren worden bepaald met benchmarking: De top 5% van de applicaties krijgt 5 sterren, de bottom 5% ééntje; de overige 90% wordt geleidelijk verdeeld over de resterende 3 tussenliggende scores.


De code metrics waar naar gekeken wordt zijn modularisatie, complexiteit, unit-lengte, code-duplicatie, volume, fan-in, unit interaction, exception handling en unit test quality. Ter illustratie hiervan passeerden tijdens de sessie een paar bekende open-source-projecten de revue, waarbij werd ingegaan op de zwakke punten, en hoe die verbeterd zouden kunnen worden. Zo scoorde Checkstyle (eindoordeel: 4 sterren) slecht op het onderdeel "complexiteit". Deze wordt op functie-niveau bepaald en uitgedrukt met een McCabe-getal; hoe hoger het getal, hoe complexer de code, en hoe groter het risico dat de onderhoudsplegers niet meer begrijpen wat er gebeurt. Dit is te verhelpen door code te verplaatsen naar nieuwe methodes; de complexiteit per methode neemt daardoor af. Een ander voorbeeld: jMule (3*) had te lange methodes. Dit is een waardeoordeel; immers, wat is "te lang"? SIG gaat uit van 20 regels per functie. Hier zit wat mij betreft een pijnpuntje: SLoC is geen ideale metric. In het algemeen geldt dat less is more, maar zoals de aloude PERL-wijsheid gaat: alles kan in één regel. En of dat nu de onderhoudbaarheid ten goede komt... Deze beperking van de metric werd ook onderkend door de spreker: als code files meer dan 3x zo breed worden als ze hoog zijn, is het tijd voor een gesprek met het management.


Allemaal belangrijke aandachtspunten, maar code metrics alone do not a great project make. De kwaliteit en kwantiteit van projectdocumentatie zit expliciet niet in het model, hoewel het belang ervan wel erkend wordt. Ook het aanroepen van databases wordt niet in beschouwing genomen, maar er wordt onderzoek gedaan naar de mogelijkheden om dit in een toekomstige versie van de evaluatie op te nemen.


Tot dusver heeft een aantal grote bedrijven zich laten verleiden tot het certificeren van hun code: KLM, Rabobank, Kasbank, ProRail en Corus. Kennelijk liggen bij deze bedrijven de release managers wat strakker aangelijnd, en worden de ontwikkelaars minder onder druk gezet om (ten koste van kwaliteit) op tijd werkende code op te leveren. Ook hebben zij de grote reserves die je nodig hebt om te investeren in onderhoudbare code. Tachtig procent van de kosten van een softwareproduct mag dan besteed worden in de onderhoudsfase, maar dan moet je die fase wel eerst halen, voordat je bedrijf failliet gaat tijdens het zoveelste oponthoud door herarchitectering van het flagship product, die het nóg onderhoudbaarder moest maken.


Het was dan wel JFall, maar strikt genomen was het geen Java-praatje, omdat de tools van SIG in principe op iedere taal toepasbaar zijn. Toch gingen alle voorbeelden uit van Java. Zou dit er op kunnen wijzen dat onderhoudbaarheid van Java-code meer aandacht vergt dan bij andere talen? Of is onze community zich gewoon meer bewust van het feit dat bewust bezig zijn met onderhoudbaarheid geen overbodige luxe is? Hoe dan ook, het eerste 5-sterren-certificaat moet nog uitgedeeld worden. Wellicht kun je je kans grijpen tijdens de volgende Masters of Java wedstrijd die in januari zal worden aangegrepen om de inzendingen te beoordelen volgens het SIG-model. Het zal interessant zijn om te zien hoe de onderhoudbaarheid zich zal verhouden tot de quick-and-dirtiness die inherent is aan de grote tijdsdruk waaronder de oplossingen geleverd moeten worden.


Share this | 370 keer bekeken | 0 reacties