terug naar overzicht

12/08/16

Insight insight

Applicatieontwikkeling
Erwin de Rijk, VX Company

Erwin de Rijk

+31 6 46 90 95 76


12/08/16

Onderhoudbaarheid tip 2: Maak analyseerbaarheid en complexiteit zichtbaar

Dit is deel drie over het belang van onderhoudbaarheid van applicaties. In het eerste deel hebben we stilgestaan bij het belang van onderhoudbaarheid van applicaties. Hoe onderhoudbaarheid wordt omschreven en hoe technical debt de onderhoudhaarheid negatief beïnvloedt. Vorig week is het belang van een Agile ontwikkelaanpak de revue gepasseerd. In dit deel sta ik stil bij het kunnen inschatten van de hoeveelheid technical debt.

Waarschijnlijk hebben we allemaal ervaring met een moeilijk onderhoudbare applicatie. Een applicatie die in de loop der tijd is uitgebouwd, waar diverse developers aan hebben gewerkt en die schijnbaar steeds lastiger is aan te passen. In de volksmond u003cemu003elegacyu003c/emu003e genoemd. Enerzijds wordt de onderhoudbaarheid beïnvloed door het gehanteerde ontwikkelproces (zie u003ca class=u0022clru002du002dprimu0022 href=u0022https://vxcompany.com/2016/08/04/onderhoudbaarheid-tip-1-gebruik-agile-ontwikkelaanpak/u0022u003edeel 2u003c/au003e) en anderzijds direct door de kwaliteit van het product (de code) zelf. Een objectieve meting van deze kwaliteit is dan ook doorlopend noodzakelijk.

Complexiteit en analyseerbaarheid

De grootste tijd- en geldslurpers van het doorvoeren van wijzigingen in bestaande applicaties zijn het opsporen en corrigeren van defecte code regels. Dit wordt vooral bepaald door de complexiteit en daarmee analyseerbaarheid van de code. Kan er snel worden bepaald waar de aanpassing moet worden doorgevoerd en of er ongewenste u003cemu003esideu003cstrongu003e u003c/strongu003eeffectsu003c/emu003e zijn? Het is dan van belang oog te hebben voor de complexiteit van de code tijdens ontwikkeling. Dit kan zowel handmatig (review of audit) als geautomatiseerd met statische code analyse.rnu003ch2 class=u0022fs-xxlu0022u003eu003c/h2u003e

Handmatige reviews

Door regelmatig reviews te laten uitvoeren op gemaakte code (bijvoorbeeld peer reviews) kan onnodige complexiteit worden voorkomen. Ook dient er gekeken te worden naar consequente opbouw, structuur, u003ca class=u0022clru002du002dprimu0022 href=u0022https://en.wikipedia.org/wiki/Coding_conventionsu0022 target=u0022_blanku0022 rel=u0022noopener noreferreru0022u003ecode conventionsu003c/au003e en design patterns. Voordeel van deze reviews is dat conclusies worden getrokken met de context van de applicatie en het team in het achterhoofd. Nadeel is dat het tijd kost van developers en dat het een volwassen team vereist, waarin teamleden zich veilig voelen om bevindingen met elkaar te delen. In een onvolwassen team zien we vaak dat deze reviews weinig structurele problemen aan het licht brengen.

Statische code analyse

Voor statistische code analyse is tooling in te zetten die regelmatig de onderhoudbaarheid in kaart brengt. Deze tooling is te koppelen aan een u003ca class=u0022clru002du002dprimu0022 href=u0022https://en.wikipedia.org/wiki/Continuous_integrationu0022 target=u0022_blanku0022 rel=u0022noopener noreferreru0022u003eContinuous Integration u003c/au003eomgeving, zoals Jenkins of Microsoft Team Foundation Server. Voorbeeld hiervan is u003ca class=u0022clru002du002dprimu0022 href=u0022http://www.sonarqube.org/u0022 target=u0022_blanku0022 rel=u0022noopener noreferreru0022u003eSonarQubeu003c/au003e, dat inzicht geeft in onder andere potentiële bugs, afwijkingen van coding standaarden, duplicaten, code coverage, complexiteit, spaghetti code en commentaar. Door middel van u003cemu003eruleu003cstrongu003e u003c/strongu003esetsu003c/emu003e* *kunnen deze checks worden aangepast aan hetgeen belangrijk is binnen het team en de organisatie. Voordeel hiervan is dat er dagelijks inzicht is in de code kwaliteit (en daarmee de onderhoudbaarheid) en dat dit geen tijd kost van developers. Maar het belangrijkste voordeel is dat de trend zichtbaar wordt. Neemt de kwaliteit in de tijd juist toe of af? Dat is een belangrijk signaal om in het development team te bespreken.rnu003cfigure class=u0022clearfixu0022u003eu003c/figureu003ernu003cfigure class=u0022clearfixu0022u003eu003cimg class=u0022aligncenteru0022 src=u0022https://vxcompany.com/wp-content/uploads/Onderhoudbaarheid-tip-2-maak-analyseerbaarheid-en-complexiteit-zichtbaar-project-dashboard-blog-Victor.pngu0022 srcset=u0022u0022 alt=u0022onderhoudbaarheid-tip-2-maak-analyseerbaarheid-en-complexiteit-zichtbaar-project-dashboard-blog-victoru0022 width=u0022499u0022 height=u0022autou0022 data-srcset=u0022https://vxcompany.com/wp-content/uploads/Onderhoudbaarheid-tip-2-maak-analyseerbaarheid-en-complexiteit-zichtbaar-project-dashboard-blog-Victor.png 249w, https://vxcompany.com/wp-content/uploads/Onderhoudbaarheid-tip-2-maak-analyseerbaarheid-en-complexiteit-zichtbaar-project-dashboard-blog-Victor@2x.png 499w, https://vxcompany.com/wp-content/uploads/Onderhoudbaarheid-tip-2-maak-analyseerbaarheid-en-complexiteit-zichtbaar-project-dashboard-blog-Victor@4x.png 997wu0022 /u003eu003c/figureu003e

Delen