Inleiding tot technische schulden

Technische schuld is een begrip dat de toekomstige kosten beschrijft die voortkomen uit het kiezen van een eenvoudige oplossing vandaag, in plaats van betere praktijken te gebruiken die meer tijd kosten om te voltooien.

De term "technische schuld" is gekozen omdat deze vergelijkbaar is met financiële schulden. Het is gebruikelijk dat mensen met financiële schulden beslissingen nemen die op dat moment de enige optie lijken of de enige optie zijn, maar hierdoor neemt de rente toe.

Hoe meer belangstelling, hoe moeilijker het wordt voor hen in de toekomst en hoe minder opties ze later hebben. Met financiële schuld neemt de rente snel toe op rente, waardoor er een sneeuwbaleffect ontstaat. Op dezelfde manier kan de technische schuld zich opbouwen tot het punt waar ontwikkelaars bijna al hun tijd besteden aan het oplossen van problemen en het opnieuw bewerken, ofwel gepland of ongepland, in plaats van waarde toe te voegen.

Hoe gebeurt het?

Het meest voorkomende excuus is strakke deadlines. Wanneer ontwikkelaars snel code moeten maken, nemen ze vaak snelkoppelingen. In plaats van bijvoorbeeld een methode te herstructureren om nieuwe functionaliteit op te nemen, kunnen ze deze kopiëren om een nieuwe versie te maken. Vervolgens testen ze alleen de nieuwe code en kunnen ze het vereiste testniveau vermijden als ze de oorspronkelijke methode wijzigen, omdat andere onderdelen van de code deze gebruiken.

Nu hebben ze twee kopieën van dezelfde code die in de toekomst moeten worden gewijzigd in plaats van één, en lopen ze het risico dat de logica anders wordt. Er zijn veel oorzaken. Er kan bijvoorbeeld een gebrek aan technische vaardigheden en volwassenheid zijn onder ontwikkelaars of geen duidelijke producteigenaar of -richting.

De organisatie heeft mogelijk helemaal geen coderingsstandaarden, dus de ontwikkelaars wisten niet eens wat ze moesten produceren. De ontwikkelaars hebben mogelijk geen duidelijke vereisten om te targeten, of ze zijn mogelijk onderhevig aan wijzigingen in last-minute vereisten.

De benodigde herstructurering kan worden vertraagd. Er zijn mogelijk geen kwaliteitstests voor code, handmatig of geautomatiseerd. Uiteindelijk maakt het het alleen moeilijker en moeilijker om waarde te leveren aan klanten binnen een redelijke termijn en tegen redelijke kosten.

Technische schuld is een van de belangrijkste redenen waarom projecten niet aan hun deadlines voldoen.

Na verloop van tijd neemt het op veel dezelfde manier toe als de monetaire schuld. Veelvoorkomende bronnen van technische schulden zijn:

• Gebrek aan coderingsstijl en -standaarden
• Gebrek aan of slecht ontwerp van eenheidstestcases
• Objectgeoriënteerde ontwerpprincipes negeren of niet begrijpen
• Monolithische klassen en codebibliotheken
• Slecht gepland gebruik van technologie, architectuur en benadering (vergeet dat alle systeemkenmerken, die van invloed zijn op onderhoud, gebruikerservaring, schaalbaarheid en andere, moeten worden overwogen)
• Over-engineering van code (code toevoegen of maken dat niet vereist is, aangepaste code toevoegen wanneer bestaande bibliotheken voldoende zijn, of lagen of componenten maken die niet nodig zijn)
• Onvoldoende opmerkingen en documentatie
• Zelfdocumentatiecode niet schrijven (inclusief klasse, methode en variabelenamen die beschrijvend zijn of intentie aangeven)
• Snelkoppelingen maken om te voldoen aan deadlines
• Dode code op zijn plaats laten

We hebben gezien dat technische schuld problemen toevoegt tijdens de ontwikkeling en het veel moeilijker maakt om extra klantwaarde toe te voegen.

Het hebben van technische schulden in een project vermindert de productiviteit, frustreert ontwikkelteams, maakt code zowel moeilijk te begrijpen als kwetsbaar, verhoogt de tijd om wijzigingen aan te brengen en deze wijzigingen te valideren. Ongepland werk komt vaak in de weg van gepland werk.

Op langere termijn verzwakt het ook de kracht van de organisatie. Technische schulden kruipen meestal op een organisatie. Het begint klein en groeit in de loop van de tijd. Telkens wanneer een snelle hack wordt gemaakt of tests worden overgeslagen omdat wijzigingen snel moeten worden doorgevoerd, verslechtert het probleem steeds verder. De ondersteuningskosten worden hoger en hoger en uiteindelijk ontstaat er een ernstig probleem.

Uiteindelijk kan de organisatie niet op een tijdige en kostenefficiënte manier reageren op de behoeften van de klanten.

Geautomatiseerde meting voor bewaking

Een belangrijke manier om de constante opbouw van technische schulden te minimaliseren, is door geautomatiseerde tests en evaluaties te gebruiken.

In de demo's die volgen, kijken we naar een van de algemene hulpprogramma's die worden gebruikt om de schuld te beoordelen: SonarCloud. (De oorspronkelijke on-premises versie was SonarQube).

Er zijn andere hulpprogramma's beschikbaar en we bespreken er een paar.

Later ziet u in het volgende praktijklab hoe u uw Azure Pipelines configureert om SonarCloud te gebruiken, inzicht te krijgen in de analyseresultaten en ten slotte hoe u kwaliteitsprofielen configureert om de regelsets te beheren die door SonarCloud worden gebruikt bij het analyseren van uw projecten.

Zie SonarCloud voor meer informatie.

Ter beoordeling:

Azure DevOps kan worden geïntegreerd met een breed scala aan bestaande hulpprogramma's die worden gebruikt om de codekwaliteit tijdens builds te controleren.

Welke hulpprogramma's voor codekwaliteit gebruikt u momenteel (indien aanwezig)?

Wat vind je leuk of vind je niet leuk aan de tools?