Skip to end of metadata
Go to start of metadata

Arkitekter hater dette, right?

Arkitektens favorittalternativer:

  1. Enterprise Rules Engine
  2. 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
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. May 20, 2009

    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...

  2. May 20, 2009

    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.

  3. May 20, 2009

    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

  4. May 20, 2009

    Den som ikke kjenner seg igjen i dette kommer aldri til å bli utvikler.

  5. May 20, 2009

    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

  6. Sep 24, 2009

    Er ikke problemet egentlig at vi mangler erfaring på hvilke parametre produksjon- og testmiljø faktisk ønsker å endre på?

    1. Sep 24, 2009

      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...)

      1. Sep 24, 2009

        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".