mboost-dp1
SXC - clix
Windcape (31) skrev:arne_v (28) skrev:
IoC er et glimrende koncept. Men har det en målbar positiv effekt på software udvikling?
Hvis de ikke har nogen, hvorfor benytter vi det så?
Der må være et kick et eller andet sted. Men uden erfaring fra entreprise løsninger hvor det benyttes, kan jeg ikke sige om der er målbare effekter.
Personligt synes jeg bare det giver renere kode, mindre side-effekter, og nemmere fejlhåndtering. Hvilket kan være et plus, afhængig af projekts kompleksitet.
IoC er ufatteligt populært i Java kredse, fordi der er 2003-2004 blev hypet helt vildt.
Der er sådan set ikke noget galt med IoC. Det er et glimrende koncept. Jeg anbefaler det selv til brug mellem forskellige layers. Ikke bare i Java men også i .NET (hvor IoC aldrig har opnået samme udbredelse som i Java).
Men det har aldrig tilnærmelsesvist leveret de fordele som blev lovet.
Og gevindster på måske 0% / 2% (udvikling/vedligehold) er meget svære at måle.
Og det er også et koncept som ikke skal misbruges - det er ikke en erstatning for new operatoren.
#effekter af forskellige ting
USAF har udgivet en lille bog omkring software estimation som kan hentes her:
http://www.stsc.hill.af.mil/consulting/sw_estimati...
Jeg har leget lidt med at implementere nogle af formlerne i et estimations program. Ikke specielt nyt - det er gjordt mange gange før.
Men hvis man leger lidt med det kan man se effekten af forskellige ændringer for en tilfældigt valgt projekt størrelse:
text editor -> GUI IDE : 889 MM -> 753 MM
average -> good BA & developer : 889 MM -> 477 MM
CMMI level 1 -> CMMI level 5 : 889 MM -> 635 MM
skifte process & tools hvert år -> ikke skifte : 889 MM -> 755 MM
multi location multi timezone -> single location : 889 MM -> 714 MM
Nu er den slags estimatiosn formler jo tildels ren tal magi, men jeg synes faktisk at tallene virker troværdige.
De vigtigste faktorer for prisen på software udviking er:
1) kvaliteten af folkene
2) udviklings processen
3) colocation af folkene
4 & 5) miljø stabilitet & tools
USAF har udgivet en lille bog omkring software estimation som kan hentes her:
http://www.stsc.hill.af.mil/consulting/sw_estimati...
Jeg har leget lidt med at implementere nogle af formlerne i et estimations program. Ikke specielt nyt - det er gjordt mange gange før.
Men hvis man leger lidt med det kan man se effekten af forskellige ændringer for en tilfældigt valgt projekt størrelse:
text editor -> GUI IDE : 889 MM -> 753 MM
average -> good BA & developer : 889 MM -> 477 MM
CMMI level 1 -> CMMI level 5 : 889 MM -> 635 MM
skifte process & tools hvert år -> ikke skifte : 889 MM -> 755 MM
multi location multi timezone -> single location : 889 MM -> 714 MM
Nu er den slags estimatiosn formler jo tildels ren tal magi, men jeg synes faktisk at tallene virker troværdige.
De vigtigste faktorer for prisen på software udviking er:
1) kvaliteten af folkene
2) udviklings processen
3) colocation af folkene
4 & 5) miljø stabilitet & tools
#9: Du behøver ikke skriveLinkedList<WhateverObject> ll = new LinkedList<WhateverObject>(). Det tilsvarende udtryk i Haskell eller enhver ML-variant er:
let ll = []
Statiske typer != eksplicitte typer. Et sprog kan sagtens være både meget kompakt at skrive i og statisk typet på samme tid.
let ll = []
Statiske typer != eksplicitte typer. Et sprog kan sagtens være både meget kompakt at skrive i og statisk typet på samme tid.
Et blogindlæg af Torben Mogensen
Han foreslår flere domænespecifikke sprog (naturligvis, han underviser jo i den slags)
Han foreslår flere domænespecifikke sprog (naturligvis, han underviser jo i den slags)
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
- ⟨
- Nyheder
Gå til bund