Sådan bestemmer du teknisk gæld i dine systemer

Kodeanalyse rangerer vedligeholdelsesbyrden for et system og hjælper blandt andet med beslutninger om modernisering kontra nyudvikling.

I Version2's artikel-serie om modernisering kontra nyudvikling har vi ofte brugt begrebet 'teknisk gæld' uden at have en klar definition af, hvad teknisk gæld er, og hvordan man egentlig kan opgøre mængden af teknisk gæld i et system.

Bevares, vi har henvist til både Howard Cunninghams og Martin Fowlers beskrivelse af begrebet, men hvordan finder man ud af, hvor stor den tekniske gæld er i et givent system?

Principper for god kode

Hos Kombit har man siden december 2018 været i gang med at finde svaret på det spørgsmål.

Kommunernes it-fællesskab anvender nemlig et system, der analyserer kodekvaliteten i it-systemer.

Hvis kvaliteten af koden er lav, vil den tekniske gæld være stor.

Det er Software Improvement Groups Sigrid-platform, som Kombit de seneste otte måneder har anvendt til at måle softwarekvaliteten i 14 systemer udviklet af leverandører til Kombit.

»Vi indkøber store it-systemer til anvendelse i kommunerne, og sommetider kan der være problemer med softwarekvaliteten. Vi ønskede et værktøj, der kunne give os et indblik i, hvad det er, leverandørerne leverer,« fortæller Jan Dynnesen, it-arkitekt hos Kombit.

Sigrid analyserer et systems kildekode ud fra otte faktorer, som baserer sig på veletablerede principper for god kode.

Metoder/funktioner bør eksempelvis ikke være længere end 15 linjer, metoder/funktioner bør ikke være for komplekse, og softwarearkitekturen bør bestå af løst koblede komponenter (se boksen ’Gode koderåd’ for en liste over principper for god softwarekvalitet).

På baggrund af kodeanalysen udregnes en score, og systemets overordnede kodekvalitet tildeles en stjernemarkering, hvor 1 stjerne tildeles systemer med lavest kodekvalitet, og 5 stjerner systemer med den bedste kvalitet i koden.

Transparens og dialog

Jan Dynnesen understreger, at kvalitetsmålingerne ikke skal bruges til at slå leverandørerne i hovedet, men skal være med til at skabe en dialog om projekternes fremdrift og prioritering.

»Kvalitetsscoren bliver brugt som udgangspunkt for en konstruktiv dialog og en måde at få mere transparens om softwarekvalitet på. Det kan bruges sammen med leverandøren til at prioritere udviklingen. Hvis en leverandør leverer dårlig softwarekvalitet, er det ikke nødvendigvis leverandørens skyld,« siger Dynnesen og fortsætter:

»Vi kan måske have en masse ændringskrav, processer, der forhindrer leverandøren i at levere det optimale, meget rigide dokumentationskrav og andet, der begrænser udviklernes produktivitet. Det er vigtigt for os at vide, så vi kan adressere eventuelle problemer vi har hos os selv.«

Modtagelsen af kvalitetsmålingerne blandt leverandørerne har været blandet.

»Nogle leverandører har været meget positive, andre har været negative, og nogle har været neutrale – de anvender ofte selv lignende værktøjer til at måle softwarekvalitet,« siger Jan Dynnesen.

Kan softwarekvalitet måles?

Nogle af leverandørernes udviklere har stillet spørgsmål til, om alt vedrørende softwarekvalitet kan måles, og om kriterierne for god kode også er rimelige.

»De fleste godtager kriterierne, men nogle brokker sig eksempelvis over, hvor mange linjer en metode højst bør have. Der er også dem, der siger, at softwarekvalitet består af andre ting end dem, vi måler. Det kan være korrekt brug af design patterns, den rigtige anvendelse af en given teknologi og lignende. Det er sandt, men vi har brug for en objektiv måde at måle på, og det her er den bedste, vi har,« siger Jan Dynnesen.

En konsistent kodeevaluering

En veldefineret og konsistent måling af softwarekvaliteten er vigtig for Kombit.

»Vi har prøvet at have en tredjepart inde og vurdere kodekvalitet, men det var en subjektiv evaluering, så det kunne altid diskuteres. Hvis en tredjeparts-kodeekspert vurderede, at koden ikke var af høj kvalitet, så kunne leverandøren argumentere for det modsatte. Med de otte objektive kriterier er der ingen diskussion. Du får altid den samme score for den samme kildekode. Du kan selvfølgelig altid diskutere, om kriterierne er retfærdige, men da de er baseret på veletablerede principper for god kode, så er det svært at argumentere for, at en lav score betyder, at din kode har en høj kvalitet,« forklarer Jan Dynnesen.

De 14 systemer, der for tiden monitoreres, er skrevet i C#, Java og en enkelt i ABAP, som er sproget i SAP-løsninger.

Over 4.000 systemer som reference

Det giver kvalitets-scoren pondus, at scoren sammenholdes med en benchmark, der er etableret på baggrund af kodeanalyser for kørende systemer verden over.

Senior Management Consultant hos Software Improvement Group Nordic Rasmus Petersen forklarer:

»Vi har indsamlet data fra over 4.000 systemer verden over. og vi bruger en delmængde af dem til at etablere en benchmark.«

Software Improvement Group inddrager kun data til benchmarken fra systemer, der stadig er i drift.

5 procent af systemerne rangeres lavest med 1 stjerne, mens 5 procent får den bedste rangering med 5 stjerner. De resterende rangeringer med 2, 3, og 4 stjerner udgør hver især 30 procent.

Ifølge Software Improvement Group er det dobbelt så hurtigt at lave ændringer og udvidelser i systemer med en firestjernet kodekvalitet som i systemer med en tostjernet kvalitet.

Hvert år bliver benchmarken justeret efter de seneste målinger, og der sker som regel en lille forbedring.

I bogen ’Building Maintainable Software’ af Joost Visser fra Software Improvement Group hedder det om de årlige benchmarkændringer: »Det er ikke de store ændringer. Overordnet set er det en tiendedel af en stjerne per år.«

Den lille kvalitetsstigning betyder, at kravene til stjernemarkeringerne også langsomt strammes, så det eksempelvis bliver lidt sværere at opnå et 4-stjernet kvalitetsstempel.

Softwarekvalitet verden over

Benchmark-målingerne kan ses som en indikator for softwarekvaliteten globalt set, dog mest i store organisationer og virksomheder, da det oftest er den type virksomheder, der anvender Software Improvement Groups kodeanalyse.

I bogen ’Building Maintainable Software’ fra 2015 hedder det om softwarekvalitet:

»Hos SIG (Software Improvement Group, red.) har vi set systemer, som basalt set ikke er til at vedligeholde. I de systemer bliver bugs ikke rettet og funktionaliteten ikke ændret eller udvidet, fordi det tager for meget tid og er for risikabelt. Desværre er det noget, som ses alt for tit i dagens it-industri, men det behøves ikke at være sådan.«

Hvis der kun sker små gradvise ændringer er det vel også tilfældet i dag?

»Ja, jeg er ked af at sige det, men situationen er stadig den samme. Dog er høj softwarekvalitet begyndt at blive et successkriterium, som softwarekøbere lægger vægt på, og i fremtiden vil højkvalitetssoftware med lave vedligeholdelsesomkostninger blive en nøglekonkurrenceparameter,« vurderer Rasmus Petersen.

Hvad koster vedligehold fremover?

Software Improvement Groups værktøjer kan estimere de totale vedligeholdelsesomkostninger fremover på baggrund af systemets kodetilstand sammenlignet med virksomhedens benchmark fra andre projekter.

Der udregnes en Total Cost of Ownership (TCO) med konkrete tal på, hvad det vil koste at refaktorere og vedligeholde et eksisterende system. På den baggrund kan man vurdere, om der skal bygges nyt, eller om man skal videreudvikle det gamle system.

Hverken Kombit eller Software Improvement Group ønsker at udtale sig om nuværende eller tidligere projekters kodekvalitet, men Version2 har før berettet om, hvordan Software Improvement Group betegnede Domstolsstyrelsens Juridiske Fagsystemer som et meget komplekst system, der ikke burde sættes i drift grundet forventede store TCO-omkostninger..

Når projekter ikke lytter

Version2 har også tidligere rapporteret om Software Improvement Groups kvalitetstjek af koden til Skats skandaleramte EFI-system. Et kvalitetstjek, som blev ignoreret:

»Kvalitetssikring af koden har ingen effekt. SIG, som på ugentlig basis maskinelt kvalitetssikrer den udarbejdede programmeringskode med rapportering til leverandørerne, melder om et voksende antal brud på retningslinjerne for programmering foretaget af KMD og CSC. Men begge leverandører har gennem længere tid ignoreret de ugentlige rapporter fra SIG, som blot kasseres uden læsning,« som Version2 kunne fortælle i 2016 på baggrund af en aktindsigt i en rapport fra PA Consulting.

Skat accepterede, at leverandørerne skulle ignorere kvalitetstjekket af koden. Af rapporten fremgik det videre:

»CSC og deres underleverandører er principielt uenige med SIG omkring anvendeligheden af SIG's værktøjer og analyser, hvorfor dialogen parterne imellem er ophørt, og CSC har fra Skat fået accept af dette.«

Proaktivt vedligehold

I de seneste tre-fire år har Kombit anvendt Software Improvement Group og andre uafhængige eksperter til enkeltstående reviews af projekter, men det er først de seneste otte måneder, at Kombit er begyndt at anvende kvalitetstjekket mere proaktivt, idet Jan Dynnesen og hans kollegaer sammen med leverandørerne løbende kan følge med i kodekvalitetens udvikling.

»Her er det mere proaktivt, da vi monitorerer koden fra uge til uge og identificerer trends, så hvis et projekt af en eller anden årsag begynder at få dårlig kodekvalitet, så kan vi gøre noget ved det, inden det bliver et problem,« siger Jan Dynnesen.

Igen understreger han, at leverandørerne ikke skal se monitoreringen af kodekvalitet som noget negativt:

»Vi holder kurser for leverandørerne, hvor de bliver undervist i, hvordan de kan bruge Sigrid-platformen i deres dialog med os. De kan dokumentere en korrekt leverance, høj kodekvalitet og dokumentere, at de arbejder på ting, som vi har bedt dem om. Hvis vi eksempelvis har bedt om en ændring, der bliver dyrere, end vi havde regnet med, så kan de dokumentere, at koden, som skulle ændres, måske var meget kompleks og derfor tog ekstra lang tid at ændre,« siger Jan Dynnesen.

Udviklerproduktivitet og TCO

Systemet giver også mulighed for at estimere udviklerproduktivitet, ligesom det giver mulighed for Kombit at prioritere ressourcer på tværs af projekter i Kombits portefølje.

»Vi har et råt estimat for, hvor mange kodelinjer en udvikler kan skrive om dagen, baseret på data fra flere tusinde projekter. Det kan bruges til at udregne udviklingstiden for et system i mandår. Vi kan sammenligne systemerne med hinanden og prioritere udviklingen af systemerne,« siger Dynnesen og fortsætter:

»Projektejerne kan lave budgetestimering baseret på TCO for et projekt samt for hele projektporteføljen for de næste ti år. Det er en god ting ved projektudbud.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (33)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Povl H. Pedersen

Personligt synes jeg 15 linier og 4 branches er for lidt, og noget der løbende overskrides når jeg som hobbykoder skriver programmer. På den anden side har jeg ikke mange funktioner på 30-60 linier.

Hvor vedligeholdelsesvenlig kode er er ikke kun afhængigt af længden og antal branches.

Og hvis man måles på det, så skriver man mere kompakt og vanskeligere at læse kode.

Bedre at bruge et par linier ekstra og gøre det let at læse. Og krydre med en kommentar hist og her - håber ikke det tæller med, ligesom block start/ends {} heller ikke bør gør det. Ingen ønsker at {} rykkes op på samme linie som kode.

  • 12
  • 0
Peter Valdemar Mørch

Er der ikke værktøjer som kan refaktorere kode automatisk så man kommer ned på meget små metoder med intetsigende navne?

Kunne man feks lave Java pseudo source ud fra Java bytekoden som garanteret var ret lille, og hvor alle variable var felter i en datastruktur?

Så ville man kunne få fem stjerner selv med skodkode! 😎 Også selvom denne source er komplet ubrugelig.

  • 6
  • 0
Michael Cederberg

Der er ingen tvivl om at mange værktøjer til statisk kodeanalyse leverer fine resultater i det fleste tilfælde. Problemet er bare at outputtet alt for ofte bruges som KPI til ledere og det er det simpelthen ikke godt nok til. For når først ledelsen har valgt et givent niveau, så bliver alle bedt om at opfylde det uanset at det i nogle tilfælde leder til ringere kodekvalitet. Der er ingen mulighed for at argumentere mod toolet - selv når det går galt i byen.

Et eksempel er max. længde for metoder. Vi kan godt blive enige om at metoder generelt ikke skal være lange. Men i nogle få tilfælde kan metoder på 200-300 linjer faktisk give mening - specielt hvis det bliver sværere at læse når koden splittes op i mindre.

Vigtigere: Statisk kodeanalyse ser kun på en meget lille del af teknisk gæld. Som andre har argumenteret for, så er der en række områder som ikke dækkes. Mit eget favoritområde er arkitektur. Her er ingen hjælp overhovedet. Jeg har set løsninger som var håbløse rent arkitektonisk men som fik top-score i kode-analysen. Og omvendt.

Når en organisation har kørt med KPI'er på kodeanalyse i et par år, så er alle systemer blevet optimeret i forhold til at maximere KPI'et. Uden at der er blevet brugt tid på at løse mere grundlæggende problemer. Og uden at det har given nogen reel værdi.

  • 11
  • 0
Jonas Høgh

Vigtigere: Statisk kodeanalyse ser kun på en meget lille del af teknisk gæld. Som andre har argumenteret for, så er der en række områder som ikke dækkes. Mit eget favoritområde er arkitektur. Her er ingen hjælp overhovedet. Jeg har set løsninger som var håbløse rent arkitektonisk men som fik top-score i kode-analysen. Og omvendt.


Nu er arkitektur jo et ret overloadet begreb, så det er svært at vide hvad du præcist mener her. Men jeg synes nu at fx et analyseværktøj som NDepend har ret gode indikatorer for arkitektonisk gæld. Fx ting som moduler, der er koblet til et højt antal andre moduler, cykliske afhængigheder mellem moduler, osv.

  • 0
  • 0
Peter Valdemar Mørch

Hvis man virkeligt vil måle teknisk gæld, så er det ikke ligegyldigt hvor i source koden man kigger.

Skodkode (som definineret ovenfor) som bliver kørt ofte i runtime og som har kørt upåklageligt siden 2003 uden en eneste bugreport eller et eneste commit ud over det oprindelige har meget mindre teknisk gæld end kode som køres sjældent, som der oftes ændres i (af en eller anden grund man bør undersøge) og som har 203848 bug reports henover tid.

Når jeg tænker på vores egen kodebase, er der områder som er "pæne" jfr. analyse men som stadig virkeligt trænger til en overhaling da det grundlæggende er designet og lavet forkert, og andet kode der bare har virket fint i årevis selv med adskillige TODO:-s :-)

Men i mangel af bedre kan dette fint være én kilde til at måle kvaliteten - det kan bare ikke stå alene.

En anden superstærk indikator må da være test coverage...

  • 6
  • 0
Lars Bendix

Personligt synes jeg 15 linier og 4 branches er for lidt, og noget der løbende overskrides når jeg som hobbykoder skriver programmer. På den anden side har jeg ikke mange funktioner på 30-60 linier.

Hvor vedligeholdelsesvenlig kode er er ikke kun afhængigt af længden og antal branches.

Det er helt sikkert godt at have nogle retningslinier - og i visse tilfælde bliver koden også mere vedligeholdelsesvenlig ved at med måde bryde disse retningslinier.

Og det er jo nok "i visse tilfælde" og "med måde" der volder problemer, når man blander automatiske metrikker ind i det. Og i sidste ende er det jo heller ikke de programmer der skal vedligeholde koden - det er kollegerne. Så det bedste må vel være at spørge kollegerne - altså at lave code reviews med det formål at se om en kollega skulle kunne vedligeholde denne kode. Det burde ikke tage mere end fem minutter for ham/hende at afgøre.

Men det giver selvfølgelig ikke noget tal til DJØF'erne - og siger ikke noget om hvor meget teknisk gæld man har fået oparbejdet i kodebasen, hvis/når man nu ikke har arbejdet pro-aktivt.

  • 1
  • 0
Rasmus Petersen

Hej Povl H Pedersen,

Mange tak for din kommentarer vedr. grænseværdierne for unit size i vores kvalitetsmodel.

Vores risiko profil for unit size er som det fremgår af infoboksen i artiklen inddelt i fire kategorier: 1-15 linier kode, 16-30 linier kode, 31-60 linier kode, og >60 linier kode.

Lav risiko kategorien er ganske rigtigt 1-15 linier kode, og vi er enige om at det ikke er muligt for samtlige units i et stort system der anvender mange forskellige teknologier. Og det er faktisk også muligt at få en over markedsgennemsnittet vurdering (4 stjerner) med blandt andet 42 procent af dine linier i 16-30 linier kode kategorien som det er angivet i artiklens info boks.

Jeg håber det svarer på dit spørgsmål?

Mvh
Rasmus

  • 0
  • 1
Michael Cederberg

Nu er arkitektur jo et ret overloadet begreb, så det er svært at vide hvad du præcist mener her. Men jeg synes nu at fx et analyseværktøj som NDepend har ret gode indikatorer for arkitektonisk gæld. Fx ting som moduler, der er koblet til et højt antal andre moduler, cykliske afhængigheder mellem moduler, osv.

Du har ret i at arkitektur er meget overloadet. Men de ting du peger på er sjældent det der har den store betydning når det gælder teknisk gæld (selvom de godt kan indikere andre problemer).

Hvis man svarer nej til et af følgende spørgsmål så kan det være tegn på teknisk gæld (alt efter hvilken verden man bevæger sig i):

  • Har systemet en arkitektur der tillader det at scalere fornuftigt med arbejdsmængden?
  • Hvad sker der når kravene udviddes på en rimelig og til dels forudsigelig måde ... hvor stor en del af systemet skal så laves om?
  • Er der en fornuftig opdeling af funktionalitet?
  • Kan man forstå dele af systemet, uden at forstå det hele?
  • Kan vi genbruge dele af koden til noget andet uden at skulle lave for meget om?
  • Er valg om sikkerhed og tillid fornuftige i systemets kontekst?
  • etc. etc

Ovenstående er ikke egnet til objektive metrikker (á lá statisk kodeanalyse), men betyder efter min mening meget mere end mere simple metrikker. Så hvis man som Kombis tror at man kan få et overblik over teknisk gæld med de metoder de bruger, så snyder man sig selv. Desværre er folk ofte ligeglade fordi det blot handler om at finde et målbart KPI for IT folks arbejde og systemers udførelse.

Historien vist at hvis man styrer vha. de gale KPI'er så ender det ofte galt (LoC giver voluminøs kode, antal traktorer leveret giver traktorer leveret i lav kvalitet, etc.). Desværre er mange organisationer i praksis ligeglade fordi alle blot forsøger optimere egne metrikker og der er intet metrik der handler om at slå dårlige metrikker ihjel. I tilfældet kombis har nogen sikkert fortalt ledelsen at de nemt og billigt kan vurdere teknisk gæld på hele kodebasen uden at behøve at sætte sig ind i hvad den laver, hvad kravene er, etc.

  • 3
  • 0
Kim Henriksen

Jeg arbejder med udvikling til hverdag, men er ikke uddannet på nogen måde.

Men her er mit besyv - jeg syntes ofte at hvis koden er dårlig formateret, så det svært for andre end programmøren selv at vedligeholde den - hvis tingene er pænt formateret, indeholder kommnetarer osv, så er det ikke svært for andre at sætte sig ind i det.

  • DET er for mig teknisk gæld - kan jeg vedligeholde det eller ej.
  • 3
  • 1
Malik Taaning

"When a measure becomes a target, it ceases to be a good measure" - Goodhart's law

Hvis en køber begynder at måle på denne måde så er de i stor risiko for at ødelægge mere end de redder.

En hver inkompetent leverandør der i forvejen kæmper med kodekvalitet kan jo bare lave en intern regel der sikrer at metoder på over 15 linjer bliver delt i flere

metodeX -> metodeX_part1, metodeX_part2, metodeX_part3

Det er fint at bruge de metrikker som guidelines - men at bruge dem som krav giver ringe eller ingen værdi.

Som jeg ser det ville det give langt større værdi hvis man stillede kravet til sin leverandør at de selv internt skulle måle og sætte ambitioner om deres kodekvalitet og så ellers i udbudsmaterialet rent faktisk vægtede kvalitet og ikke kun pris

https://en.wikipedia.org/wiki/Goodhart%27s_law

  • 8
  • 0
Magnus Jørgensen

Jeg har her en simpel function

def parent(self, child: QModelIndex) -> QModelIndex:  
    if not child.isValid():  
        return QModelIndex()  
    model_item = child.internalPointer()  
    try:  
        if model_item is None:  
            return QModelIndex()  
        elif model_item == self._root_item:  
            return QModelIndex()  
        else:  
            parent_item = model_item.parent()  
            if parent_item is not None:  
                elder_item = parent_item.parent()  
                if elder_item is not None:  
                    row = elder_item.children().index(parent_item)  
                else:  
                    row = 0  
                return self.createIndex(row, 0, parent_item)  
    except Exception as e:  
        print(str(e))  
    return QModelIndex()

20 linier kode. Hvordan giver det mening at denne function skulle være for lang?

  • 0
  • 0
Sune Marcher

Bum bum, jeg ved ikke om den metode er for lang, men ude af kontekst er den ikke-triviel.

Der ser ud til at være mutable state involveret, index/createIndex, som vi ikke kender til, er ikke noget der lyder som om det kunne have side effects, og ikke noget jeg umiddelbart ville forvente i en func/meth med navnet "parent".

Et hurtigt gæt ud fra layout og navngivning er det er noget med Python og Qt at gøre (anede ikke der var Qt bindings til Python, men det undrede mig ikke) - min erfaring med begge dele er begrænset, så stærkere domæneviden i begge ville klart hjælpe...

Men ren læsning uden kontekst er det ikke simpelt. Og det er nok et ret godt argument for at det er decideret latterligt at sætte KPI'er op ud fra et statisk analyseværktøj - uanfægtet at analyseværktøjer kan være utroligt værdifulde for os udviklere.

  • 2
  • 0
Martin Storgaard Dieu

Hvordan giver det mening at denne function skulle være for lang?


Som Sune Marcher, så har jeg ikke domænekendskab nok. Men for mig ligner det at alle steder der returnere QModelIndex() er guards. I så fald kan de flyttes ud i en decorator. Det der så er tilbage er den egentlige logik for at finde parent. Jeg tror også at hvis du kører den igennem statisk kodeanalyse at den vil brokke sig over at du har en catch all.

  • 0
  • 0
Jonas Høgh

Hvad mener du?


Jeg mener, at din kodestil er inkonsistent. I den første if/elif/else udpensler du de to forskellige måder hvor vores søgen efter parent kan fejle, og returnerer eksplicit. Hvis du gik efter mere koncis kode kunne du have inverteret betingelserne, kombineret dem med and, og kun bibeholdt else grenen. Senere udelader du else og lader det hermed være underforstået at vi skal ned til den sidste return.

Jeg ved godt det er super pedantisk, men hvis det var professionel kode, som skulle overdrages til vedligehold hos et andet udviklingshold eller lignende, er det værd at huske på, at der kun skal et par if-sætninger til, før en, der læser koden for første gang kan blive forvirret.

  • 0
  • 0
Jonas Høgh

I så fald kan de flyttes ud i en decorator


Det giver vel kun mening, hvis vi kan tillade os at kalde .parent() flere gange uden at det går ud over performance (jeg kender heller ikke Qt, så det vil jeg ikke spå om). Jeg er heller ikke sikker på jeg synes det øger læsbarheden.

Det ville være bedre at bruge et sprog med en Option-type, eller et UI-bibliotek, der er ikke er så gammeldags som Qt, så vi slet ikke behøver fedte med den slags detaljer som metoden her.

  • 0
  • 0
Magnus Jørgensen

Tak for input Jonas Høgh:

def parent(self, child: QModelIndex) -> QModelIndex:  
    if child.isValid():  
        model_item = child.internalPointer()  
        if model_item is not None and model_item is not self._root_item:                
            parent_item = model_item.parent()  
            if parent_item is not None:  
                elder_item = parent_item.parent()  
                if elder_item is not None:  
                    row = elder_item.children().index(parent_item)  
                else:  
                    row = 0  
                return self.createIndex(row, 0, parent_item)  
    return QModelIndex()

Det er både mere konsistent og nu nede på 12 linier.

  • 2
  • 0
Magnus Jørgensen

Meget muligt, men kan du ikke i klartale fortælle hvad dens formål er, i stedet for at man skal prøve at dechifrere din kode?

QAbstractItemModel bruges normalt til at modellere data modellen bag et treeview. Conceptet bygger på Model View Controller paragdimet. I min kode bruger jeg det til at vise referencerne til de billeder man tagger med personers ansigter og med et valgfrit categori system.
treeview
parent functionen er en virtual funktion der skal overrides for at treeview fungere. Hvordan du opstiller din model er kun begrænset til at forælder/barn forholdene bibeholdes.

  • 1
  • 0
Jens Villadsen

Statisk kodeanalyse skal bruges til statisk kodeanalyse, og er blot et af mange værktøjer som bør indgå i en helt almindelige CD/CI pipeline, og jeg har svært ved at se undskyldninger for ikke at gøre dette. Som udgangspunkt kan f.eks. SonarQube tages ned fra hylden der allerede understøtter bl.a. Java (including Android), C#, PHP, JavaScript, TypeScript, C/C++, Ruby, Kotlin, Go, COBOL - og dette kan gøres gratis, kvit og frit - og er et udmærket værktøj at danne diskussioner mellem udviklere. At andre end udviklere vælger at fortolke dette, bør stå helt for egen regning. Held og lykke med at konvertere det til KPI'er

  • 0
  • 0
Log ind eller Opret konto for at kommentere