Arkitekter hater dette, right?
Arkitektens favorittalternativer:
- Enterprise Rules Engine
- Just Configure It!
Og, da ender vi jo lett opp slik:
Noen som føler seg truffet? Varmer opp til Geek Cruise til helgen
Ref:
Labels:
None
8 Comments
comments.show.hideMay 20, 2009
Leif Auke
På ingen måte
men hvis parametern er å betrakte som en del av programmet. DVS alltid den samme, eller en del av logikken i programmet så gjelder motsatt regel. Da hardkoder vi. Probelemet blir da å vurdere hvor man raskest finner hvor man skal endre. Hvis endring (av parameter) alikevel er en del av en programendring er det bedre å hardkode, så slipper man å forholde seg til parameterfiler i 'hytt og pine', så konklusjonen er avhengig av kontekst og formål ....
ellers benytter jeg den praksis å definere parameterobjekter som serialiseres direkte ut og inn ved oppstart eller når de skal benyttes. For å skryte av .net så har den full støtte for serialisering av objekter uten noe dikedarier...
May 20, 2009
Leif Auke
Du snakker om serialisering. Jeg laget et system for et par år siden med utelukkende seialiserte objekter som datalager i et system av XML filer. Det er egentelig en ok strategi noen ganger, særlig nå datamodellen endrer seg under utviklingen. Starte med et serialisert objektlag, som siden evt. impl. inn i database når alt er stabilt.
May 20, 2009
Mads Nissen
representerer ihvertfall ikke favorittalternativene til denne arkitekten
det interessante i forhold til bruk av f.eks. en rules engine eller wf engine er jo endrings-, og vedlikeholdsscenariene. i dette ligger det at endring og vedlikehold må være enkelt effektivt og sikkert (ikke krasje noe). XML manifester vil aldri nå opp på disse kriteriene uansett
Xml'en i dette eksempelet er kode, med eneste forskjell at den bare kan testes med å eksekveres i prod:-P
May 20, 2009
Kjetil Valstadsve
Den som ikke kjenner seg igjen i dette kommer aldri til å bli utvikler.
May 20, 2009
Leif Auke
Nå skal ikke jeg starte noen slåsskamp om dette
haha.. og poenget om man skal betrakte en regel som kode eller parameter er viktig poeng (egentlig). Overparameterisering kan være minst like forvirrende og vanskeelig å vedlikeholde som hardkoding i et program. Poenget er; hvis man samtidig som man må endre parametere også må inn i koden for å endre logikken, da er det ikke en parameter men en del av koden og det blir en smaksak hvor man ønsker å legge reglene eller hvilke kodeellementer man har. (om det er XML eller kodelinjer). Men det er da en god regel å samle reglene mest mulig i samme boksen av hensyn til fremtidig vedlikehold. Autonome classer 
Sep 24, 2009
Bård Lind
Er ikke problemet egentlig at vi mangler erfaring på hvilke parametre produksjon- og testmiljø faktisk ønsker å endre på?
Sep 24, 2009
Thor Henning Hetland
Mangler vilje eller evne? Og event hva gjør man hvis man mangler erfaringen, er vel kanskje gode spørsmål?
(Tips: det er lov å snakke med driftere...)
Sep 24, 2009
Bård Lind
Driftere er en god kilde, og en nødvendig kilde. Desverre er det ofte vanskelig å få tak i disse resursene.
Produkteier er også en viktig kilde å spørre.
Hva jeg hadde håpet var at noen kunne lage en liste over dette "typiske" paramtre som faktisk blir endret i prod.
Ofte opplever jeg soft-koding som et resultat av at "jeg vet ikke hva som skal endres, men håper de parametrene jeg leverer med vil avhjelpe fremtidig drift og utvikling".