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


Gå til bund
Gravatar

#1 arne_v 29. aug. 2019 14:50

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#2 Claus Jørgensen 31. aug. 2019 18:02

Tydeligvis skrevet af udviklere der aldrig arbejder med UI, suk.

Det er skørt hvordan industrien ikke vil tage højde for UI, selvom det er der hvor der er flest problemer med arkitektur, test og kode kvalitet
Gravatar

#3 arne_v 31. aug. 2019 18:39

#2

Der er (uheldigvis) en vis tradition for at man blandt udviklere opfatter:

backend = mere avanceret / krævende / fint
frontend = mindre avanceret / krævende / fint

Formentligt primært af historiske årsager.

For 30-60 år siden var:

frontend = terminal interface og rapporter for linieprinter
backend = en masse DIY kode for at håndtere samtidighed, transaktioner og persistering

Men idag er meget backend udvikling trivielt, fordi der er frameworks til at håndtere samtidighed, transaktioner og persistering. Mens GUIøs er blevet meget avancerede.

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#4 larsp 1. sep. 2019 09:44

Claus Jørgensen (2) skrev:
Tydeligvis skrevet af udviklere der aldrig arbejder med UI, suk.

Det er skørt hvordan industrien ikke vil tage højde for UI, selvom det er der hvor der er flest problemer med arkitektur, test og kode kvalitet

Passer deres "kode-råd" da ikke til UI? Den UI kodning jeg har prøvede sidst krævede i meget høj grad en god struktur og objektorientering for ikke at eksplodere i crap og gentagelser (joystick + LCD gui)

Jeg synes umiddelbart rådene er gode. Der sker tit det at man koder noget sjusket først for at prøve koncepterne af, for derefter at refaktorere det til at blive solidt og ordenligt. Hvis man skipper refaktoreringen og lader den sjuskede kode blive opbygger man en teknisk gæld.
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#5 Claus Jørgensen 1. sep. 2019 17:26

#4

Deres linjenumre er til grin. Men v2 er jo ekstra bladet for IT, så det giver mening.
Gravatar

#6 Claus Jørgensen 1. sep. 2019 17:34

Eksempel: https://github.com/clausjoergensen/TodoApp/blob/ma...

Sikker progrsmmering med null checks og early returns gør hurtigt metoder længere end 5 linjer
Gravatar

#7 arne_v 1. sep. 2019 17:59

#5 og #6

De siger 15 linier ikke 5 linier.

Og det er ikke så forskelligt fra gængse anbefaleringer som McConnell eller Martin.

PS: Dit link virker ikke. Private repo??
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#8 Claus Jørgensen 1. sep. 2019 18:02

ah, typisk, mit eneste private repo som eksempel

Jeg finder et andet i morgen når jeg er hjemme igen
Gravatar

#9 larsp 1. sep. 2019 18:29

De 15 linjer for funktioner formoder jeg hentyder til lines of logic, ikke faktiske linjer. Det er dog stadig ret snævert, enig.

Max fire parametre til funktioner, og max 4 forgreninger... tja, det kan også hurtigt blive snævert.

Men idéen er vel at man sætter en grænse et sted så tingene ikke stikker af fuldstændig, og det synes jeg er en god idé. ...givet at det er bløde grænser man kan overskride når det er nødvendigt. Regelfascisme er aldrig godt, heller ikke i kode ;)
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#10 brostenen 1. sep. 2019 19:54

Claus Jørgensen (5) skrev:
#4

Deres linjenumre er til grin. Men v2 er jo ekstra bladet for IT, så det giver mening.


Jeg er ikke programmør. Men din sammenligning er spot on, og fik mig til at smile. Fuck ekstrabladet. Det er jo ikke andet end blod/vold/sex for de mindre begavede.
Min blog: http://to9xct.blogspot.com

001100 010010 011110 100001 101101 110011

Glad og tilfreds Linux desktop bruger.
Gravatar

#11 arne_v 1. sep. 2019 19:55

#9

En regel "du må ikke" er næppe godt for den slags.

Men der er to andre ting de kan bruges til:

funktion X overtræder => ekstra code review af funktion X

Kode kvalitet udfra statistik: hvis en høj procentdel af alle funktioner er lange, så er der noget galt med kode kvaliteten.

Eksempel: 10000 funktioner hvor 500 er på mere end 50 linier. Der er noget galt. Hvis der kun er 10 funktioner som er mere end 50 linier, så behøver der ikke være noget galt.


The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#12 demolition 2. sep. 2019 08:43

larsp (9) skrev:
De 15 linjer for funktioner formoder jeg hentyder til lines of logic, ikke faktiske linjer. Det er dog stadig ret snævert, enig.

Nu mener jeg også at de går efter at mindst 85% af funktionerne skal være på maks. 15 linjer, så det er ikke en hård grænse. Derfor synes jeg det giver nogenlunde mening, selv om jeg også synes at de er lidt for firkantede på nogle områder. Kildekode bliver aldrig 100% elegant og nemt at gennemskue og vedligeholde. Et stykke software der er i brug vil konstant blive tilpasset nogle nye omstændigheder, så det skal ses lidt som værende et levende væsen. Vi mennesker går også rundt med affalds-gener som måske havde en funktion engang, men som ikke længere giver mening, og sådan er det bare.
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login