mboost-dp1
Sådan bestemmer du teknisk gæld i dine systemer
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
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
#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.
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.
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.
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
Sikker progrsmmering med null checks og early returns gør hurtigt metoder længere end 5 linjer
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 ;)
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 ;)
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.
#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.
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.
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.
Ja, det er det helt rigtige valg! Jeg tror, at hvis du tilføjer mere på nuværende tidspunkt vil spørgsmålet om penge meget https://inkasso.com/ let blive afsluttet. Jeg håber på deres forståelse, og især i betragtning af, at dette er et avanceret produkt-jeg tror på dem!
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.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund