{"id":257570,"date":"2023-03-02T06:48:00","date_gmt":"2023-03-02T03:48:00","guid":{"rendered":"https:\/\/inform.click\/hvordan-evaluere-administrere-og-unnga-teknisk-gjeld\/"},"modified":"2023-03-02T06:59:00","modified_gmt":"2023-03-02T03:59:00","slug":"hvordan-evaluere-administrere-og-unnga-teknisk-gjeld","status":"publish","type":"post","link":"https:\/\/inform.click\/no\/hvordan-evaluere-administrere-og-unnga-teknisk-gjeld\/","title":{"rendered":"Hvordan evaluere, administrere og unng\u00e5 teknisk gjeld"},"content":{"rendered":"

\n Hvis teknisk gjeld h\u00f8res ut som noe som er l\u00f8ftet fra en h\u00e5ndbok 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\u00f8dvendige trinn hoppet over, eller bare forkastet i et fors\u00f8k p\u00e5 \u00e5 overholde en tidsfrist.\n<\/p>\n

\n I et fors\u00f8k p\u00e5 \u00e5 utvikle den perfekte appen eller programvaren, er utviklere ofte satt i tid \u2013 akkurat som enhver tilfeldig person som uansett utf\u00f8rer en hvilken som helst vilk\u00e5rlig oppgave. Derfor er det vanligvis fornuftig \u00e5 ha en slags avveining mellom \u00e5 levere et perfekt produkt med perfekt kode og \u00e5 maksimere tiden.\n<\/p>\n

\n Sp\u00f8rsm\u00e5let er da: er det en grense for disse avveiningene? Er det iboende skader som kan f\u00f8lge av denne avveiningen? Til slutt, er utvikleren virkelig bedre i det lange l\u00f8p? I dette stykket om teknisk gjeld vil jeg fors\u00f8ke \u00e5 svare p\u00e5 alle disse sp\u00f8rsm\u00e5lene.\n<\/p>\n

\n Hva er teknisk gjeld?
\n<\/h5>\n

\n N\u00e5r vi definerer teknisk gjeld, m\u00e5 vi referere til mannen som er kreditert for \u00e5 ha generert begrepet i utgangspunktet: Ward Cunningham. If\u00f8lge Cunningham refererer teknisk gjeld til det ekstra utviklingsarbeidet som m\u00e5 g\u00e5 med til \u00e5 programmere en kode for \u00e5 kompensere for underskuddet som oppst\u00e5r ved \u00e5 programmere den innen en kort periode.\n<\/p>\n

\n For \u00e5 gj\u00f8re det mer grafisk, forestill deg at du har i oppgave \u00e5 rydde opp i et rotete rom, og du kommer for sent til en time. I et fors\u00f8k p\u00e5 \u00e5 sikre at du utf\u00f8rer instruksjonen og ogs\u00e5 kommer i tide til timen din, gj\u00f8r du en rask rengj\u00f8ring og feier det meste av rusket under sofaen. Resultatet av dette er at du til slutt m\u00e5 ta deg tid til \u00e5 sortere gjennom rotet. For programvareutvikling, n\u00e5r du hopper gjennom de n\u00f8dvendige trinnene og f\u00f8lger en enklere rute, med ‘ikke s\u00e5 rene' koder, vil det bli vanskeligere \u00e5 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 \u00e5 bli l\u00f8st.\n<\/p>\n

\n Typer teknisk gjeld\n<\/p>\n

\n Teknisk gjeld er av forskjellige typer, inkludert:\n<\/p>\n

\n Planlagt teknisk gjeld
\n<\/h5>\n

\n Dette skjer i situasjoner der organisasjoner bevisst bestemmer seg for \u00e5 g\u00e5 inn i teknisk gjeld. Dette, som tidligere diskutert, er vanligvis for \u00e5 sl\u00e5 oppgitte tidsfrister og komme frem til et bestemt m\u00e5l. N\u00e5r man engasjerer seg i planlagt teknisk gjeld, m\u00e5 organisasjonen v\u00e6re tydelig p\u00e5 hva de er villige til \u00e5 gi opp, og hva de ikke kan. Du m\u00e5 f\u00f8re n\u00f8yaktige poster, med tanke p\u00e5 at du til slutt m\u00e5 returnere og rette opp feilene du hoppet gjennom i begynnelsen.\n<\/p>\n

\n Utilsiktet teknisk gjeld
\n<\/h5>\n

\n Denne typen teknisk gjeld er en direkte motsetning til den f\u00f8rste. Det oppst\u00e5r n\u00e5r en organisasjon ikke forutser eller planlegger teknisk gjeld. \u00c5rsaken til dette er typisk et sammenbrudd i kommunikasjonen mellom de ulike enhetene i organisasjonen, eller elendig arbeidspraksis mellom enhetene.\n<\/p>\n

\n Uunng\u00e5elig teknisk gjeld
\n<\/h5>\n

\n 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\u00e5v\u00e6rende standardene som er ansl\u00e5tt.\n<\/p>\n

\n Ogs\u00e5 denne typen teknisk gjeld kan oppst\u00e5 n\u00e5r endringer blir forespurt n\u00e5r koden allerede skrives. Hvis det innf\u00f8res visse endringer midtveis i utformingen av programvaren, kan det \u00f8delegge dynamikken, slik at den gamle koden blir foreldet eller un\u00f8dvendig.\n<\/p>\n

\n \u00c5rsaker til teknisk gjeld
\n<\/h3>\n

\"\"<\/a><\/p>\n

\n Noen av \u00e5rsakene til teknisk gjeld har blitt diskutert ovenfor, men jeg vil bare plukke dem ut etter hverandre for \u00e5 gj\u00f8re dem klarere.\n<\/p>\n

\n Hastverk
\n<\/h5>\n

\n Den hyppigste \u00e5rsaken til teknisk gjeld er hastverk. Utviklere har ofte strenge tidsfrister, hvorav noen inkluderer frister for lansering av viss programvare. Det er ofte forst\u00e5elig (og forventet) i slike situasjoner at utvikleren kan p\u00e5dra seg teknisk gjeld underveis. Denne typen teknisk gjeld er ofte tilsiktet og kan f\u00f8re til problemer som kan variere fra feil i koden, eller spaghettikoder som oppst\u00e5r.\n<\/p>\n

\n Forglemmelse\/feil
\n<\/h5>\n

\n Noen ganger skriver programmerere bare d\u00e5rlige koder, som til slutt f\u00f8rer til teknisk gjeld. Uansett om den d\u00e5rlige koden eksisterer som f\u00f8lge 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\u00e5tte fikses.\n<\/p>\n

\n Mangel p\u00e5 bevissthet om effektene
\n<\/h5>\n

\n Noen ganger oppst\u00e5r teknisk gjeld fordi koderen ikke klarer \u00e5 innse eller erkjenne hvor skadelig teknisk gjeld er i det lange l\u00f8p. Dette kan stamme fra en legitim uvitenhet om de skadelige effektene av \u00e5 ta snarveier under programmering, eller det kan v\u00e6re en forsettlig ignorering av konsekvensene.\n<\/p>\n

\n Intensjon
\n<\/h5>\n

\n Teknisk gjeld kan oppst\u00e5 med vilje ved bevisste handlinger fra koderen eller organisasjonen.\n<\/p>\n

\n Mangel p\u00e5 modularitet
\n<\/h5>\n

\n Dette oppst\u00e5r hovedsakelig fordi \u00e9n kode kan betjene ulike forretningslogikk samtidig. Denne typen situasjon gj\u00f8r h\u00e5ndtering av programvare mye vanskeligere. Med hver kode en utvikler skriver, jo st\u00f8rre sjanse er det for at de vil oppleve utfordringer med modularitet.\n<\/p>\n

\n Vurdering av teknisk gjeld
\n<\/h3>\n

\"\"<\/a><\/p>\n

\n Teknisk gjeld b\u00f8r aldri beregnes manuelt fordi det ville v\u00e6re ganske vanskelig. Det ville bety \u00e5 m\u00e5tte angi koden manuelt for \u00e5 finne ut de n\u00e5v\u00e6rende problemene og mulige fremtidige. Bortsett fra hvor tidssl\u00f8sende den manuelle prosessen er, er det en mulighet for at kodene ville ha endret form p\u00e5 slutten av den manuelle prosessen.\n<\/p>\n

\n En m\u00e5te \u00e5 gjennomf\u00f8re evalueringen p\u00e5 er \u00e5 utf\u00f8re en statisk analyse ved \u00e5 bruke noen verkt\u00f8y som st\u00f8tter den. Noen av verkt\u00f8yene som kan brukes inkluderer Coverity, SonarQube, Check Style og Closure Compiler.\n<\/p>\n

\n Generelt er det to m\u00e5ter \u00e5 beregne teknisk gjeld p\u00e5. I den f\u00f8rste tiln\u00e6rmingen kunne den oppn\u00e5s ved \u00e5 beregne den tekniske gjeldens forholdstall etter kodeforhold. Her vil det f\u00f8rste estimatet eller den totale tiden som trengs for \u00e5 utvikle appen bli brukt til \u00e5 bestemme tiden det tar \u00e5 fikse den tekniske gjelden.\n<\/p>\n

\n I den andre tiln\u00e6rmingen kan du direkte bruke estimatene gitt av de forskjellige verkt\u00f8yene som SonarQube. Dette vil bli kombinert med listene over de tekniske gjeldene samt deres referansekoder. Fra verkt\u00f8yene kan du f\u00e5 et n\u00f8yaktig anslag over hvor lang tid det tar \u00e5 fikse det.\n<\/p>\n

\n Evaluering av den tekniske gjelden vil gi deg en f\u00f8lelse av hvor mange dager det vil ta \u00e5 fikse den tekniske gjelden. Jo mer gjeld det er, jo lengre tid vil det ta deg \u00e5 fikse det.\n<\/p>\n

\n L\u00f8sning av teknisk gjeld
\n<\/h3>\n

\n Hva om teknisk gjeld har oppst\u00e5tt og du er usikker p\u00e5 hva du skal gj\u00f8re? Det er visse skritt du kan ta for \u00e5 h\u00e5ndtere den tekniske gjelden.\n<\/p>\n

\n For det f\u00f8rste b\u00f8r du erkjenne at den tekniske gjelden eksisterer og kommunisere det samme til teamet ditt. N\u00e5r du kommuniserer, b\u00f8r du v\u00e6re tydelig p\u00e5 hva som har skjedd og hva som m\u00e5 gj\u00f8res for \u00e5 rette opp det. Du b\u00f8r s\u00f8rge for at du tydelig kommuniserer behovet for \u00e5 ta h\u00e5nd om den tekniske gjelden s\u00e5 tidlig som mulig.\n<\/p>\n

\n Etter \u00e5 ha informert teamet ditt om den tekniske gjelden, er det tre tiln\u00e6rminger du kan ta. I den f\u00f8rste tiln\u00e6rmingen kan du bestemme deg for \u00e5 fortsette med systemet som det er. I dette scenariet vil applikasjonen bli brukt som den er.\n<\/p>\n

\n Alternativt kan du velge \u00e5 refaktorisere s\u00f8knaden. Refaktorering gj\u00f8res med m\u00e5l om \u00e5 redusere kompleksiteten i appen samt rydde opp i appens struktur. Med refactoring vil ikke oppf\u00f8rselen til programvaren endres; den eneste ber\u00f8rte delen vil v\u00e6re den indre strukturen.\n<\/p>\n

\n Til slutt, hvis de to alternativene diskutert ovenfor ikke fungerer, m\u00e5 du erstatte koden helt. Et problem med dette er at det kan f\u00f8re til ny teknisk gjeld, men det kan v\u00e6re en bedre avveining p\u00e5 sikt.\n<\/p>\n

\n Unng\u00e5 teknisk gjeld i fremtiden
\n<\/h3>\n

\"\"<\/a><\/p>\n

\n Selvf\u00f8lgelig er det en enkel sak at det definitivt er smartere \u00e5 unng\u00e5 teknisk gjeld enn \u00e5 pr\u00f8ve \u00e5 fikse dem n\u00e5r de oppst\u00e5r. Bortsett fra at det sparer deg for b\u00e5de tid og stress, s\u00f8rger det ogs\u00e5 for at restkonsekvensene som kommer av \u00e5 ha teknisk gjeld fra starten uteblir.\n<\/p>\n

\n Det kan hevdes at teknisk gjeld i seg selv ikke er d\u00e5rlig. De er generelt problematiske fordi de er gjeld som m\u00e5 betales tilbake, og mennesker er ikke den mest ansvarlige arten p\u00e5 jorden. \u00c5 konsekvent velge et svakere alternativ vil generelt svekke styrken til programvaren din, og gj\u00f8re det vanskeligere \u00e5 forbedre funksjonaliteten senere. Alt i alt er det beste alternativet for alle \u00e5 unng\u00e5 teknisk gjeld.\n<\/p>\n

\n S\u00e5 hvordan forhindrer du at teknisk gjeld oppst\u00e5r:\n<\/p>\n

\n Opprett en prosjektetterslep\n<\/p>\n

\n Tanken her er \u00e5 holde alle orientert om prosessen og f\u00e5 dem oppdatert med kravet til den oppgaven som skal utf\u00f8res. N\u00e5r du oppretter et etterslep, kan alle se oppgavene som er ugjort, og veiene \u00e5 ta for \u00e5 oppn\u00e5 dem.\n<\/p>\n

\n Prioriter kvalitet fremfor hastighet\n<\/p>\n

\n Hvis du selv er programmerer, m\u00e5 du l\u00e6re deg \u00e5 prioritere \u00e5 legge ut kvalitetsarbeid fremfor mye arbeid. S\u00f8rg for at kodene dine er rene, og at appene eller annen programvare er utviklet til perfeksjon. Forst\u00e5 at fristelsen til \u00e5 ta snarveier ikke vil v\u00e6re verdt det, fordi du til slutt fortsatt m\u00e5 utf\u00f8re oppgavene du forkastet.\n<\/p>\n

\n Hvis du leder et team, m\u00e5 du kommunisere de samme verdiene til teammedlemmer. Medlemmene b\u00f8r l\u00e6res \u00e5 lage resultatorienterte l\u00f8sninger og unng\u00e5 snarveier.\n<\/p>\n

\n Bevisstgj\u00f8re\n<\/p>\n

\n Generelt kan en inng\u00e5ende kunnskap om hva teknisk gjeld er og hvordan man unng\u00e5r den v\u00e6re nyttig for \u00e5 forhindre at de oppst\u00e5r i utgangspunktet. N\u00e5r du bev\u00e6pner utviklerne dine med den n\u00f8dvendige kunnskapen, vil de bedre unng\u00e5 fellene teknisk gjeld utgj\u00f8r.\n<\/p>\n

\n Introduser god kodingspraksis\n<\/p>\n

\n Noen kodingspraksis gj\u00f8r det mer sannsynlig enn ikke for deg \u00e5 havne i teknisk gjeld. Derfor ville det v\u00e6re flott \u00e5 unng\u00e5 tett kobling, bruke abstraksjon og refactoring.\n<\/p>\n

\n Introduser oppdatert teknologi\n<\/p>\n

\n Regelmessige oppdateringer av teknologi kan v\u00e6re et utmerket middel for \u00e5 unng\u00e5 teknisk gjeld. Ved oppdatering m\u00e5 du s\u00f8rge for at det som brukes er det siste rammeverket, databaser og applikasjonsprogramvare.\n<\/p>\n

\n Konklusjon
\n<\/h5>\n

\n Teknisk gjeld er i de aller fleste tilfeller uunng\u00e5elig s\u00e5 lenge du fortsetter \u00e5 utvikle programmer og skrive koder. Imidlertid kan sjansene for at de forekommer, reduseres betraktelig n\u00e5r trinnene ovenfor f\u00f8lges. Dessuten, i tilfelle av teknisk gjeld, er ikke alt h\u00e5p ute. Hold deg rolig, v\u00e6r selvsikker, handle deretter.\n<\/p>\n<\/p>\n

\n Opptakskilde: instantshift.com<\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Hvis teknisk gjeld h\u00f8res ut som noe som er l\u00f8ftet fra en h\u00e5ndbok 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\u00f8dvendige trinn hoppet over, eller bare forkastet i et fors\u00f8k p\u00e5 \u00e5 overholde en tidsfrist. I et fors\u00f8k p\u00e5 \u00e5 utvikle den perfekte appen eller programvaren, er utviklere ofte satt i tid \u2013 akkurat som enhver tilfeldig person som uansett utf\u00f8rer en hvilken som helst vilk\u00e5rlig oppgave. Derfor er det vanligvis fornuftig \u00e5 ha en slags \u2026<\/p>\n","protected":false},"author":1,"featured_media":209172,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_wp_rev_ctl_limit":""},"categories":[213,265,96,57],"tags":[],"class_list":["post-257570","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-koding","category-psykologi","category-seo-og-markedsforing","category-web-og-wordpress"],"_links":{"self":[{"href":"https:\/\/inform.click\/no\/wp-json\/wp\/v2\/posts\/257570","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/inform.click\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/inform.click\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/inform.click\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/inform.click\/no\/wp-json\/wp\/v2\/comments?post=257570"}],"version-history":[{"count":0,"href":"https:\/\/inform.click\/no\/wp-json\/wp\/v2\/posts\/257570\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/inform.click\/no\/wp-json\/wp\/v2\/media\/209172"}],"wp:attachment":[{"href":"https:\/\/inform.click\/no\/wp-json\/wp\/v2\/media?parent=257570"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/inform.click\/no\/wp-json\/wp\/v2\/categories?post=257570"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/inform.click\/no\/wp-json\/wp\/v2\/tags?post=257570"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}