Inleiding tot technische schulden
Technische schuld is een termijn die de toekomstige kosten beschrijft die worden gemaakt door vandaag een eenvoudige oplossing te kiezen in plaats van betere procedures te gebruiken, omdat het langer duurt om deze te voltooien.
De termijn technische schuld werd gekozen voor zijn vergelijking met financiële schulden. Het is gebruikelijk dat mensen met financiële schulden beslissingen nemen die op dat moment geschikt of de enige optie lijken, maar in dat geval neemt de rente toe.
Hoe meer rente, hoe moeilijker het voor hen is in de toekomst en hoe minder kleine opties later beschikbaar zijn. Met financiële schulden neemt de rente binnenkort toe op rente, waardoor er een sneeuwbaleffect ontstaat. Op dezelfde manier kunnen technische schulden zich opbouwen tot het punt waar ontwikkelaars bijna al hun tijd besteden aan het sorteren van problemen en het opnieuw bewerken, 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 we kopiëren om een nieuwe versie te maken. Vervolgens test ik alleen mijn nieuwe code en kan ik het vereiste testniveau vermijden als ik de oorspronkelijke methode wijzig omdat andere onderdelen van de code deze gebruiken.
Nu heb ik twee kopieën van dezelfde code die ik in de toekomst moet wijzigen in plaats van één, en ik loop het risico dat de logica afwijkt. Er zijn veel oorzaken. Er kan bijvoorbeeld een gebrek aan technische vaardigheden en volwassenheid zijn tussen de ontwikkelaars of geen duidelijk producteigendom of -richting.
De organisatie heeft mogelijk helemaal geen coderingsstandaarden. De ontwikkelaars wisten dus niet eens wat ze moesten produceren. De ontwikkelaars hebben mogelijk geen nauwkeurige vereisten om zich te richten. Misschien zijn ze 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 testcases voor eenheden.
- Objectoriënteerde ontwerpprincipes negeren of niet begrijpen.
- Monolithische klassen en codebibliotheken.
- Slecht bedacht het gebruik van technologie, architectuur en benadering. (Vergeet dat alle systeemkenmerken, die van invloed zijn op onderhoud, gebruikerservaring, schaalbaarheid en andere, moeten worden overwogen).
- Over-engineeringcode (code toevoegen of maken die niet vereist is, aangepaste code toevoegen wanneer bestaande bibliotheken voldoende zijn of lagen of onderdelen 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.
- Laat dode code staan.
Notitie
Na verloop van tijd moet de technische schuld worden terugbetaald. Anders kan het team problemen oplossen en nieuwe functies en verbeteringen implementeren, langer duren en uiteindelijk kosten-verbiedend worden.
We hebben gezien dat de technische schuld een aantal problemen toevoegt tijdens de ontwikkeling en het veel moeilijker maakt om extra klantwaarde toe te voegen.
Het hebben van technische schulden in een project saps 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 is 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 testen wordt omzeild omdat wijzigingen moeten worden overhaast, wordt het probleem erger en slechter. De ondersteuningskosten worden hoger en hoger, en er ontstaat altijd 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 verwerving 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.
Beoordeel het volgende:
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?