mboost-dp1
Software udvikling og godt håndværk
http://www.version2.dk/artikel/ekspert-danske-udvi...
http://www.version2.dk/artikel/saadan-fik-kmd-fejl...
Hoved pointen om at det er bedre at finde fejl tidligt har jo været kendt i uendeligt mange år, så det synes jeg ikke er interessant.
Men den sekundære pointe at danske udviklere generelt ikke er gode håndværkere er lidt interessant.
http://www.version2.dk/artikel/saadan-fik-kmd-fejl...
Hoved pointen om at det er bedre at finde fejl tidligt har jo været kendt i uendeligt mange år, så det synes jeg ikke er interessant.
Men den sekundære pointe at danske udviklere generelt ikke er gode håndværkere er lidt interessant.
artiklen skrev:Det er god skik at unit-teste al kode, altså sikre at hver en stump løser sin opgave rigtigt, men alligevel sker det ofte alt for tilfældigt, forklarer konsulenten.
Jeg er uenig, det er ofte spild af tid at lave unit tests på objekt/funktions niveau.
Hvis vi f.eks. har en funktion der beregner gennemsnittet på et array af integers, der vil crashe hvis at en integer er = 65537, men det andetsteds i applikation bliver valideret at alle integers er < 65537 kan en udvikler bruge masser af tid på at skrive en test der fremkalder fejlen, og validere at funktionen failer gracefully, til ingen verdens nytte.
Det handler mere om user story baserede test cases, helst automatiseret.
På den måde bliver hele samspillet af alle komponenter testet på en mere realistisk måde, og man undgår at skrive ligegyldige tests.
Men pointen om at gode udviklere er essentielle er korrekt(surprise?)
artiklen skrev:. Et andet indsatsområde er for eksempel at skifte vandfaldsmodellen ud med agil udvikling. Kort fortalt handler det om at dele opgaverne op i små, afsluttede bidder og løbende tilpasse systemet til kundens krav.
No shit sherlock? Har du nogensinde hørte nogen sige "Vi laver det her med vandfalds modellen, og hvis kunden ikke kan lide det laver vi det hele om"
artiklen skrev:»Agil udvikling i form af Scrum hjælper på at få den rigtige løsning. Men skal man nærme sig fejlfri og vedligeholdelsesvenlig kode, skal der også fokus på mere basale best practices inden for software engineering,«
Scrum kan aldrigt redde et projekt fra dårlige udviklere- en dårlig udviklings practice kan ødelægge et projekt- men en god udviklings metode kan aldrigt redde et projekt fra dårlige udviklere.
I det hele taget er det en meget intet sigende artikel hvis pointe er pretty much common knowledge.
Præcis.Mamad (moveax1ret) (2) skrev:Scrum kan aldrigt redde et projekt fra dårlige udviklere
Uden gode udviklere, og strenge regler for kvalitet (af kode, og test tilhørende koden), og et højt seriøsitetsniveau, kan et projekt aldrig blive en success.
På mit arbejde er niveauet enormt højt, og kvaliteten tilsvarende.
Mamad (moveax1ret) (2) skrev:No shit sherlock?
Mamad (moveax1ret) (2) skrev:I det hele taget er det en meget intet sigende artikel hvis pointe er pretty much common knowledge.
Det forsøgte jeg også at kommunikere med:
arne_v (1) skrev:Hoved pointen om at det er bedre at finde fejl tidligt har jo været kendt i uendeligt mange år, så det synes jeg ikke er interessant.
Mamad (moveax1ret) (2) skrev:Jeg er uenig, det er ofte spild af tid at lave unit tests på objekt/funktions niveau.
Hvis vi f.eks. har en funktion der beregner gennemsnittet på et array af integers, der vil crashe hvis at en integer er = 65537, men det andetsteds i applikation bliver valideret at alle integers er < 65537 kan en udvikler bruge masser af tid på at skrive en test der fremkalder fejlen, og validere at funktionen failer gracefully, til ingen verdens nytte.
Jeg er ikke helt enig.
Typisk business kode har det med at leve meget længe.
Det er ikke urealistisk at have en forventet leve tid for ny kode på 15-30 år.
Meget kan ændre sig over så mange år.
Jeg vil derfor være meget forsigtig med "det er ikke nødvendigt at teste for X fordi den kaldende kode allerede tester for det".
Det gør den måske nok idag. Men hvad er den kaldende kode om 15-30 år??
arne_v (7) skrev:Det gør den måske nok idag. Men hvad er den kaldende kode om 15-30 år?
Min erfaring er at hvis en funktion eller et objekt vil give god mening i mere end ét projekt, er der allerede et API der kan genbruges.
Det meste kode man bliver nødt til selv at skrive giver oftest kun mening i det aktuelle projekt.
Dog er det noget andet hvis vi laver et libary, så har du naturligtvis ret.
Men i en typisk enterprice applikation giver meget lidt kode mening at genbruge uden for kontekst.
Men altså, selvfølgeligt er mere testing altid bedre, men når en projekt leder skal prioritere udviklers tidsbrug må man ofte være streng.
Tests kan kun bruges til visse ting, man kan f.eks. ikke lave unit test der fanger at en j2ee servlet outputter javascript der ikke kan parses af safari.
Der er intet der slår ægte mennesker, der gør de ting brugerne vil gøre.
Jeg ved ikke hvilken sektor din erfaring angående at kode bliver kaldt af andet kode 15-30 år efter stammer fra.....Bank verden?
Hvis noget skal nedprioriteres i et projekt er loose coupling et oplagt sted for mig. Programmører har det med at overdrive konceptet fordi det har de lært på deres uddannelse.
Mamad (moveax1ret) (8) skrev:Det meste kode man bliver nødt til selv at skrive giver oftest kun mening i det aktuelle projekt.
Mamad (moveax1ret) (8) skrev:Men i en typisk enterprice applikation giver meget lidt kode mening at genbruge uden for kontekst.
Noget giver det mening at genbruge.
Og noget bliver genbrugt selvom det ikke giver mening at genbruge.
Mamad (moveax1ret) (8) skrev:Jeg ved ikke hvilken sektor din erfaring angående at kode bliver kaldt af andet kode 15-30 år efter stammer fra.....Bank verden?
Det er ret udbredt.
Frontend kode bliver hyppigt lavet om, men backend kode lever meget længe.
Koden bliver ikke erstattet men udvidet med ny funktionalitet.
Der er 2 gode grunde til ikke at skrive det om:
- det koster penge
- en omskrivning vil introducere fejl som det vil tag tid og besvær at få fjernet igen
Virksomheder vil hellere bruge penge på ny funktionalitet som giver værdi end på at omskrive noget som (stort set) virker.
Der er omkring 250 milliarder linier COBOl og der tilføjes 5 nye hvert år.
Og det er ikke kun COBOL.
COBOL og PL/I kode fra 70erne og 80erne.
C og C++ kode fra 80erne og 90erne.
Java kode fra 00erne.
O.s.v..
Bankerne er meget kendte for det.
Men det findes også hos diverse industri og handelsvirksomheder.
Eksempel som var fremme for nyligt:
http://www.version2.dk/artikel/tudsegammelt-it-sys...
De gængse OS er 20-40 år gamle.
De gængse databaser er 15-30 år gamle.
Mamad (moveax1ret) (8) skrev:Hvis noget skal nedprioriteres i et projekt er loose coupling et oplagt sted for mig. Programmører har det med at overdrive konceptet fordi det har de lært på deres uddannelse.
Jeg er ikke helt enig.
Der er måske ikke fordele her og nu.
Men fordelene viser sig hvis koden skal genbruges langt ud i fremtiden.
Det kan også tit vise sig at være overkompliceret design, hvor små ændringer kræver enorme gentagelser i koden.arne_v (11) skrev:Men fordelene viser sig hvis koden skal genbruges langt ud i fremtiden.
Specielt når folk forsøger at designe til programmeringssproget. Java udviklere er notorisk gode til at overdrive med facades, factories og andre anti-patterns, for at overkomplicere deres kode, i forhold til projekter som f.eks. er skrevet i python eller erlang.
Windcape (12) skrev:Det kan også tit vise sig at være overkompliceret design, hvor små ændringer kræver enorme gentagelser i koden.
Decoupling (og andre goodies) skal føre til mindre arbejde ved ændringer.
Håbløst design påklistret en decoupling (eller anden etiket) kan naturligvis godt give mere arbejde.
Windcape (12) skrev:Specielt når folk forsøger at designe til programmeringssproget. Java udviklere er notorisk gode til at overdrive med facades, factories og andre anti-patterns, for at overkomplicere deres kode, i forhold til projekter som f.eks. er skrevet i python eller erlang.
Facade og factory er ikke anti patterns.
YAGNI versus alle kendte best practices er en kendt diskussion. Jeg er nok ikke spcielt YAGNI orienteret. Netop fordi konteksten kan ændre sig over softwarens løbetid og visse ændringer er meget dyre og/eller risikable at lave senere.
Jeg tror at der er to grunde til at du ser simplere løsninger i Python end i Java:
1) Dynamic typed sprog kommer med en vis indbygget decoupling som gør at visse practices kendt fra static typed sprog ikke er nødvendige.
2) Der er langt færre Python udviklere end Java udviklere som sidder og maintainer gammel kode og har store problemer p.g.a. designet
Windcape (15) skrev:Hele snakken om at "genbruge" kode er fjollet, specielt hvis man laver specialiserede produkter.
Så er IT industrien vist generelt ret fjollet. Det er almindligt at ønske at genbruge kode på tværs af platforme, versioner og produkter. Også selvom det er specialiserede produkter.
Windcape (15) skrev:Samt I dag handler det om "testability", og ikke "reuseability".
Tror jeg ikke har ret meget med virkeligheden at gøre.
Ønske, ja.arne_v (16) skrev:Det er almindligt at ønske at genbruge kode på tværs af platforme, versioner og produkter.
Det sker sjællent i praksis.
Måske i din virkelighed. Den er ret langt fra min.arne_v (16) skrev:Tror jeg ikke har ret meget med virkeligheden at gøre.
Windcape (17) skrev:Ønske, ja.
Det sker sjællent i praksis.
Windcape (17) skrev:Måske i din virkelighed. Den er ret langt fra min
Nu lige for at få et par ting på plads, du er fra 86, du er næsten nyuddannet, dvs. hvis du har været aktiv på arbejdsmarkedet så lad os antage det giver 3-5 år effektivt,
Arne_v har i følge hans CV arbejdet med det siden 87, hvilket giver ca. lige så mange år som du er gammel.
Nok er erfaring ikke alt, men lad dog være med at være så bedre vidende!
Jeg er yngre end dig og jeg har arbejdet et sted hvor fokus har været på at genbruge det kode man skrev for 5 år siden fordi det har vist sig at virke og er efterprøvet, og det på trods af at produkterne ligger meget langt fra hinanden og de nye udviklere skulle sætte sig ind i det.
Windcape (15) skrev:#14
Overengineering er altid et problem. Specielt i static typed sprog.
Hele snakken om at "genbruge" kode er fjollet, specielt hvis man laver specialiserede produkter.
Samt I dag handler det om "testability", og ikke "reuseability".
Som ikke udvikler undrer jeg mig over at man ikke har fokus på reuseability. Ville det ikke alt andet lige være billigere at genbruge kode hvor det giver mening?
Jo, selvfølgelig.Hubert (20) skrev:Ville det ikke alt andet lige være billigere at genbruge kode hvor det giver mening?
Men f.eks. apps til mobiler, vil mindst 50% være så applikations-specifikt, at det ikke giver mening at fokusere på reuseability.
Testability er et bedre fokus, da det tvinger løs-kobling, hvilket i sidste ende også gør det nemmere at genbruge komponenter.
At snakke om at skrive enhver klasse, så den kan genbruges, er en fjollet tankegang fra 90erne, hvor man ikke skrev så meget forskelligt kode.
Det *primære* fokus er maintainability. Og derefter testability.
F.eks. er det meningsløst at DanID forsøger at skrive NemID så alle enkelte dele kan genbruges i andre projekter, da sandsynligheden er lig nul. Det er bedre at de fokusere på at skrive noget kode der kan maintaines i 20 år, uden at folk skal bruge dag og nat på at forstå koden.
På Kamstrup tog det måneder at komme ind i et meget simplere produkt. Hos Skype, tog det cirka. 2 dage før vi var produktive.
Bankerne sender folk på 3 måneders kurser før de kan lave de mindste ændringer, og folk er vel generelt ikke produktive før 6-12 måneder efter de blev ansat.
Hvis KMD laver så overkomplicerede produkter, at de ikke kan hente nye folk ind midt i forløbet, og have dem være effiktive i løbet af et par dage, så er det jo klart at de fejler.
offtopic:
Jeg havde aldrigt troet at jeg ville være mere enig med windscape end arne_v i en diskussion :p
Jeg havde aldrigt troet at jeg ville være mere enig med windscape end arne_v i en diskussion :p
Windcape (17) skrev:
Ønske, ja.
Det sker sjællent i praksis.
Der er flere forskellige former for genbrug.
a) Traditionel PP/OOP kode genbrug hvor et generelt library genbruges af vidt forskellige apps.
Det har vel vist sig vanskeligere at gøre end man forestillede sig tilbage i 70'erne og 80'erne.
Men hvis man sammenligner Java lib, .NET lib, PHP lib, C++ boost etc. med ISO/ANSI C, ISO/ANSI Pascal, ISO/ANSI Cobol, ISO/ANSI Fortran så ser man at brugen af generelle libraries er vokset kraftigt.
Erfaringen er bare at det kræver meget at lave et godt genbrugeligt library og de færreste firmaer gør det for ren in house brug.
b) Genbrug af systemer (SOA).
SOA har ikke vist resultater som matcher hypen.
Men konceptet er alligevel blevet ganske almindeligt.
c) Uplanlagt genbrug af specifik app kode.
Et system får en meget længere levetid end oprindeligt planlagt og bliver integreret med andre systemer på måder som ikke var en del af det oprindelige design.
Og det er så almindeligt.
Man omskriver sjældent backend kode. I stedetfor så tilføjer man ny kode, opdaterer platform, putter nye GUI's foran, integrerer med andre systemer etc..
Windcape (17) skrev:Måske i din virkelighed. Den er ret langt fra min.
Windcape (19) skrev:Men jeg arbejder i en anden virksomhedskultur end arne_v, med et helt andet produkt-fokus end arne_v.
Der er forskel på hvad man arbejder med.
Traditionelt bliver frontend kode oftere erstattet fremfor udvidet mens backend kode oftere bliver udvidet fremfor erstattet.
Og så er der spørgsmålet om hvor produkterne er i deres livs cyklus.
Du arbejder meget med smartphone apps.
Det er jo åbenlyst at du sidder ikke med noget 10 år gammel eksisterende kode og bander over designet. Fordi det er nye produkter.
Men kan der godt sidde nogen om 10 år og bande over det design du laver nu!!
Windcape (21) skrev:Men f.eks. apps til mobiler, vil mindst 50% være så applikations-specifikt, at det ikke giver mening at fokusere på reuseability.
Og her fosser der et større antal spildte milliarder dollars ud i de kommende årtier.
Det kan godt være at en pæn del af koden for app X kun giver mening for app X.
Men genbrug er ikke kun mellem app X og app Y.
Genbrug er også mellem version N og version N+D af app X.
Genbrug er også mellem app X på platform AB og app X på platform BA.
Genbrug er også mellem app X og varianten app X*.
Genbrug er også mellem app X og app XY som indeholder både X og Y.
Netop.arne_v (24) skrev:Erfaringen er bare at det kræver meget at lave et godt genbrugeligt library og de færreste firmaer gør det for ren in house brug.
Du assumere at man altid har backend kode.arne_v (24) skrev:Man omskriver sjældent backend kode. I stedetfor så tilføjer man ny kode, opdaterer platform, putter nye GUI's foran, integrerer med andre systemer etc..
Jeg er ikke enig.
Vi bander også over design-fejl, men i hver produktcyklus bruger vi lang tid på omskrive kode, hvis det er nødvendigt.arne_v (25) skrev:Det er jo åbenlyst at du sidder ikke med noget 10 år gammel eksisterende kode og bander over designet. Fordi det er nye produkter.
Det er faktisk et *krav* fra management. Vi *skal* refactor kode.
Mobility er stadigvæk en for ung platform til at være værd at investere tid i at generalisere funktionalitet på.arne_v (26) skrev:Og her fosser der et større antal spildte milliarder dollars ud i de kommende årtier.
Det er normalt at der er *breaking changes* mellem versioner, hvilket gør det meget mere agilt, og meget anderledes end f.eks. at skrive software til bankverdenen, hvor alting har været bagudkompatibelt i 40 år.
Hvad kalder du en kommunikations-client der er baseret på peer2peer?-)arne_v (29) skrev:Man har stort set altid backend kode.
Derudover så synes hele definitionen af frontend og backend at være utrolig gammeldags.
Web og Mobility gør grænsen meget meget mere flydende, end ved traditionelle apps.
Windcape (30) skrev:Hvad kalder du en kommunikations-client der er baseret på peer2peer?
Sådan en er vel ligesom alle mulige andre programmer.
En frontend med et UI og en backend for resten.
Hvis du specifikt tænker på Skype, så vil jeg opdele:
frontend - GUI, interface højtalere/mikrofon/webcam
backend - low level protokol, high level protokol, supernode funktionalitet
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