Hvordan evaluere, administrere og unngå teknisk gjeld

Hvis teknisk gjeld høres ut som noe som er løftet fra en håndbok om finans, er det fordi begrepet er relatert til finans. Men i den virkelige forstand er teknisk gjeld knyttet til programmering. Det er ideen at under utviklingen av et programvareprosjekt blir visse nødvendige trinn hoppet over, eller bare forkastet i et forsøk på å overholde en tidsfrist.

I et forsøk på å utvikle den perfekte appen eller programvaren, er utviklere ofte satt i tid – akkurat som enhver tilfeldig person som uansett utfører en hvilken som helst vilkårlig oppgave. Derfor er det vanligvis fornuftig å ha en slags avveining mellom å levere et perfekt produkt med perfekt kode og å maksimere tiden.

Spørsmålet er da: er det en grense for disse avveiningene? Er det iboende skader som kan følge av denne avveiningen? Til slutt, er utvikleren virkelig bedre i det lange løp? I dette stykket om teknisk gjeld vil jeg forsøke å svare på alle disse spørsmålene.

Hva er teknisk gjeld?

Når vi definerer teknisk gjeld, må vi referere til mannen som er kreditert for å ha generert begrepet i utgangspunktet: Ward Cunningham. Ifølge Cunningham refererer teknisk gjeld til det ekstra utviklingsarbeidet som må gå med til å programmere en kode for å kompensere for underskuddet som oppstår ved å programmere den innen en kort periode.

For å gjøre det mer grafisk, forestill deg at du har i oppgave å rydde opp i et rotete rom, og du kommer for sent til en time. I et forsøk på å sikre at du utfører instruksjonen og også kommer i tide til timen din, gjør du en rask rengjøring og feier det meste av rusket under sofaen. Resultatet av dette er at du til slutt må ta deg tid til å sortere gjennom rotet. For programvareutvikling, når du hopper gjennom de nødvendige trinnene og følger en enklere rute, med ‘ikke så rene’ koder, vil det bli vanskeligere å rydde opp i koden senere i fremtiden. Det er flere faser i programvareprosjektets dominobrikker, og jo lenger du ignorerer et eksisterende problem, desto lengre tid tar det å bli løst.

Typer teknisk gjeld

Teknisk gjeld er av forskjellige typer, inkludert:

Planlagt teknisk gjeld

Dette skjer i situasjoner der organisasjoner bevisst bestemmer seg for å gå inn i teknisk gjeld. Dette, som tidligere diskutert, er vanligvis for å slå oppgitte tidsfrister og komme frem til et bestemt mål. Når man engasjerer seg i planlagt teknisk gjeld, må organisasjonen være tydelig på hva de er villige til å gi opp, og hva de ikke kan. Du må føre nøyaktige poster, med tanke på at du til slutt må returnere og rette opp feilene du hoppet gjennom i begynnelsen.

Utilsiktet teknisk gjeld

Denne typen teknisk gjeld er en direkte motsetning til den første. Det oppstår når en organisasjon ikke forutser eller planlegger teknisk gjeld. Årsaken til dette er typisk et sammenbrudd i kommunikasjonen mellom de ulike enhetene i organisasjonen, eller elendig arbeidspraksis mellom enhetene.

Uunngåelig teknisk gjeld

Dette er den typen teknisk gjeld som ingen handling fra organisasjonens side kunne ha forhindret. For eksempel, med de raske endringene som oppleves i teknologi, er det fornuftig at noen koder som er skrevet i fortiden, vil falle under de nåværende standardene som er anslått.

Også denne typen teknisk gjeld kan oppstå når endringer blir forespurt når koden allerede skrives. Hvis det innføres visse endringer midtveis i utformingen av programvaren, kan det ødelegge dynamikken, slik at den gamle koden blir foreldet eller unødvendig.

Årsaker til teknisk gjeld

Noen av årsakene til teknisk gjeld har blitt diskutert ovenfor, men jeg vil bare plukke dem ut etter hverandre for å gjøre dem klarere.

Hastverk

Den hyppigste årsaken til teknisk gjeld er hastverk. Utviklere har ofte strenge tidsfrister, hvorav noen inkluderer frister for lansering av viss programvare. Det er ofte forståelig (og forventet) i slike situasjoner at utvikleren kan pådra seg teknisk gjeld underveis. Denne typen teknisk gjeld er ofte tilsiktet og kan føre til problemer som kan variere fra feil i koden, eller spaghettikoder som oppstår.

Forglemmelse/feil

Noen ganger skriver programmerere bare dårlige koder, som til slutt fører til teknisk gjeld. Uansett om den dårlige koden eksisterer som følge av feilen til koderen eller ikke, er faktum at feil resulterer i teknisk gjeld, og fordi de ikke er skalerbare, vil de til slutt måtte fikses.

Mangel på bevissthet om effektene

Noen ganger oppstår teknisk gjeld fordi koderen ikke klarer å innse eller erkjenne hvor skadelig teknisk gjeld er i det lange løp. Dette kan stamme fra en legitim uvitenhet om de skadelige effektene av å ta snarveier under programmering, eller det kan være en forsettlig ignorering av konsekvensene.

Intensjon

Teknisk gjeld kan oppstå med vilje ved bevisste handlinger fra koderen eller organisasjonen.

Mangel på modularitet

Dette oppstår hovedsakelig fordi én kode kan betjene ulike forretningslogikk samtidig. Denne typen situasjon gjør håndtering av programvare mye vanskeligere. Med hver kode en utvikler skriver, jo større sjanse er det for at de vil oppleve utfordringer med modularitet.

Vurdering av teknisk gjeld

Teknisk gjeld bør aldri beregnes manuelt fordi det ville være ganske vanskelig. Det ville bety å måtte angi koden manuelt for å finne ut de nåværende problemene og mulige fremtidige. Bortsett fra hvor tidssløsende den manuelle prosessen er, er det en mulighet for at kodene ville ha endret form på slutten av den manuelle prosessen.

En måte å gjennomføre evalueringen på er å utføre en statisk analyse ved å bruke noen verktøy som støtter den. Noen av verktøyene som kan brukes inkluderer Coverity, SonarQube, Check Style og Closure Compiler.

Generelt er det to måter å beregne teknisk gjeld på. I den første tilnærmingen kunne den oppnås ved å beregne den tekniske gjeldens forholdstall etter kodeforhold. Her vil det første estimatet eller den totale tiden som trengs for å utvikle appen bli brukt til å bestemme tiden det tar å fikse den tekniske gjelden.

I den andre tilnærmingen kan du direkte bruke estimatene gitt av de forskjellige verktøyene som SonarQube. Dette vil bli kombinert med listene over de tekniske gjeldene samt deres referansekoder. Fra verktøyene kan du få et nøyaktig anslag over hvor lang tid det tar å fikse det.

Evaluering av den tekniske gjelden vil gi deg en følelse av hvor mange dager det vil ta å fikse den tekniske gjelden. Jo mer gjeld det er, jo lengre tid vil det ta deg å fikse det.

Løsning av teknisk gjeld

Hva om teknisk gjeld har oppstått og du er usikker på hva du skal gjøre? Det er visse skritt du kan ta for å håndtere den tekniske gjelden.

For det første bør du erkjenne at den tekniske gjelden eksisterer og kommunisere det samme til teamet ditt. Når du kommuniserer, bør du være tydelig på hva som har skjedd og hva som må gjøres for å rette opp det. Du bør sørge for at du tydelig kommuniserer behovet for å ta hånd om den tekniske gjelden så tidlig som mulig.

Etter å ha informert teamet ditt om den tekniske gjelden, er det tre tilnærminger du kan ta. I den første tilnærmingen kan du bestemme deg for å fortsette med systemet som det er. I dette scenariet vil applikasjonen bli brukt som den er.

Alternativt kan du velge å refaktorisere søknaden. Refaktorering gjøres med mål om å redusere kompleksiteten i appen samt rydde opp i appens struktur. Med refactoring vil ikke oppførselen til programvaren endres; den eneste berørte delen vil være den indre strukturen.

Til slutt, hvis de to alternativene diskutert ovenfor ikke fungerer, må du erstatte koden helt. Et problem med dette er at det kan føre til ny teknisk gjeld, men det kan være en bedre avveining på sikt.

Unngå teknisk gjeld i fremtiden

Selvfølgelig er det en enkel sak at det definitivt er smartere å unngå teknisk gjeld enn å prøve å fikse dem når de oppstår. Bortsett fra at det sparer deg for både tid og stress, sørger det også for at restkonsekvensene som kommer av å ha teknisk gjeld fra starten uteblir.

Det kan hevdes at teknisk gjeld i seg selv ikke er dårlig. De er generelt problematiske fordi de er gjeld som må betales tilbake, og mennesker er ikke den mest ansvarlige arten på jorden. Å konsekvent velge et svakere alternativ vil generelt svekke styrken til programvaren din, og gjøre det vanskeligere å forbedre funksjonaliteten senere. Alt i alt er det beste alternativet for alle å unngå teknisk gjeld.

Så hvordan forhindrer du at teknisk gjeld oppstår:

Opprett en prosjektetterslep

Tanken her er å holde alle orientert om prosessen og få dem oppdatert med kravet til den oppgaven som skal utføres. Når du oppretter et etterslep, kan alle se oppgavene som er ugjort, og veiene å ta for å oppnå dem.

Prioriter kvalitet fremfor hastighet

Hvis du selv er programmerer, må du lære deg å prioritere å legge ut kvalitetsarbeid fremfor mye arbeid. Sørg for at kodene dine er rene, og at appene eller annen programvare er utviklet til perfeksjon. Forstå at fristelsen til å ta snarveier ikke vil være verdt det, fordi du til slutt fortsatt må utføre oppgavene du forkastet.

Hvis du leder et team, må du kommunisere de samme verdiene til teammedlemmer. Medlemmene bør læres å lage resultatorienterte løsninger og unngå snarveier.

Bevisstgjøre

Generelt kan en inngående kunnskap om hva teknisk gjeld er og hvordan man unngår den være nyttig for å forhindre at de oppstår i utgangspunktet. Når du bevæpner utviklerne dine med den nødvendige kunnskapen, vil de bedre unngå fellene teknisk gjeld utgjør.

Introduser god kodingspraksis

Noen kodingspraksis gjør det mer sannsynlig enn ikke for deg å havne i teknisk gjeld. Derfor ville det være flott å unngå tett kobling, bruke abstraksjon og refactoring.

Introduser oppdatert teknologi

Regelmessige oppdateringer av teknologi kan være et utmerket middel for å unngå teknisk gjeld. Ved oppdatering må du sørge for at det som brukes er det siste rammeverket, databaser og applikasjonsprogramvare.

Konklusjon

Teknisk gjeld er i de aller fleste tilfeller uunngåelig så lenge du fortsetter å utvikle programmer og skrive koder. Imidlertid kan sjansene for at de forekommer, reduseres betraktelig når trinnene ovenfor følges. Dessuten, i tilfelle av teknisk gjeld, er ikke alt håp ute. Hold deg rolig, vær selvsikker, handle deretter.