Kiezen voor kwaliteit

Waarom heeft je auto eens in de zoveel tijd een APK-keuring nodig en je applicatie niet? Met de jAPK brengen we daar verandering in. De jAPK is een hulpmiddel om de kwaliteit van Java-applicaties in kaart te brengen. We hebben de jAPK al een paar jaar in gebruik bij het Kadaster en Ordina, maar vanaf nu is hij er voor iedereen!

Aan de hand van een checklist met veel voorkomende potentiële problemen kun je de kwaliteit van je applicatie inventariseren. Door potentiële problemen tijdig te signaleren kan het team ze in het normale ontwikkelproces oplossen in plaats van dat je er in productie tegenaan loopt, als het al te laat is.

Kwaliteit is een vaag begrip, je kunt het op heel veel verschillende manieren interpreteren. Sommige mensen bedoelen daar eigenlijk mee dat ze vinden dat ontwikkelaars hun werk niet goed doen, maar kwaliteit is helemaal geen stok om ontwikkelaars mee te slaan! Kwaliteit van een applicatie omvat ‘alles’ van en rondom die applicatie. Een kwaliteitsanalyse van een applicatie richt zich dus niet alleen op de code, maar ook op het volledige ontwikkelproces, op operationele beheersbaarheid en op bruikbaarheid. De jAPK benadert de kwaliteit van applicaties vanuit zoveel mogelijk relevante invalshoeken. Met de jAPK kun je de zwakste schakels van je applicatie signaleren en verbeteringen motiveren.

 

 

Geschiedenis

We hebben de jAPK een jaar of vier geleden bij het Kadaster ontwikkeld. Daar hebben we tientallen applicaties die door de tijd heen allemaal zo hun eigen weg gaan. Om met een beperkt aantal mensen deze applicaties te kunnen beheren, hebben we onze ‘ontwikkelstraat’ gemaakt. Dit is een set van richtlijnen waar de applicaties zich (min of meer) aan houden. De jAPK beschrijft de afwijkingen van een applicatie ten opzichte van de ontwikkelstraat.

Bij Ordina hebben we de Kadaster-specifieke zaken aangepast aan wat er volgens ons zoal in de markt speelt. Daarbij hebben we gezocht naar een balans tussen een aantal verschillende factoren: het belangrijkste doel van de jAPK is om de kwaliteit van applicaties bespreekbaar te maken. Daarnaast mag het uitvoeren van de jAPK niet al te veel tijd kosten, anders wordt hij niet uitgevoerd. Tegelijk is deze controle zo compleet dat de uitkomsten duidelijk aangeven op welke vlakken je de applicatie het beste kunt verbeteren. Deze gegeneraliseerde jAPK vormt een solide basis voor kwaliteitsanalyses bij diverse opdrachtgevers.

 

Gebruik

Met de jAPK analyseer je de kwaliteit van je applicatie aan de hand van een checklist. Je mag de tekst van de checklist items vrij interpreteren, maar we geven ook een toelichting die beschrijft wat we met de checklist items bedoelen. Dit helpt je om te zien wat er rondom het item speelt, welke risico's erachter verscholen liggen, hoe je dit kunt detecteren, doorgronden en verwoorden naar andere (mogelijk minder technisch onderbouwde) collega’s.

Het uitvoeren van de jAPK is een handmatig proces. De checklist en de toelichting geven je zoveel mogelijk hints waar je naar kunt kijken. Bij het uitvoeren van de jAPK helpen geautomatiseerde code-analyse tools je om te bepalen op welke delen van de code je wilt inzoomen, maar uiteindelijk zal je de potentiële problemen toch echt met de hand moeten uitpluizen. Sorry hiervoor J.

De ervaring leert dat het goed is om de jAPK jaarlijks en bij grote veranderingen uit te voeren. Als je een applicatie door en door kent, duurt het uitvoeren van de jAPK, afhankelijk van de grootte van je systeem, een halve dag tot twee dagen. Als je nog geen kennis van de applicatie hebt, kun je de jAPK óók uitvoeren. Dan duurt het invullen langer, maar raak je wel meteen snel ingewerkt.

De jAPK is geen afrekentool voor het management, maar een richtingaanwijzer voor structurele verbeterpunten. Wees daarom bij het invullen zo eerlijk mogelijk. Als er een stuk code in zit waar je niet aan durft te komen, beschrijf het. Als bepaalde onderdelen juist heel goed zijn, benoem dat dan ook. Deze kennis helpt het team om risico’s in kaart te brengen en prioriteiten te bepalen.

De exacte inhoud van de jAPK is niet in beton gegoten. Als team kun je de checklist aanpassen aan wat jullie belangrijk vinden. Als je organisatie er bijvoorbeeld naar streeft om alle applicaties op één platform te gaan draaien, dan heb je een prima extra checklist item. Of in de code. Vindt het team het belangrijk dat alle interfaces met een I beginnen, hebben jullie er een goede motivatie voor en consensus over, zet hem er vooral ook bij.

 

 

Hands-on

De jAPK bevat een lijst met ongeveer 50 checklist items. Om de lijst beheersbaar te houden, hebben we de items ingedeeld in zeven verschillende categorieën. De categorieën zijn: Architectuur, documentatie, metrics, code review, beveiliging, achterstallig onderhoud en tooling en infrastructuur.

Als je de lijst invult, geef je in het veld 'Score' met de kleuren van het stoplicht aan of dit onderdeel al dan niet in orde is: Een groen vinkje, oranje uitroepteken of rood kruis. Wat je niet weet (hopelijk zo min mogelijk) krijgt een geel vraagteken. In de kolom ‘opmerking’ kun je de score nog verder onderbouwen. Interpreteer de steekwoorden vooral vrij, dit is slechts een kapstok.

Bovenaan de checklist staat een managementsamenvatting. Nadat je de checklist volledig hebt ingevuld, kun je hier een overkoepelend oordeel geven. Ook hier heb je de stoplichtsymbolen en ruimte voor een korte toelichting. Dat geeft de lezers in één oogopslag een indruk van de kwaliteit van de applicatie, zonder dat ze de volledige checklist door hoeven te lopen.

Onder 'Code review' staan bijvoorbeeld de volgende checklist items:

Een voorbeeld van hoe we in de toelichting dieper ingaan op de checklist items:

'healthCheck'-functionaliteit

Beschrijving

Bij iedere applicatie willen er op een gegeven moment mensen weten of hij goed geïnstalleerd is. Soms gebeurt dit door (een deel van) de functionele flow te doorlopen, maar een applicatie kan hier ook een aparte pagina voor hebben. Kijk of zo’n soort pagina bestaat. Typische voorbeelden van wat je op deze pagina zou verwachten:

• Als de applicatie met het filesysteem werkt: kijk of het pad bestaat;
• Als de applicatie een database gebruikt: voer een dummy query uit;
• Als er een achterliggende webservice wordt aangeroepen: roep de service aan;
• Als er een JMS-queue gebruikt wordt, probeer de queue te browsen.

Kijk of deze pagina compleet is en of alle componenten waar je afhankelijk van bent gecontroleerd worden.

Waarom

Na installatie en bij onverwachte fouten is deze pagina een eerste check van de infrastructuur. Deze controle kan door operationeel beheerders worden uitgevoerd. Zolang deze pagina fouten geeft, hoef je als ontwikkelaar niet uit je bed gebeld te worden.

Tips en hulpmiddelen

Het DropWizard Metrics-project bevat HealthChecks. Deze library kun je gebruiken of je er door laten inspireren. De rest van het Metrics-project biedt trouwens run-time monitoringfunctionaliteit. Dit is zeker het overwegen waard om in je applicatie op te nemen.

Overwegingen

Let bij het bouwen van deze controlepagina op de volgende punten:

• Ga niet uit van specifieke data in een database of achterliggende service, die kan van omgeving tot omgeving variëren;
• Laat de controles niets veranderen. Gebruik alleen controles die geen effect hebben (leesacties);
• Een service aanroepen met ongeldige data en een specifieke foutmelding terugkrijgen is een prima manier om te controleren of de service benaderbaar is.

Deze controlepagina is niet een uitputtend middel voor infrastructuurmonitoring. Het gaat om een eerste en gemakkelijke check. Als de pagina bijvoorbeeld controleert of een directory bestaat, weet je nog niet of er genoeg ruimte is op het filesysteem en of je wel schrijfrechten hebt.

 

 

Weerstand

Ondanks dat vrijwel iedereen voorstander is (of zegt te zijn) van goede kwaliteit, komen we nogal eens weerstand tegen rondom de jAPK. De weerstand komt vaak vanuit de volgende hoeken:

A) Vanuit functionele hoek, omdat in het verleden de techniek ‘het gewoon deed’. Door de extra aandacht voor de techniek worden er ineens dingen gedaan die ‘geen functionele waarde toevoegen’.

Het helpt meestal wanneer je uitlegt dat een kwalitatief goede applicatie beter is aan te passen aan functionele veranderingen en nieuwe wensen. Daarnaast werden die dingen die ‘geen functionele waarde toevoegen’ zonder de jAPK simpelweg verrekend in hogere tijdsschattingen. De jAPK maakt de kwaliteitsissues alleen zichtbaarder en helpt mee om de risico’s te verwoorden. Daardoor worden kwaliteitsverbeteringen dus beter in te plannen.

B) Vanuit projectleiders, omdat er geen tijd of budget is. Dit heeft meestal te maken met de korte termijn scope van projectleiders. Zeker wanneer de jAPK aan het eind van het ontwikkeltraject ineens tevoorschijn komt, blijken projectleiders erg goed in het weg managen van dit soort pijnpuntjes.

Wanneer de jAPK al vroeg in het project (en daarna af en toe) wordt uitgevoerd, is kwaliteitsbesef gewoon deel van je werk. Kwaliteitsissues zijn vaak ontstaan door veranderende omstandigheden en soms simpelweg door een fout, zelfs ontwikkelaars lijken af en toe net mensen. Tijdige reflectie helpt als vangnet tegen latere onverwachte verrassingen, iedere zichzelf respecterende projectleider zou dat juist moeten willen. (zie ook TDD, waar refactoring een essentieel onderdeel is van het proces; of de Retrospective in Scrum)

C) Vanuit ontwikkelaars, want ook zij zijn nog niet allemaal gewend aan dit soort transparantie. Sommigen zien fouten in de code als een persoonlijke nederlaag en proberen ze daarom te verbergen, te bagatelliseren of op te lossen zonder dat iemand het in de gaten heeft.
Als je dat doet neem je, vaak zonder het te beseffen, een te grote verantwoordelijkheid op je nek. Onzichtbare issues zijn niet alleen jouw probleem, ze zijn niet te plannen en vormen daarmee een risico voor het project. Door de zwakke punten zichtbaar te maken, kan het team kijken naar oplossingen of kunnen de gevolgen (tijdelijk) worden geaccepteerd. In ieder geval wordt het een gedeelde verantwoordelijkheid van het team, in plaats van dat je het in je eentje moet dragen.

 

 

Olievlek

Sommigen willen, enthousiast geworden door de eerste resultaten, weten of je jAPK kunt toepassen in een andere context. Dat hangt sterk van de context af:

• Bij andere JVM-talen, zoals Groovy, Scala en Clojure is de vertaling relatief eenvoudig te maken. Vaak volstaat de huidige checklist, met hier en daar een extra taal specifieke opmerking.
• Voor Javascript geldt dat deels ook, hoewel je de jAPK hier iets meer voor aan moet passen. Die wereld is op dit moment zo hard in ontwikkeling dat het volgens ons nog wat vroeg is om standaarden en best practices als checklist items vast te leggen. Misschien werkt een Javascript-APK goed bij organisaties die één ontwikkelplatform hebben met daarbinnen een groot aantal verschillende Javascript-applicaties, maar daar hebben wij nog geen ervaring mee.
• Bij andere talen en platformen, zoals PL/SQL, VB, C++ en SAP moet niet alleen een technische vertaalslag gemaakt worden. Vaak is een verandering in de mindset van de ontwikkelaars veel belangrijker. Al jaren vraag ik DBA's naar de test coverage van hun code en vrijwel altijd krijg ik ontwijkende antwoorden. Zolang de initiatieven op dat niveau al ontbreken, zal een structurele kwaliteitsanalyse ook weinig effect hebben.

 

 

Work in progress

De jAPK is een afspiegeling van wat zich op dit moment afspeelt in de markt. Daardoor zal dit kwaliteitscontrolesysteem blijven veranderen. Daarnaast is de tekst nog niet af: nog niet alle punten hebben een begeleidende toelichting. Dat neemt niet weg dat de jAPK in zijn huidige vorm prima te gebruiken is. Omdat de markt veel groter is dan wij kunnen overzien, is jouw input van harte welkom. Mis je cruciale punten of heb je extra tips die iets toevoegen aan een toelichting, laat het ons dan vooral weten! Zelfs als je alleen wilt consumeren zonder bij te dragen, resteert nog maar één optie: git clone https://github.com/J-Technologies/jAPK

Succes met invullen!