Arbetsmarknad för scala-utvecklare ?
Tomas Johansson
än så länge verkar det inte direkt finnas någon arbetsmarknad för
utvecklare som är intresserad av scala...
Jag gjorde alldeles nyss några sökningar på scala-jobb i sverige på
jobsafari och monster.se och f.n. finns det näst intill inga jobb alls
(monster hade en enda jobb-annons där scala nämndes som ett av några
språk).
Utomlands verkar inte situationen så mycket bättre. På jobserve.com
fanns det just nu 4 annonser (av 10665 st. "IT-jobb") med jobb i
London där scala nämndes.
En scala-fritextsökning på monster.com för USA resulterade i endast 11
träffar.
Finns det någon här kanske som kan peka på några tydliga tecken på att
situationen kommer att förändras inom de närmaste åren... ?
Det jag är ute efter är egentligen att försöka ta ställning till om
det värt besväret att fördjupa sig i ett språk som sannolikt aldrig
kommer att bli något annat än ett minoritetsspråk.
Jag tycker visserligen att scala verkar vara väldigt bra, men om det
inte blir någon arbetsmarknad för det så finns det ju en hel del andra
saker som man skulle kunna välja att lägga sin energi på i stället...
Självklart finns det ingen annan här som kan svara på om det någonsin
kommer att slå igenom på allvar eller inte, men kanske ändå finns
någon intressant synpunkt som talar för att det kommer att göra det...
Som ett exempel kan jag själv nämna att James Gosling lär ha sagt
(enligt baksidan på boken "Programming in Scala") att "If I were to
pick a language to use today other than java, it would be scala".
Ett sådant faktum kanske skulle kunna påverka vissa tveksamma
beslutsfattare i rätt riktning, så att säga ...
och kanske finns det några andra "kändisar" som har uttalat sig
tydligt positivt om scala, eller finns det kanske något stort känt
företag som har offentliggjort att de har för avsikt att satsa stort
på scala-utveckling...?
Jonas Bonér
Andra som anvander Scala i prod:
* SAP
* Siemens
* Sony
* LinkedIn
* Twitter
* EDF Trading
* Xerox
* plus flera mindre foretag
Scala kommer att sla, det kan jag satta mitt huvud pa. Det ar det anda
spraket som kan utmana Java pa allvar.
Jag har under hosten nu haft 7 interna foretagskurser i Scala. Allt
mellan 1/2 - 3 dagarskurser.
/Jonas
2009/12/29 Tomas Johansson <dddsv...@oo-systemutvecklare.se>:
> --
>
> Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Groups.
> Om du vill göra ett inlägg i den här gruppen skickar du e-post till scala-...@googlegroups.com.
> Om du vill sluta prenumerera på den här gruppen skickar du e-post till scala-sverig...@googlegroups.com.
> För fler alternativ, besök gruppen på http://groups.google.com/group/scala-sverige?hl=sv.
>
>
>
--
Jonas Bonér
twitter: @jboner
blog: http://jonasboner.com
work: http://scalablesolutions.se
code: http://github.com/jboner
code: http://akkasource.org
also: http://letitcrash.com
Enno Runne
Det är visserligen så att Scala inte dyker upp i jobbannonser ännu och jag kan tänka mig att det tar en eller två år till.
Precis som Jonas är jag ganska säker på att Scala kommer att ta över efter Java, men än så länge vågar mycket få företag ta det steget officiellt. Scala är på många sätt en mindre förändring av "tänket" än vad de andra språken på JVM:en innebär. Hela ekosystemet av driftsmiljöer, applikationsserver, utvecklingscykel och inte minst ramverk förblir detsamma. Sedan är det ju oftast så i vår bransch att personalavdelningen inte blir dem första som vet att teknikutvecklingen har gått vidare...
Men sedan kan det förstås vara så att någon hittar en annan - eventuellt mer lättillgänglig - paketering av fördelarna som Scala medför och den tar över. Det viktiga för dig bör inte vara att lära dig Scala, utan att lära dig koncepten som gör Scala till vad det är idag. Scala är inte svår - det är kombinationen av programmeringskoncepten som är utmaningen. Precis som folk någon gång i tiden tyckte att objektorientering verkar jättekrånglig...
Genom att lära dig Scala blir du en bättre Java-, C#- eller Xyz-programmerare!
Enno.
--
Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Groups.
Om du vill göra ett inlägg i den här gruppen skickar du e-post till scala-...@googlegroups.com.
Om du vill sluta prenumerera på den här gruppen skickar du e-post till scala-sverig...@googlegroups.com.
För fler alternativ, besök gruppen på http://groups.google.com/group/scala-sverige?hl=sv.
--
en...@runne.net
John Nilsson
Jan Kronquist
att det utvecklar mig som programmerare och att det funkar tillsammans
med existerande verktyg (tex maven). Oavsett vilket språk som blir
stort i framtiden kan jag redan nu komma igång att använda mixins,
funktionell programmering etc. En bonus är förståss att Scala är
vackert och roligt att programmera i!
Såklart finns det massa annat att lägga sin tid på än
programmeringsspråk, men om du vill lära dig ett nytt
programmeringsspråk, vilket annat språk skulle du välja?
/Jan
2009/12/29 Enno Runne <en...@runne.net>:
Niclas Nilsson
> programmeringsspråk, men om du vill lära dig ett nytt
> programmeringsspråk, vilket annat språk skulle du välja?
Den andra "extremen" - ett dynamiskt språk?
Jag tycker personligen att båda extremerna (med representanter som
Haskell i ena änden och Lisp i andra) är intressanta, men av lite
olika anledningar.
Mvh
Niclas
Viktor Klang
Jag håller med! Det viktiga för mig varför jag lär mig Scala är främst
att det utvecklar mig som programmerare och att det funkar tillsammans
med existerande verktyg (tex maven). Oavsett vilket språk som blir
stort i framtiden kan jag redan nu komma igång att använda mixins,
funktionell programmering etc. En bonus är förståss att Scala är
vackert och roligt att programmera i!
Såklart finns det massa annat att lägga sin tid på än
programmeringsspråk, men om du vill lära dig ett nytt
programmeringsspråk, vilket annat språk skulle du välja?
Clojure! :-)
Så får Niclas sin dos dynamic typing också ;-)
--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall
Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang
Niclas Nilsson
Clojure! :-)
Så får Niclas sin dos dynamic typing också ;-)
2009/12/30 Jan Kronquist <jan.kr...@gmail.com>Jag håller med! Det viktiga för mig varför jag lär mig Scala är främst
att det utvecklar mig som programmerare och att det funkar tillsammans
med existerande verktyg (tex maven). Oavsett vilket språk som blir
stort i framtiden kan jag redan nu komma igång att använda mixins,
funktionell programmering etc. En bonus är förståss att Scala är
vackert och roligt att programmera i!
Såklart finns det massa annat att lägga sin tid på än
programmeringsspråk, men om du vill lära dig ett nytt
programmeringsspråk, vilket annat språk skulle du välja?
Jonas Bonér
Joakim Ohlrogge
-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN
Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
E-mail: joakim....@agical.se
Niclas Nilsson
On 30 dec 2009, at 15.46, Jonas Bonér <jbo...@gmail.com> wrote
> eval stavas val evil?
Nejdå. Du kan se det som (loadtime / runtime) byte code manipulation -
fast enkelt... ;-)
Mvh
Niclas
>> scala-...@googlegroups.com.
>> Om du vill sluta prenumerera på den här gruppen skickar du e-post
>> till
>> scala-sverig...@googlegroups.com.
>> För fler alternativ, besök gruppen på
>> http://groups.google.com/group/scala-sverige?hl=sv.
>>
>
>
>
> --
> Jonas Bonér
>
> twitter: @jboner
> blog: http://jonasboner.com
> work: http://scalablesolutions.se
> code: http://github.com/jboner
> code: http://akkasource.org
> also: http://letitcrash.com
>
> --
>
> Det här meddelandet skickas till dig eftersom du prenumererar på gru
> ppen scala-sverige i Google Groups.
> Om du vill göra ett inlägg i den här gruppen skickar du e-post till scala-sverige@googlegroups.
> com.
> Om du vill sluta prenumerera på den här gruppen skickar du e-post ti
> ll scala-sverig...@googlegroups.com.
John Nilsson
Jag tycker personligen att båda extremerna (med representanter som
Haskell i ena änden och Lisp i andra) är intressanta, men av lite
olika anledningar.
Niclas Nilsson
som främst skiljer Scala från Java; den funktionella approachen och
ett riktigt statiskt typsystem (istället för Javas låtsasstatiska),
och skalas "motsats" ser jag då som ett språk med liknande approach
men med ett riktigt dynamiskt typsystem.
Prolog vore nog dags igen, för det fick jag aldrig skallen runt när
jag pluggade. men nu ser jag användningsområdena (men förstår inte
tänket).
Mvh
Niclas
2009/12/30 John Nilsson <jo...@milsson.nu>:
Andreas Källberg
Johan Näsman
Jag tror att det är otroligt viktigt att folk inser att steget
(investeringsmässigt) inte blir för stort.
Det stora steget är att övertyga & utbilda folk i att bygga rätt. Helt
övertygad om att man kan
bygga fel i Scala. Det kan man i alla språk.
Vi kommer att göra en satsning på Scala. Vi är övertygade att det är
en av de troligaste
kandidaterna, men jag tror att det kommer att ta tid. Men tiden är
"early adopters - mature".
Helt klart.
Egentligen, vad är grundproblemet? Java eller hur vi bygger appar /
kompetens? Lurigt.
/Johan N
2009/12/30 Andreas Källberg <andreas....@gmail.com>:
--
Regards,
Johan Näsman
Mobile: +46 (0)70 508 7477
johan....@jayway.se
johan....@gmail.com
http://www.jayway.se
http://www.waygroup.se
http://www.linkedin.com/in/jnasman
John Nilsson
Egentligen, vad är grundproblemet? Java eller hur vi bygger appar /
kompetens? Lurigt.
Per Arneng
Risken med scala tror jag är att det är för kraftfullt vilket kommer leda till legacy
kod som är väldigt svår att hantera:
http://blog.fogus.me/2009/03/26/baysick-a-scala-dsl-implementing-basic/
Man kan skapa skit-kod i alla programmering språk men ju kraftfullare språk man
har desto mer olika sätt finns det att skapa ounderhållbar kod.
Java är väldigt verbose:t, explicit och oflexibelt men det är ganska lätt att
läsa Java spagetti-kod eftersom det är mycket WSIWYG över koden.
Personligen gillar jag Scala och programmerar hellre i det än Java men
efter att ha jobbat en del med legacy system i olika språk har jag fått
förståelse för hur viktigt det är att skriva kod som är lätt att underhålla
och lätt att läsa.
Ett av designmålen med Java är:
Primary characteristics of the Java programming language include a simple language that can be programmedMan har ju haft helt andra design mål med Scala. Man måste komma ihåg att
without extensive programmer training while being attuned to current software practices. The fundamental concepts
of Java technology are grasped quickly; programmers can be productive from the very beginning
http://java.sun.com/docs/white/langenv/Intro.doc2.html
alla programmerare har inte programmering som hobby och engagerar sig inte
i att lära sig hur man använder ett språk eller verktyg på bästa sätt. Det finns
också dom som är väldigt skickliga programmerare som skapar eleganta lösningar
men det är omöjligt/svårt för medel-programmeraren att förstå dessa lösningar
och därför för svårt att underhålla koden.
Så jag är lite kluven i om det är en bra ide att ersätta Java med Scala.
Mvh
Per
--
Niclas Nilsson
> Vad som förhoppningsvis kommer att hända är att Clojure forsätter utveckla viktiga insikter och lösningar på aktuella problem. Scala kommer lära folk programmera i en funktionell stil, samt att använda de kraftfulla modulariseringsmöjligheterna som Scala erbjuder. Haskell communityn kommer fortsätta upptäcka matematiskt intressanta egenskaper att bygga kraftfulla abstraktioner på. JVM:en kommer utvecklas till att effektivt optimera även funktionella program.
Tittar man på historien så tror jag tyvärr inte det kommer bli så bra.
När man tittar på "snittkod" (d.v.s. inte gjort av de mest
intresserade 5-10%:en utvecklare) i exempelvis Java så är det
fantastiskt vad lite OO principer som faktiskt används. Folk
programmerar mest imperativt i objektorienterade mainstreamspråk. Att
det var så förr när folk kom från Basic, Pascal, C och VB till C++,
Java och C# kan jag förstå, men även de som lärt sig ett OO-språk som
första språk verkar ändå "programmera Basic" i Java och C#. Det får
mig att tro att Scala inte kommer lära "folk" programmera i
funktionell stil speciellt mycket, utan de kommer sannolikt använda
Scala som ett mindre brusigt imperativt språk med lite
inkapslingsinslag om/när Scala blir mainstream. Många open source
ramverk (skrivet av entusiaster) kommer däremot alldeles säkert
påverkas mycket och bli väldigt mycket mer funktionella.
Det enda jag kan tänka mig som skulle ändra den hittills historiska
trenden är om de stora leverantörerna inte lyckas lösa "automatisk
parallellism" på iallafall ett halvdant sätt, så folk slipper tänka så
mycket på det. Skulle det misslyckas kanske väldigt många utvecklare
blir tvingade att lära sig tänka mer funktionellt, men om det händer
kommer det inte hända innan folk inte har något som helst val (d.v.s.
när varje dator har massvis med långsamma kärnor) och MS Research
m.fl. misslyckats med sina försök att lösa det med verktygen.
> Summan av dessa utvecklingar kommer förhoppningsvis resultera i att om typ 5-år så kan vi alla börja lära oss ett programmeringsspråk som låter oss ta ett rejält kliv i vår förmåga att hantera komplexitet.
Jag önskar verkligen att du har rätt.
Mvh
Niclas
Joakim Ohlrogge
-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN
Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
E-mail: joakim....@agical.se
Jonas Bonér
amen
2009/12/31 Joakim Ohlrogge <joakim....@gmail.com>:
--
Niclas Nilsson
Jag tror Michael har rätt på ett plan, men kanske ser det lite snävt
(i just detta uttalandet). Det finns och måste få finnas olika slags
programmering. Idag är det alldeles för vanligt att det är ungefär
"jämntjockt" (jämnsvårt? jämnkomplext?) i ett system. Jag räknar just
nu bort de saker man står på (OR-mappare och annat), utan det jag
menar är inom kodbasen företaget själv skapat.
Jag tror att man måste erkänna skillnader och inse att man behöver ha
några riktigt bra utvecklare som gör tämligen komplexa saker för att
underlätta för många andra. På "toppen" bör det vara så enkelt att
nästan "vem som helst" bör kunna skriva kod, men det är också ganska
små mängder relativt sett och all tekniskt mumbojumbo skall inte synas
(tänk DSL:er exempelvis, men också UI-nära, peka-klicka saker och
andra saker som är nära affärsregler och flöden). Därmed är det kod
där du glatt kan kasta och göra om när kraven ändras utan att det är
ett problem med "den stora investeringen vi gjort". Dessa kodrader är
mer av kategorin att det kan ta två långa möten med kunden för att
fatta hur en stackars rad skall se ut, och sedan tar det 2 min att
skriva den och testa den (iallafall manuellt).
Vi behöver hantera komplexitet på ett annat sätt än vi gör nu av många
skäl, och gör vi det kommer det också kunna utkristallisera sig en
roll man mer kan kalla "subject matter expert programmerare" eller
"business programmer" eller liknande, och där kan vi ha andra slags
krav. De skall aldrig behöva ens veta att det finns flera kärnor eller
kanske ens maskiner inblandade i systemet för att ta ett exempel.
Tänker jag helt galet eller är det någon annan som tänkt liknande banor?
Gott nytt på er alla geeks! Skönt att ni finns!
Mvh
Niclas
2009/12/31 Jonas Bonér <jbo...@gmail.com>:
Per Arneng
Closures är ju just en sådan sak som faktiskt kommer till Java av anledningen att det gör koden mycket lättare att läsa och hantera
om man jämför med interna anonyma klasser. Det är ju sjävlklart så att vad man tycker är lätt eller svårt är beroende på vem man
är och vad man har för bakgrund men oavsett vad man tycker så är just ett av dom viktigaste designmålen i Java att det skall vara
lätt för "average joe" att förstå. Detta är antagligen en av anledningarna att det är så populärt.
Håller med om att man bör anställa bra programmerare men det är nog ganska svårt om man inte får se någon form av portfolio
eller arbetsprov för alla kan skriva att dom kan Java, C eller annat språk men det är ju en enorm skillnad om man är bra eller dålig
och det är svårt att veta innan man sett koden som produceras.
Så länge som "kreti och pleti" står för majoriteten av alla som producerar kod i företag idag så tror jag att det är bra att anpassa sig
efter dom alternativt ha hårdare anställningskrav men då skulle vi snabbt få ännu mer brist på programmerare och fler jobb skulle
outsourcas.
Mvh
Per
Peter Lewerin
> det var baske mig det finaste jag har hort sedan konfirmationen
> amen
>
> 2009/12/31 Joakim Ohlrogge <joakim....@gmail.com>:
>
flera fina po�nger. Inte minst d� att Java inte p� n�got vis �r ett
"l�tt" spr�k. Ett exempel som blivit aktuellt f�r mig �r n�r jag
�vers�tter Processing-kod (som visserligen inte �r detsamma som
Java-kod, bara n�stan helt och h�llet) till Scala. Det �r skillnad som
natt och dag. Scala g�r det l�ttare att uttrycka sig, l�ttare att
utl�sa vad som h�nder, och g�r det utan att ta ifr�n den kunniga
programmeraren hennes verktyg.
Viktor Klang
+1000
On Dec 31, 2009 2:48 PM, "Jonas Bonér" <jbo...@gmail.com> wrote:
det var baske mig det finaste jag har hort sedan konfirmationen
amen
2009/12/31 Joakim Ohlrogge <joakim....@gmail.com>:
> Jag hör ofta argumentet om att man ska programmera enkelt (även i Java) för > att programmerare so...
-- Jonas Bonér twitter: @jboner blog: http://jonasboner.com work: http://scalablesolutions.se...
Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Grou...
Tomas Johansson
> ...
> Man kanske inte bör anställa
> programmerare som inte kan prestera underhållsbar kod eller inte förstår att
> läsa kod som faktiskt är underhållsbar?
Ja, jag har själv väldigt länge tyckt att underhållsbarhet är oerhört
viktigt, och den förmågan borde helt klart vara ett viktigt kriterium
vid en anställning, men det känns tyvärr som en väldigt avlägsen dröm
med tanke hur de flesta rekryteringerna brukar gå till.
Alldeles för många företag använder sig av rekryteringsföretag med
näst intill obefintlig (enligt min erarenhet i alla fall) kompetens
(trots att företagsnamnet kan ibland ha ett "IT" som suffix för att
försöka antyda att de har kompetens inom området).
En gång för ganska många år sedan blev jag t.ex. kontaktad av ett
rekryteringsföretag som tyckte att min CV såg intressant ut bortsett
från ett potentiellt bekymmer, nämligen att det inte stod något om
HTML-kunskaper.
Det hade jag medvetet utelämnat från CV:n eftersom jag tyckte det
kändes lite för trivialt att ens nämna HTML när jag bl.a. hade nämnt
ASP, JSP och XHTML.
Det var tydligen feltänkt då man tvingas befatta sig med amatörer som
inte har en aning om t.ex. skillnaden på XML och SQL, och inte duger
till mycket mer än att jämföra exakta bokstavsförkortningar (men html
och xhtml kan tydligen bli för avancerat att skilja på) och försöka
jämföra kandidatens antal årserfarenhet av språk X, ramverk Y,
applikationsserver Z etc.
Dessutom klarar de även av att vid en intervju kontrollera att
kandidaten har välputsade skor och ser generellt välvårdad ut, men det
finns nog inte många på rekryteringsföretagen som är i närheten av att
kunna bedöma en utvecklares kunskaper om förvaltningsbar källkod.
Det baserar jag på min egen erfarenhet, och jag har faktiskt under
årens lopp träffat rekryterare från de flesta av vanligaste
rekryteringsföretagen och det brukar se likadant ut, dvs ingen som
helst spetskompetens inom det aktuella verksamhetsområdet dvs
systemutveckling.
Dock kan eventuellt situationen ha förändrats de senaste två-tre åren
(även om jag tvivlar) eftersom jag succesivt har blivit alltmer
irriterad på de företag som anlitar rekryterinsgföretagen att jag
numera sällan brukar bry mig om att söka sådana jobb, även om
jobbbeskrivningen i princip kan låta intressant ibland.
Anledningen till att jag inte gärna söker jobb där företagen har
anlitat rekryterare är helt enkelt att jag vill jobba tillsammans med
likasinnade (dvs de mest intresserade 5-10%:en utvecklare som Nicas
Nilsson nämnde) och jag har lite svårt att se att sådana personer
(under förutsätning att de har inflytande över rekryteringsprocessen)
vill anlita ett rekryteringsföretag som i princip bara kan servera
kreti och pleti kandidater (såvida de inte av ren tur råkar hitta
någon som faktisk har en seriös kompetens och inte bara välputsade
skor).
Det är f.ö. inte heller bara rekryterinsgföretagen som är dåliga på
rekryteringar, utan många andra verkar också vara beredda att köpa
grisen i säcken, och tror att man automatiskt är kompetent bara för
att man har X antal års erfarenhet av något.
Jag har själv tackat nej till ett erbjudande från ett konsultföretag
för några år sedan just pga att erbjudandet kom så oerhört
lättvindigt, och det kändes som IT-chefen lika gärna ha plockat in vem
som helst från gatan, och ställde knappt några frågor alls till mig,
och ingen fråga över huvud taget som syftade till att försöka
undersöka min kompetens...
Då tänkte jag nämligen att det var stor sannolikhet att kollegorna
(som har blivit rektyterade på samma sätt) tillhör den majoritet som
producerar hemsk ravioli/spagetthi-kod utan något större intresse/
kompetens för långsiktigt förvaltningsbar kod.
On Dec 31, 3:07 pm, Per Arneng <per.arn...@anyplanet.com> wrote:
>
> Håller med om att man bör anställa bra programmerare men det är nog ganska
> svårt om man inte får se någon form av portfolio
> eller arbetsprov för alla kan skriva att dom kan Java, C eller annat språk
> men det är ju en enorm skillnad om man är bra eller dålig
> och det är svårt att veta innan man sett koden som produceras.
Jag är tveksam till att kräva ett omfattande arbetsprov (men de som
gör det borde då åtminstone erbjuda lite betalning som vissa gör) men
tror faktiskt man skulle kunna komma ganska långt med att tillämpa
kodgranskning på en intervju.
Med andra ord skulle man kuna låta kandidaten titta på lite dålig
källkod som inte är bra med avseende på olika aspekter, t.ex. dålig
semantik i typerna/metoderna/variablerna, dålig inkapsling, multipla
likadana if/switch-satser i en klass (istället för att använda
polymorfism med State eller Strategy pattern), duplicering, magic
value, återanvändning av samma variabel men med nytt innehåll längre
ner i metoden, metoder som tar emot en till synes "generell" typ men
som i implementation kräver en specifik (dvs byter mot Liskovs),
metoder som använder HashTabeller (istället för domänobjekt) eller
"Object" i publika metodsignaturer och som måste downcastas till vissa
typer eller hanteras på annat sätt utan intention-revealing
interfaces, high coupling, low cohesion o.s.v. o.s.v.
Det förekommer att vissa företag tillämpar kodgranskning, men i de
fall jag har fått göra det så har det varit relativt få kodexempel,
och jag tycker att en diskssussion om konkreta kodexempel borde
användas i mycket större omfattning i rekryteringar.
Bl.a. för att det helt enkelt är mycket mindre tidskrävande för
kandidaten, men tror också det är lättare att tydligt försöka fånga
upp faktiska kunskaper om olika viktiga aspekter av förvaltningsbar
kod, jämfört med att låta kandidaten skriva egen kod. Jag kan nämligen
tycka att det alltid finns potential för förbättringar, och om man
själv ska skriva kod som skall bedömas så kan det vara svårt att veta
var man skall lägga ribban.
Det är nämligen så att om man gör det lite för snyggt och onödigt
flexibelt så kan man få YAGNI-kommentarer, men å andra sidan om man
inte gör det tillräckligt flexibelt så kan man i stället få
kommentarer om att man i större omfattning faktiskt borde ha lagt in
fler hook points (open-closed principle).
Genom att helt enkelt sitta tillsammans och diskutera kodexempel så
tror jag faktiskt man har goda möjligheter om en utvecklare har det
rätta tänket om vad som gör kod förvaltningsbar/icke-förvaltningsbar.
/ Tomas Johansson
John Nilsson
Tänker jag helt galet eller är det någon annan som tänkt liknande banor?
Joakim Ohlrogge
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN
Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
E-mail: joakim....@agical.se
Joakim Ohlrogge
Joakim Ohlrogge
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN
Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
E-mail: joakim....@agical.se
Joakim Ohlrogge
Niclas Nilsson
> Om vi leker med tanken att man bara kan ha mycket kompetenta programmerare som klarar av att göra hyfsat komplexa saker. Om man vidare tänker att de är kapabla att arbeta tillsammans med den verksamhet de stödjer... varför ska man då ha mindre kompetenta programmerare? Är det en kostnadsfråga? Är det vanliga "grunt-worket" för tråkigt för en sådan mycket kompetent programmerare?
> Jag tänker att det borde vara förmånligt att ha personal som fritt kan röra sig över komplexitet-nivåerna.
>
> Jag kan tänka mig att businessprogrammern är en person som inte kan programmera men som mycket väl skulle kunna läsa kod skriven i en DSL och därmed lätt kunna parprogrammera ihop psudokod/skarp kod med någon som kan programmera. (Det är lättare att förstå ett språk än att tala det)
Vi har eventuellt olika världsbild eftersom jag inte tror att dett du beskriver är möjligt av ett enkelt skäl, och det är det gamla klassiska skälet som du hört till döddagar som svekskäl för allt möjligt, men jag skall iallafall roa dig med att använda det i ett helt annat sammanhang, och skälet är: skalbarhet.
Låt oss leka med tanken att det behövs i vart fall 10x mer mjukvara än de personerna du beskriver ovan kan producera hur mycket flow de än har. Hur löser man det problemet? Min teori är att det behövs väldigt mycket mer mjukvara nu och än mer i framtiden än vad "talangen" räcker till för. Att skapa och implementera kraftfulla och användbara abstraktioner som är enkla att använda (relativt sett och på just axeln abstraktioner) är ganska svårt, men lyckas man bra så skalar det bra, så den koden kan få många "användare".
Det är mycket lättare att lära sig tala ett språk än det är att designa ett språk och i vår värld måste vi dessutom implementera språket och få det att göra intressanta saker med det språket skall användas för att manipulera. Excel är ett lysande exempel, men det finns många saker som är närmare vår egen domän. Ta Rails, Hibernate, PostgreSQL och varför inte Firefox?
Det finns massvis med utvecklare som löser businessproblem ganska smärtfritt med hjälp av Rails - det är antagligen några tusen gånger fler än vad det finns folk som skulle klara av att bygga, eller ens underhålla Rails. Hibernate likaså, många klarar använda det, men många färre skulle gå i land att bygga det. PostgresSQL är antagligen ett ännu extremare exempel. Hur många "yet another report"-SQL-hackers skulle ens veta hur de skulle börja angripa problemet att bygga en relationsdatabas och ett frågespråk? Och HTML skall också produceras, men av miljoner fler människor än som kan hacka inne i Firefox :-)
Jag tror inte det är rimligt att tro att de som faktiskt klarar av att bygga en relationsdatabas skall vara med och parprogrammera all SQL världen behöver, och även om de hade haft tid och det hade varit en bra prioritering (vilket jag inte tror det är), så tror jag faktiskt de hade blivit uttråkade. Jag säger inte att det är mindre värt att skriva den SQL:en VD:n behöver för att få rätt siffror i sin hand, och det krävs ofta mycket förståelse om verksamheten för att göra det rätt och bra, men jag skulle vilja hävda att det på just axeln abstraktioner är bra mycket mindre komplext, och jag tror också att det finns mycket färre personer som skulle klara lära sig det som behövs för att bygga en relationsdatabas än det finns personer som klarar lära sig att skapa rapporten till VD:n.
Tänker man bara att man alltid utvecklar allt i vertikaler och där alla skall kunna göra alla delar så som den agila diskussionen ofta går idag (även om det i vissa team är ok att man kan vara lite mer expert på någon teknik), så tror jag man missar en viktig poäng. Det är liknande tankesätt som det ovan jag tror vi kan applicera i mycket större utsträckning inom företag, system och applikationer och få samma slags hävstänger. Jag är ofta förvånad över hur mycket open source som används för infrastrukturskomponenter och annat återanvändbart, men hur lite samma företag/team ser sina egna möjliga abstraktioner och återanvändning de kunde gjort. Istället är det nästan alltid "jämntjockt" och samma komplexitetsnivå utsmetad på bredden i den egna kodbasen.
Missförstå mig nu inte och tro att jag menar att man bör (som jag sett vissa stora företag göra) sätta sig ner i 3-5 år och bygger den stora plattformen och sen skall man enkelt bygga appar ovanpå (och sedan lägger ner BDUF plattformen eftersom den missade målet eller aldrig blev klar...). Man måste alltid sträva efter att dra ur det generella från det specifika när man kan, men det finns också fall då det inte är vaken lämpligt eller möjligt, och i de fallen måste man verkligen se till att iallafall till att inte ligga speciellt långt efter med att bygga appar så man får testat sina byggstenar eller sin plattform tidigt och kontinuerligt (och driver krav och förändringar den vägen).
Lyckades jag förklara hur jag tänker eller rörde jag bara till det? För mig finns det många olika nivåer av programmering, inte bara olika områden, och förstår man det och organiserar sig efter det (och arbetar agilt, men inte "alla kan allt"-agilt) kan man åstadkomma storverk.
Joakim Ohlrogge
-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN
Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
E-mail: joakim....@agical.se
John Nilsson
Joakim Ohlrogge
Jag tycker det är lite att missa målet om man ser det som en linjär skala från duktiga kodare till mindre duktiga kodare.
Jag ser det mer så här:Den kodare som kan implementera en snabb, minnessnål och skalbar databasmotor har antagligen spenderat majoriteten av sin utbildningsbudget (med vilket jag menar "fritid") att läsa på om algoritmer och erfarenheter kring extremt tekniska detaljer.
En businesskodare som jag ser det kan ha lärt sig lika mycket om rå programmering som databaskodaren men istället lagt majoriteten av sin utbildningsbudget på att studera psykologi, design, sociologi och andra områden som krävs för att vara duktig på sitt jobb.
Så det som skiljer dem är inte kompetensen gällande programmering, det är kompetensen gällande problemområdet. Databaskillen är expert på algoritmer och datastrukturer, busniesskillen är expert på usability och sin avdelnings specifika behov och kontext.
Jag tror dessutom att båda områden mår bra av bättre verktyg som låter dem experimentera och uttrycka sig utifrån sin domänkunskap snarare än låglevelstrunt och biolderplate.
Jämförelsen med Excel är inte dålig. Problemet med den modellen som jag ser det är att den är dels för kantig, och dels avskiljd.
Kantig i det att gränssnittet mellan ett excekark och andra applikationer i verksamheten är tämligen strikt och fast. I princip begränsat till att ladda ner och upp tabeller.
Avsklijd i det att excelkodaren ofta har mycet liten kontakt med andra applikationskodare i organisationen. Vilket leder till obefintligt ubyte av kunskap och förbättringspotential.
Så om vi ökar ribban för excelkodaren så att det blir en roll som förväntas jobba med kraftfullare och mer flexibla verktyg. Samt framföallt jobba tillsammans med andra applikationskodare för att se till att integration, vidareutveckling och informationsflöde fungerar optimalt. Då tror jag att vi har mycket att vinna i flexibilitet och kvalité i vad vi skapar.
Viktor Klang
--
Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Groups.
Om du vill göra ett inlägg i den här gruppen skickar du e-post till scala-...@googlegroups.com.
Om du vill sluta prenumerera på den här gruppen skickar du e-post till scala-sverig...@googlegroups.com.
För fler alternativ, besök gruppen på http://groups.google.com/group/scala-sverige?hl=sv.
--
Mats Henricson
Jag är tveksam till att kräva ett omfattande arbetsprov (men de som
gör det borde då åtminstone erbjuda lite betalning som vissa gör) men
tror faktiskt man skulle kunna komma ganska långt med att tillämpa
kodgranskning på en intervju.
Med andra ord skulle man kuna låta kandidaten titta på lite dålig
källkod som inte är bra med avseende på olika aspekter, t.ex. dålig
semantik i typerna/metoderna/variablerna, dålig inkapsling, multipla
likadana if/switch-satser i en klass (istället för att använda
polymorfism med State eller Strategy pattern), duplicering, magic
value, återanvändning av samma variabel men med nytt innehåll längre
ner i metoden, metoder som tar emot en till synes "generell" typ men
som i implementation kräver en specifik (dvs byter mot Liskovs),
metoder som använder HashTabeller (istället för domänobjekt) eller
"Object" i publika metodsignaturer och som måste downcastas till vissa
typer eller hanteras på annat sätt utan intention-revealing
interfaces, high coupling, low cohesion o.s.v. o.s.v.
På Crisp använder vi oss av ett programmeringstest som bland annat
har en kodbas som vi ber kandidaten fixa. Henrik Kniberg skrev den en
gång, och det han gjorde var att han tog OK kod och sedan gjorde han
"refucktoring" på den.
I slutändan är dock dessa tester bara ett sätt för oss att få igång en
konversation om programmering. Förstår kandidaten vad han gör?
Förstår JAG vad kandidaten säger? Är han trevlig, vänlig och fri från
prestige, eller försvarar han kodbasen med tänderna? Känner han till
vilka val som finns för att lösa vissa problem? Etc.
Mats
Mats Henricson
För även om många hävdar att scala är för komplicerat så tycker jag den raka motsatsen. Visst, det är ett 'rikt' språk (dvs komplicerat, eller?), men fortfarande, du kan skriva java-syntax rakt av och få scala. Och detta är nyckeln. För till skillnad till vad många tror så är faktiskt dom flesta programmerare hyfsat konservativa, dvs dom håller sig till vad dom kan (java), och att då kunna göra en 'mjuk' övergång till ett mer produktivt språk blir väldigt värdefullt.Ett projekt (java) kan tex börja skriva alla sina tester i scala, och då samtidigt göra en smidig och mjuk övergång/kunskapsglidning mot scala.
Det är lätt och elegant att programmera OO i Scala. Jag har provat i ett hobbyhack. Att sedan gå över till exempelvis actors var rena knarket - vill ha meeeer! De funktionella delarna är jag fortfarande nybörjare på, men jag försöker.
Så tror jag de flesta kommer att migrera till Scala.
Mats
Niclas Nilsson
On Feb 2, 2010, at 11:22 , Mats Henricson wrote:
> 2009/12/31 Tomas Johansson <dddsv...@oo-systemutvecklare.se>
> Jag är tveksam till att kräva ett omfattande arbetsprov...
...
> metoder som använder HashTabeller (istället för domänobjekt) eller
:-) Denna hade jag missat innan.
Om detta är ett filter innebär det nog att man skulle få ungefär 0 st Python/Ruby-hackers genom filtret. :-)
(Och ja - jag använder kopiöst mycket mer hashmaps istället för domänobjekt / andra-objekt idag än för en handfull år sedan)
Viktor Klang
> Jag är tveksam till att kräva ett omfattande arbetsprov...
On Feb 2, 2010, at 11:22 , Mats Henricson wrote:
> 2009/12/31 Tomas Johansson <dddsv...@oo-systemutvecklare.se>
...
> metoder som använder HashTabeller (istället för domänobjekt) eller:-) Denna hade jag missat innan.
Om detta är ett filter innebär det nog att man skulle få ungefär 0 st Python/Ruby-hackers genom filtret. :-)
(Och ja - jag använder kopiöst mycket mer hashmaps istället för domänobjekt / andra-objekt idag än för en handfull år sedan)
Din rebell! ;-)
--
Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Groups.
Om du vill göra ett inlägg i den här gruppen skickar du e-post till scala-...@googlegroups.com.
Om du vill sluta prenumerera på den här gruppen skickar du e-post till scala-sverig...@googlegroups.com.
För fler alternativ, besök gruppen på http://groups.google.com/group/scala-sverige?hl=sv.
--
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall
Twttr: twitter.com/viktorklang
Tomas Johansson
skulle kunna kalla HOA (Hashtable-Oriented Architecture), eller
förresten kanske det inte är något mönster heller, eftersom det då
enligt en vanlig definition skall ha identifierats från flera
oberoende projekt.
Själv känner jag i alla fall till ett företag där ett slags
hashTabeller används genomgående i metodsignaturerna, både som
inparametrar och returvärden.
(det här systemet har f.ö. beskrivits för mig av en person som jag
känner mycket väl, och är därför säker på att det verkligen existerar
och inte är en skräck-historia, även om det kan låta så, och det är
inte heller något litet system som utvecklas av ett litet
garageföretag utan det är ett mycket affärskritiskt system som används
av flera stora företag, och om jag vore ansvarig för den där produkten
skulle jag inte kunna sova gott om nätterna med tanke på den oändliga
potentialen för runtime-exceptions)
Det är ett java-system, och 'hahtabellen' som används är inte någon
som ingår i JDK, utan en egenkonstruerad variant (som jag kallar
'Hash' här intill) med bl.a. metoder såsom 'addInt(String keyName, int
value)' , 'addString(String keyname, String value)', 'addSubHash
(String keyname, Hash subHashToAdd)' o.s.v.
Det finns tre s.k. lager, ett GUI-lager (dit webb-anropen först hamnar
efter att en servlet bl.a. har transformerat request-parametrarna till
hashtabellen) och ett applikations/domän-lager och ett
persisteringslager.
Metoderna i alla tre lagren returnerar alltså en hashtabell samt tar
emot en hashtabell som parameter.
Hashtabellen som returneras tillbaka från GUI-lagrets metoder skickas
sedan vidare till en JSP-sida, som i princip bara innehåller ett
metodanrop som tar emot den hashtabellen och genererar html-koden för
hela webbsidan m.h.a. all den information som alla use-cases skall ha
tryckt in i hashtabellen.
(och det finns även vissa möjligheter att påverka utseendet m.h.a. xml-
konfigurerings-filer)
Eftersom riktiga domäntyper saknas (egendefinierade typer med båda
data och metoder) så är förstås applikationen fullständigt procedur-
orienterad med en sorts anemisk domänmodell på stereoider skulle man
kunna säga.
Det kan även nämnas att systemet är kryddat men en hel del
reflektionsanrop samt i princip helt saknar JUnit/TestNG-tester som
utvecklaren kan köra (men lyckligtvis finns det i alla fall en
testavdelning som verkar göra ett bra jobb).
Många metoder är också åtskilliga hundra rader långa med en hög
cyklomatisk komplexitet (t.ex. finns det metoder som har 40+ möjliga
evauleringsvägar, men alltså med noll stycken möjliga
regressionstester som utvecklaren kan köra).
Eftersom detta är en diskussionsgrupp för Scala som uppmuntrar
immutability kan det också vara värt att nämna att hashtabellen som
skickas runt överallt är mutable, och den muteras också ofta, dvs
input parametern kan i vissa fall djupt nere i en if-sats skickas
vidare till en annan metod som populerar hahtabellen med lite mer
värden. Det finns alltså inte så mycket som gör applikationen särskilt
refaktoriseringsvänlig...
Det kanske finns en och annan hackare som tycker att det här låter som
en trevlig arkitektur att jobba med, men själv har jag den
uppfattningen att kod bör vara självbeskrivande i största möjliga
utsträckning, och man bör alltid sträva efter att den som läser koden
inte ska behöva hoppa in i metoderna som blir anropade och läsa
implementationerna, för att kunna förstå den yttre/anropande koden.
När man jobbar med en HOA av den ovan beskrivna typen så kan det ofta
vara väldigt svårt att läsa i implementationen av en metod för att
t.ex. bilda sig en uppfattning om hur den ska anropas, och vilka sub-
hashtabeller och sub-sub-sub-hashtabeller som ibland måste vara
popluerade med vilka värden i olika scenarios.
För att utvecklaren ska kunna förstå hur en befintlig metod skall
anropas (t.ex. om man vill försöka anropa den med en ny typ av
klientkod, t.ex. för att exponera en metod för web services anrop) så
måste vederbörande i princip debugga sig in i metoderna genom att
klicka in sig via webbläsaren på vanliga användningsfall med en
breakpoint till den metod som man tror kommer att anropas i ett visst
scenario, för att se den totala mängden av hashtabells-värden som
verkar krävas i ett normalt fall.
> Om detta är ett filter innebär det nog att man skulle få ungefär 0 st Python/Ruby-hackers genom filtret. :-)
Ja, en sådan utvecklare som inte reagerar negativt på att exponera
hashtabeller i publika metod-signaturer (i stället för egentypade
domänobjekt som inkluderar verksamhetslogiken) skulle knappast kunna
passera genom mitt filter i alla fall, om jag hade haft inflytande i
rekryteringsprocessen.
/ Tomas
On Feb 2, 4:56 pm, Niclas Nilsson <niclas.nils...@factor10.com> wrote:
> On Feb 2, 2010, at 11:22 , Mats Henricson wrote:
>
>
>
> > 2009/12/31 Tomas Johansson <dddsver...@oo-systemutvecklare.se>
Viktor Klang
--
Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Groups.
Om du vill göra ett inlägg i den här gruppen skickar du e-post till scala-...@googlegroups.com.
Om du vill sluta prenumerera på den här gruppen skickar du e-post till scala-sverig...@googlegroups.com.
För fler alternativ, besök gruppen på http://groups.google.com/group/scala-sverige?hl=sv.
--
Tomas Johansson
Johan Näsman
Tror att det finns många som är intresserade - finns det ngn
intressant blogg som reflekterar detta?
/JN
2010/2/2 Tomas Johansson <dddsv...@oo-systemutvecklare.se>:
> Ja, det gjorde jag faktiskt. Observant av dig att du noterade det :-)
>
> On Feb 2, 8:06 pm, Viktor Klang <viktor.kl...@gmail.com> wrote:
>> Jag får ett distinkt intryck av att du pratar om hasch-tabeller.
>
> --
> Det här meddelandet skickas till dig eftersom du prenumererar på gruppen scala-sverige i Google Groups.
> Om du vill göra ett inlägg i den här gruppen skickar du e-post till scala-...@googlegroups.com.
> Om du vill sluta prenumerera på den här gruppen skickar du e-post till scala-sverig...@googlegroups.com.
> För fler alternativ, besök gruppen på http://groups.google.com/group/scala-sverige?hl=sv.
>
>
--
Regards,
Johan Näsman
Mobile: +46 (0)70 508 7477
johan....@gmail.com
http://www.linkedin.com/in/jnasman
Niclas Nilsson
> Du har tur om du har missat det arkitekturella anti-mönstret som man
> skulle kunna kalla HOA (Hashtable-Oriented Architecture)
:-)
> Själv känner jag i alla fall till ett företag där ett slags
> hashTabeller används genomgående i metodsignaturerna, både som
> inparametrar och returvärden.
> (det här systemet har f.ö. beskrivits för mig av en person som jag
> känner mycket väl, och är därför säker på att det verkligen existerar
> och inte är en skräck-historia, även om det kan låta så, och det är
> inte heller något litet system som utvecklas av ett litet
> garageföretag utan det är ett mycket affärskritiskt system som används
> av flera stora företag, och om jag vore ansvarig för den där produkten
> skulle jag inte kunna sova gott om nätterna med tanke på den oändliga
> potentialen för runtime-exceptions)
Hmm... Jag tycker mig ana att du känner starkt aversion mot den här typen av system, men jag vågar mig ändå på att ställa lite frågor och kanske även visa på lite andra synsätt.
Första frågan jag har är varför det skulle automatiskt bli runtime-exceptions bara för att man gör så här? De flesta runtime-exceptions jag fått i mitt liv har handlat om att folk inte kollar sitt indata och jobbar på saker som är t.ex. är null. Däremot har jag mycket sällan fått det p.g.a. typfel (även i dynamiskt typade språk alltså). Jag tror för övrigt liknande arkitekturer är mycket vanligare på stora företag än på små (eller i vart fall än på mellanstora) eftersom de mycket oftare har system av integrationskaraktär.
> Det finns tre s.k. lager, ett GUI-lager (dit webb-anropen först hamnar
> efter att en servlet bl.a. har transformerat request-parametrarna till
> hashtabellen) och ett applikations/domän-lager och ett
> persisteringslager.
>
> Metoderna i alla tre lagren returnerar alltså en hashtabell samt tar
> emot en hashtabell som parameter.
Det du beskriver är något som snabbt blir vanligare och vanligare, både mellan system, mellan tjänster och mellan "lager", nämligen JSON (ofta i kombination med REST), vilket faktiskt fungerar väldigt bra.
> Eftersom riktiga domäntyper saknas (egendefinierade typer med båda
> data och metoder) så är förstås applikationen fullständigt procedur-
> orienterad med en sorts anemisk domänmodell på stereoider skulle man
> kunna säga.
Utan att mena att vara elak så känns det som din emailadress hintar om en mycket stark åsikt om hur ett system måste se ut, men jag kan inte låta bli att det är lite småkul (på ett snällt sätt) när just argumentet "kod måste bo på datat" är ett framtrådande argument i ett forum där influenserna från funktionell programmering är väldigt stark. I rena funktionella språk så är allt en anemisk domänmodell på stereoider, eller ev. listor och hashmaps på stereoider, så varför skulle det vara så problematiskt? Ser man på hur t.ex. Python är implementerat så är alla objekt egentligen bara (tada) hashtabeller (dictionaries). Däremot finns det inga anledningar att välja språket Java för den typ av arkitektur du beskriver (medans det kan finnas goda skäl att välja plattformen).
> Det kan även nämnas att systemet är kryddat men en hel del
> reflektionsanrop [...]
...vilket jag tolkar att du anser är negativt? Reflection är ju ett av få sätt att kunna göra någon slags metaprogrammering alls i Java och på de ställen du hittar reflektionkod hade man ofta fått handkoda samma sak magnituder fler gånger eller kodgenerera och göra systemet mer komplext och trögjobbat på en annan axel. Gör man däremot reflection för en one-shot sak där den konkreta implementationen hade varit likadan vinner man naturligtvis ingenting, men det tvivlar jag på att de gjort?
> samt i princip helt saknar JUnit/TestNG-tester som
> utvecklaren kan köra (men lyckligtvis finns det i alla fall en
> testavdelning som verkar göra ett bra jobb).
Personligen skulle jag inte bygga vare sig ett statiskt typat eller dynamiskt typat / hashtable system utan att testdriva det, men visst är det ännu något dumdristigare att göra det i ett dynamiskt typat / hashmapbaserat system än i ett verkligen hårt typat system.
> Många metoder är också åtskilliga hundra rader långa med en hög
> cyklomatisk komplexitet (t.ex. finns det metoder som har 40+ möjliga
> evauleringsvägar, men alltså med noll stycken möjliga
> regressionstester som utvecklaren kan köra).
Ok, de kan uppenbarligen inte skriva underhållsbar kod, vilket självklart är farligare när man inte har tester och inte heller ens den lilla, lilla trygghet ett typsystem ger dig om du inte har tester, men det här ser vi varje månad hos olika kunder, så det är absolut inte något som har med just denna typen av arkitektur att göra. Men det är definitivt inte bra.
> Eftersom detta är en diskussionsgrupp för Scala som uppmuntrar
> immutability kan det också vara värt att nämna att hashtabellen som
> skickas runt överallt är mutable, och den muteras också ofta, dvs
> input parametern kan i vissa fall djupt nere i en if-sats skickas
> vidare till en annan metod som populerar hahtabellen med lite mer
> värden. Det finns alltså inte så mycket som gör applikationen särskilt
> refaktoriseringsvänlig...
Ser man på hur REST / JSON-världen ser på data så handlar det ofta om att det är helt ok att utöka, lägga till saker (och det gör en vettig OO-värld också i och med subklasser), och som konsument skall du inte bry dig om data du inte förväntar dig. Om man är mycket strikt med det du måste ha, men var väldigt liberal med allt annat data så landar man i något av en sweetspot när det gäller förändringsbar kod. Att stenhårt kolla att allt ser ut exakt som du förväntar dig, vare sig du skall använda det eller inte skulle motsvara att i ett OO-system kolla att det du får in är av exakt rätt typ istället för att kolla instanceof (d.v.s. du skulle rata alla subklasser). Så länge du följer Liskov fungerar det precis likadant med en hashtabell som med en klasshierarki.
Om alla bara validerar exakt det som är viktigt för dem och ignorerar allt annat så får du dessutom mindre sköra testsviter, enklare att mocka (du mockar bara det som behövs, inte allt), och ett väldigt lättändrat system utan att en ändring slår på irrelevanta saker. Den statiskt typade OO-lösningen på detta problemet är att skapa många små interface, ofta så små att ingen enskild klass / tjänst implementerar bara ett interface, utan att varje roll är ett nytt interface (en vy) anpassad för konsumenten. Det ger ett fantatiskt fint objektorienterat system (jag är inte ironisk), men det är mycket brus i förhålande till signalen i ett sådant system. Väljer man ett dynamiskt typat system / hashmaps så får du samma effekt out of the box p.g.a. duck typing och du slipper skapa massa artifakter (alla små interface).
> Det kanske finns en och annan hackare som tycker att det här låter som
> en trevlig arkitektur att jobba med, men själv har jag den
> uppfattningen att kod bör vara självbeskrivande i största möjliga
> utsträckning, och man bör alltid sträva efter att den som läser koden
> inte ska behöva hoppa in i metoderna som blir anropade och läsa
> implementationerna, för att kunna förstå den yttre/anropande koden.
Att koden skall vara självbeskrivande håller jag helt med om, men faktum är att det inte finns någon motsättning här. Det kan bli exakt lika läsbart i hashmapsfallet, och det går också (inte ovanligt) med rätt verktyg att sätta upp så att du i en given funktion inte kan utröna om objektet du jobbar på är en vanlig instans av en klass eller en hashmap. Konsumentkoden kan se exakt likadan ut.
> När man jobbar med en HOA av den ovan beskrivna typen så kan det ofta
> vara väldigt svårt att läsa i implementationen av en metod för att
> t.ex. bilda sig en uppfattning om hur den ska anropas, och vilka sub-
> hashtabeller och sub-sub-sub-hashtabeller som ibland måste vara
> popluerade med vilka värden i olika scenarios.
Så kan det absolut vara. Så kan det lika gärna vara i ett aggregat med objekt. Du kan väldigt sällan se på en objektgraf vilka av alla tillstånd du skulle kunna sätta som är giltiga tillstånd, speciellt på helheten. Istället kommer du få runtimeexception om programmerar fel. Det går att undvika det genom att göra allting (och därmed hela graferna) immutable och aldrig låta grafen inta ett felaktigt tillstånd, men det är inte direkt så att Java skulle hjälpa till med utan du får koda in ganska mycket explicit för att det skall funka. Det är enklare i ett språk där allting är immutable. Men det intressanta i programmeringsfelsfallet är att har du testdrivit ditt system så kommer du ta den programmeringebuggen direkt i vilket fall som helst och kombinerar du det dessutom med ett DbC-tänkande skall det mycket till för att det skall slippa igenom nätet.
> För att utvecklaren ska kunna förstå hur en befintlig metod skall
> anropas (t.ex. om man vill försöka anropa den med en ny typ av
> klientkod, t.ex. för att exponera en metod för web services anrop) så
> måste vederbörande i princip debugga sig in i metoderna genom att
> klicka in sig via webbläsaren på vanliga användningsfall med en
> breakpoint till den metod som man tror kommer att anropas i ett visst
> scenario, för att se den totala mängden av hashtabells-värden som
> verkar krävas i ett normalt fall.
Bristen på dokumentation eller någon slags schema verkar ju vara total och det du beskriver här är definitivt inte det sättet jag vill lära mig ett interface på, men jag tycker ändå du buntar ihop många saker du anser vara negativa och påskiner att de hör ihop eller beror på varandra, men så måste det absolut inte vara. Jag bygger gärna dynamiskt typade system och ganska ofta löst typade också, men med ett starkt BDD och DDD-tänkande och med DbC-principer som inte släpper in ogiltiga kombinationer genom grindarna för varje tjänst / lager / <din-favorit-modulariserings-teknik>.
>
>> Om detta är ett filter innebär det nog att man skulle få ungefär 0 st Python/Ruby-hackers genom filtret. :-)
>
> Ja, en sådan utvecklare som inte reagerar negativt på att exponera
> hashtabeller i publika metod-signaturer (i stället för egentypade
> domänobjekt som inkluderar verksamhetslogiken) skulle knappast kunna
> passera genom mitt filter i alla fall, om jag hade haft inflytande i
> rekryteringsprocessen.
Som sagt, du sågar bl.a. REST och JSON (vilket du självklart får göra - det finns många som inte tycker om det, och det är helt ok!), men det fungerar otroligt bra och ger helt andra fördelar när det gäller flexibilitet än många rigida arkitekturer. Om man sen inte förstår att med frihet kommer ansvar så får man snart problem.
När det gäller var verksamhetslogiken skall ligga så är mitt defaultval ofta samma som ditt - i domänobjeken i många typer av system, men i andra typer så är det datadrivna, regelmotorbaserade tänkandet som är "rätt". Separationen i sig är alltså viktig för samma regel skall jobba på många olika slags data t.ex. eller appliceras under olika förhållanden. Att trycka in en objektmodell (normal OO alltså) i ett sådant system blir oerhört komplext, alldeles för mycket kod, och oflexibelt.
Det jag försöker säga är att du sågat ett system (främst) för dess val av designprinciper, utan att vi vet något alls om systemets karaktär. Är det ett typiskt data-drivet transformationsproblem (pipes-and-filters) skulle jag säga att de antagligen har gjort precis rätt val, men det enda vi får reda på är att det är ett stort företag, vilket är alldeles för lite information för att dra en enda slutsats. Det finns många system där en statiskt typad domänmodell är helt fel val, inte minst i rent funktionella problem. Jag har vid några tillfällen angripit ett problem jag uppfattat som ett objektorienterat problem med min default DDD/OO-approach, med sedan insett felet, backat ur, slickat såren, och löst det den rent funktionellt datadrivna vägen - och fått en enkel, elegant lösning. Alla typer av problem kan lösas på många sätt, men ofta är en, två, ibland rent av tre av lösningarna riktigt lämpliga och det stora flertalet blir mycket krångligare än problemet självt (accidental complexity), men det finns ingen lösning som överglänser andra helt kontextlöst.
Så jag ber ödmjukast om att inte automatiskt hålla med, och hoppas på en efterföljande intressant debatt där vi alla kan lära oss lite nya angreppssätt, för och nackdelar med olika designprinciper och vad som passar bra till vad.
Tomas Johansson
långa inlägget kommer att beröra det som rubriken säger dvs
"Arbetsmarknad för scala-utvecklare".
Det gör det tyvärr inte, utan det började spåra ur till en offtopic-
diskussion.
Till Niclas skulle jag därför vilja föreslå att om du ytterligare vill
fortsätta diskutera detta ämne, så kanske du kan skapa en ny tråd i
ett lämpligare forum och med en lämpligare rubrik, t.ex. skapa ett
ämne i DDD-forumet ( http://groups.google.com/group/dddsverige/topics
) med ett förslag på rubrik:
"Är det förenligt med DDD-principer att använda hashtabeller i stället
för egendefinierade abstrakta datatyper ?"
(eftersom jag uppfattar dig som att du faktiskt tycker det)
och kanske även med en länk till det som började diskussionen d.v.s.
http://groups.google.com/group/scala-sverige/msg/93e5b9420b56b116
On Feb 2, 11:39 pm, Niclas Nilsson <niclas.nils...@factor10.com>
wrote:
> On Feb 2, 2010, at 19:45 , Tomas Johansson wrote:
>
> > Du har tur om du har missat det arkitekturella anti-mönstret som man
> > skulle kunna kalla HOA (Hashtable-Oriented Architecture)
>
> :-)
>
> > Själv känner jag i alla fall till ett företag där ett slags
> > hashTabeller används genomgående i metodsignaturerna, både som
> > inparametrar och returvärden.
> > (det här systemet har f.ö. beskrivits för mig av en person som jag
> > känner mycket väl, och är därför säker på att det verkligen existerar
> > och inte är en skräck-historia, även om det kan låta så, och det är
> > inte heller något litet system som utvecklas av ett litet
> > garageföretag utan det är ett mycket affärskritiskt system som används
> > av flera stora företag, och om jag vore ansvarig för den där produkten
> > skulle jag inte kunna sova gott om nätterna med tanke på den oändliga
> > potentialen för runtime-exceptions)
>
> Hmm... Jag tycker mig ana att du känner starkt aversion mot den här typen av system, men jag vågar mig ändå på att ställa lite frågor och kanske även visa på lite andra synsätt.
>
> Första frågan jag har är varför det skulle automatiskt bli runtime-exceptions bara för att man gör så här?
> De flesta runtime-exceptions jag fått i mitt liv har handlat om att folk inte kollar sitt indata och jobbar på saker som är t.ex. är null.
> Däremot har jag mycket sällan fått det p.g.a. typfel (även i dynamiskt typade språk alltså). Jag tror för övrigt liknande arkitekturer är mycket vanligare på stora företag än på små
> (eller i vart fall än på mellanstora) eftersom de mycket oftare har system av integrationskaraktär.
Det är möjligt att du kan slippa runtime-exceptions om du och kanske
någon annan kommer att vara de enda utvecklarna och har koll på era
hashTabeller, men när applikationen har ett antal år på nacken och
många utvecklare har kommit och gått, utan att skapa tester, så är jag
övertygad om att förvaltningsbarheten kommer att vara mycket sämre än
med en typad applikation, bl.a. runtime-exceptions som kommer att
inträffa, som skulle ha förhindrats med typning.
Exempelvis kan du i din HOA ha definierat konstanter som kanske i
_teorin_ skulle kunna ge liknande typsäkerhet som egendefinierade
typer och du använder så här:
String name =
hashMapWhichShouldContainPersonData.getString(PersonConstants.NAME); //
konstanten har värdet "name"
Sedan kanske du ändrar koden och vill splitta upp namnet på förnamn
och efternamn, med nya konstanter så att du kommer att byta ut raden
ovan mot följande:
String name =
hashMapWhichShouldContainPersonData.getString(PersonConstants.FIRST_NAME)
+ " " +
hashMapWhichShouldContainPersonData.getString(PersonConstants.LAST_NAME);
Om du själv hade varit ensam utvecklare hade du kanske kunnat känna
dig trygg på att detta inte ska behöva bli något problem om du söker
efter förekomster av PersonConstants.NAME, men någonstans kan det
mycket väl finnas en hårdkodning (utan att använda konstanten) av
följande typ:
String name = hash.getString("name") // där "hash" här en input-
parameter till en metod
Detta är ett exempel på ett runtime-exception som inte skulle kunna
inträffa om man använder en statiskt typad 'Person' och skulle plocka
bort en getName()-metod eftersom utvecklaren då får kompileringsfel.
Nu kanske du tycker att ingen skulle hårdkoda strängen "name" eller
döpa en input-variabel till "hash" utan att använda bättre semantik,
men det betraktar jag nog lite som en utopi, för det finns faktiskt en
del sträng-hårdkodnings-duplicerare där ute...
Samma sak (dvs att det är en utopi ur ett långsiktigt perspektiv)
gäller en eventuell åsikt om att ett sådant fel _borde_ kunna fångas
upp av ett automatiserat testfall.
Visst, du kanske skulle göra det, men det tycker jag inte man kan
räkna med att framtida utvecklare kommer att göra, om man ska försöka
resonera lite realistiskt.
> varför det skulle automatiskt bli runtime-exceptions bara för att man gör så här?
Sammanfattningen av mitt svar ovan är alltså att en arkitektur som
skickar omkring hashtabeller med sträng-nycklar ökar möjligheten att
fulkoda med strängar som förhindrar kompilatorn att upptäcka felen,
och jag är övertygad om att en överväldigande majoritet av alla
applikationer med många års livslängd med många inblandade utvecklare
kommer att bli fulkodad och även kommer att sakna tester som snabbt
fångar upp problemen.
> > Det finns tre s.k. lager, ett GUI-lager (dit webb-anropen först hamnar
> > efter att en servlet bl.a. har transformerat request-parametrarna till
> > hashtabellen) och ett applikations/domän-lager och ett
> > persisteringslager.
>
> > Metoderna i alla tre lagren returnerar alltså en hashtabell samt tar
> > emot en hashtabell som parameter.
>
> Det du beskriver är något som snabbt blir vanligare och vanligare, både mellan system, mellan tjänster och mellan "lager", nämligen JSON (ofta i kombination med REST), vilket faktiskt fungerar väldigt bra.
JSON är ju ett språkoberoende format för att utbyta data, och jag ser
ingen anledning till att skicka omkring hashtabeller mellan de interna
lagren i applikationen bara för att man där använder JSON.
Om man t.ex. kollar på "Jackson" ( http://jackson.codehaus.org/ ) så
kan den läsa in JSON-data till antingen en Map eller till egen typad
klass:
import org.codehaus.jackson.map.ObjectMapper;
final ObjectMapper jacksonObjectMapper = new ObjectMapper();
// ett alternativ med en hashtabell:
final Map<String,Object> mapWithUser =
jacksonObjectMapper.readValue(jsonInputStream, Map.class);
// ett annat alternativ som använder sig av en egendefinierad typ
'User':
final User user = jacksonObjectMapper.readValue(jsonInputStream,
User.class);
Om du menar att det är vanligt att använda en sådan Map, skapad från
en JSON-struktur i det första lagret och sedan skicka vidare till
övriga lager som en Map, så tycker jag det är beklagligt, och att det
är vanligt är definitivt ingen garanti för att det är bra. Den
anemiska domänmodellen är t.ex. också väldigt vanlig men betyder inte
att den är bra.
Om det snabbt blir vanligare och vanligare kanske man ska tolka det
som att det inte har varit vanligt särskilt länge, och att de
långsiktiga konsekvenserna (av att skicka omkring hashtabeller och
använda strängar för att hämta ut värden som förhoppningsvis finns där
med rätt nyckelnamn) därför ännu inte har blivit påtagliga.
> > Eftersom riktiga domäntyper saknas (egendefinierade typer med båda
> > data och metoder) så är förstås applikationen fullständigt procedur-
> > orienterad med en sorts anemisk domänmodell på stereoider skulle man
> > kunna säga.
> Utan att mena att vara elak så känns det som din emailadress hintar om en mycket stark åsikt om hur ett system måste se ut, men jag kan inte låta bli att det är lite småkul
> (på ett snällt sätt) när just argumentet "kod måste bo på datat" är ett framtrådande argument i ett forum där influenserna från funktionell programmering är väldigt stark.
> I rena funktionella språk så är allt en anemisk domänmodell på stereoider, eller ev. listor och hashmaps på stereoider, så varför skulle det vara så problematiskt?
> Ser man på hur t.ex. Python är implementerat så är alla objekt egentligen bara (tada) hashtabeller (dictionaries). Däremot finns det inga anledningar att välja språket
> Java för den typ av arkitektur du beskriver (medans det kan finnas goda skäl att välja plattformen).
Nej, jag tycker inte att kod _alltid_ måste bo på datat, men däremot
att det är en naturlig utgångpunkt att placera metoden på typen som
innehåller datat.
Jag kan förstås ha fel men tvivlar på att det är särskilt ovanligt att
en Scala-utvecklare uppskattar den statiska typningen eller vill
definiera egna typer med lämpliga metoder för tillhörande data i
stället för att skicka omkring data i hashtabeller.
Jag kan inte uttala mig om hur man skulle göra i ett "rent"
funktionellt språk, men om man utgår från de två viktigaste
egenskaperna i ett funktionellt språk, enligt "Programming in Scala"
kapitel 1.2, så är det att funktioner är "first-class values" samt
immutability dvs att man inte modifierar värden.
Jag tycker båda dessa egenskaper är tilltalande. Det är t.ex.
omständigt i Java att behöva skapa ett Strategy-interface med en enda
metod om man kan använda en funktion i stället, och immutability är
också ofta en bra princip att sträva efter, även om det kan vara svårt
att tillämpa med ramverk som t.ex. kräver javabean setters.
(och DDD som genomgående är väldigt OO-inriktat innehåller bl.a. ett
avsnitt om Side-Effect-Free Functions, och även "Item 15: Minimize
mutability" i "Effective Java" som är en bok som riktar sig till
objekt-orienterade Java-programmerare)
Jag ser alltså inga större konflikter med mitt sätt att tänka jämfört
med att gärna vilja tillämpa de två främsta funktionella principerna.
Jag blir faktiskt lite osäker på om vi verkligen pratar om samma sak,
och om du verkligen tycker att det är lika bra att placera
domänlogiken utanför klassen (dvs "kod _utanför_ datat") där jag och
många andra tycker att den naturligt hör hemma. Därför tycker jag det
är dags för ett konkret kodexempel för att se om vi fullständigt
pratat förbi varandra och tänker på olika saker.
Jag utgår från ditt eget lilla kodexempel (
http://programmer.97things.oreilly.com/wiki/index.php/Thinking_in_States
) om en "Order" som är "completed" om den är "paid" och "shipped" (som
jag f.ö. sedan tidigare har kommenterat på discussions-fliken men det
räknar jag med att du har sett dvs att skribenterna bevakar
diskussioner om sina egna sidor, med "watch"-funktionen).
Nedan följer tre olika implementations-varianter, som jag själv tycker
är oerhört enkelt att rangordna i bättre, sämre och sämst i den
ordning som nedan följer, men du kanske tycker att de är likvärdiga ?
Alternativ 1. Den "normala" icke-anemiska varianten med en
egendefinierad typ:
public class Order {
...
public boolean isComplete() {
return isPaid() && hasShipped();
}
...
private boolean hasShipped() {
return shipped;
}
private boolean isPaid() {
return paid;
}
...
private boolean shipped;
private boolean paid;
...
}
Exempel på klientkod:
Order order = ...
...
if(order.isComplete()) {
...
Alternativ 2. En variant med en typad men extremt anemisk
domänmodell:
public class Order {
...
public boolean shipped;
public boolean paid;
...
}
public class OrderUtility { // alternativt kanske du hellre vill kalla
klassen "OrderService" ?
...
public static boolean isComplete(Order order) {
return order.paid && order.shipped;
}
...
}
Exempel på klientkod:
Order order = ...
...
if(OrderUtility.isComplete(order)) {
...
Alternativ 3. En variant med en otypad anemisk domänmodell, med en
hashtabell i stället för en egen datatyp:
public class OrderConstants {
...
public static final String PAID = "paid";
public static final String SHIPPED = "shipped";
...
}
import java.util.Map;
import static OrderConstants.PAID;
import static OrderConstants.SHIPPED;
public class OrderUtility { // alternativt kanske du hellre vill kalla
klassen "OrderService" ?
...
public static boolean isComplete(Map order) {
return isPaid(order) && hasShipped(order);
}
...
private static boolean hasShipped(Map order) {
return (Boolean)order.get(SHIPPED);
}
private static boolean isPaid(Map order) {
return (Boolean)order.get(PAID);
}
...
}
Exempel på klientkod:
Map<String, Object> order = ...
...
if(OrderUtility.isComplete(order)) {
...
Min fråga är alltså om du tycker att alternativen ovan är tämligen
likvärdiga implementationer dvs är ungefär lika bra ?
Om du inte tycker det, så korrigera gärna koden ovan för att
illustrera vad du menar med din kommentar om att "kod måste bo på
datat" som indikerar att du själv inte tycker att den borde göra det
som en naturlig utgånspunkt angående var man ska placera logiken.
> > Det kan även nämnas att systemet är kryddat men en hel del
> > reflektionsanrop [...]
>
> ...vilket jag tolkar att du anser är negativt? Reflection är ju ett av få sätt att kunna göra någon slags metaprogrammering alls i Java och på de ställen du hittar reflektionkod
> hade man ofta fått handkoda samma sak magnituder fler gånger eller kodgenerera och göra systemet mer komplext och trögjobbat på en annan axel. Gör man däremot reflection
> för en one-shot sak där den konkreta implementationen hade varit likadan vinner man naturligtvis ingenting, men det tvivlar jag på att de gjort?
Jag har själv flera gånger (i olika applikationer) stött på
reflektionskod i applikationer för att implementera en slags "Worker
Thread" alltså skicka in objekt som skall exekvera vid ett senare
tillfälle, men då har man använt sig av reflektion och typen "Object"
som skickas omkring en del och gör det svårare att veta vad som
konkret kommer att exekvera.
Om man i sådana fall istället anväder sig av en variant av Command
pattern, så blir det mycket lättare att hitta de klasser som
implementerar ett sådant interface.
Ju mer reflektionskod man ser i en applikation desto osäkrare blir man
på om en metod verkligen används, och vågar därför inte ta bort
metoder som man tror eventuellt kan användas någonstans, och
konsekvensen blir att det antagligen ligger kvar en massa kod i onödan
som aldrig används. En annan sak gäller svårigheten att våga
refaktorisera när man inte snabbt och enkelt kan söka fram hur en
metod används, t.ex.
våga introducera en ny parameter, men det skulle då kunna orsaka
problem om det kommer ett reflektionsanrop som inte skickar in den nya
parametern.
En rimlig konskvens av att utvecklaren inte vågar refaktorisera en
metod för att göra den mer återanvändbar är att vederbörande i stället
kopierar implementationen till en ny metod och gör sina ändringar, dvs
skapar onödig duplicering pga rädsla av konsekvensen av evenuella
reflektionsanrop på den befintliga koden.
Det är också mycket enkelt att själv skriva reflektionskod, dvs det är
inte alls syntaktiskt svårt utan man behöver bara lära sig några få
enkla metoder och klasser, men att däremot försöka förstå
reflektionskod som någon annan har skrivit är inte alls lika enkelt.
I den aktuella applikationen används reflektionen för att (åminstone
bl.a. därför) kunna specificera metodnamn med strängar i stället för
att anropa på normalt sätt.
Exempelvis kan GUI-lagret köra följande typ av anrop:
applicationLayerGenericObject.execute("savePerson",
hashTableWithPersonData);
alltså i stället för att på ett lite mer normalt (för java) typat sätt
anropa metoden:
applicationLayerPerson.savePerson(hashTableWithPersonData);
Syftet med sträng-anropet ovan var att den förstnämnda generella
metoden ovan kommer att anropa den sistnämnda metoden ovan ifall den
existerar, men annars skall i stället en generell default-
implementation delegera vidare till följande generella kod:
persistenceLayerGenericObject.execute("savePerson",
hashTableWithPersonData);
som i sin tur då anropar följande metod (ifall den finns
implementerad):
persistenceLayerPerson.savePerson(hashTableWithPersonData);
Om inte den metoden existerar så kommer den generella koden (via
"persistenceLayerGenericObject.execute" alltså) att försöka persistera
det som skickas in i hash-tabellen som alltså förhoppningsvis är en
person med validerad data, men som även kan tänkas innehålla
relaterade sub-hashtabeller med t.ex. adresser som då eventuellt skall
persisteras till en adress-tabell.
Input-hastabellen innehåller inte bara själva datat, utan även diverse
styrparametrar, t.ex. flaggor som kan styra ifall tabeller med
relaterade data även skall persisteras, t.ex. om en eventuell
förekomst av adress-sub-hastabeller i exemplet ovan skall också
persisteras så kan detta kontrolleras via särskilda hashtabellsvärden.
De ovan nämnda metodnamn-strängarna hanteras oftast, men inte alltid,
via konstantklasser, dvs oftast inte med hårdkodad sträng som ovan,
utan snarare med:
applicationLayerGenericObject.execute(ApplicationLayerPersonActions.SAVE_PERSON,
hashTableWithPersonData);
Dock förekommer det även ännu mer "dynamisk" kod av följande typ, där
m_className är ett fält i den anropande klassen:
applicationLayerGenericObject.execute("save" + m_className,
hashTable);
Jag har fått höra att det är näst intill hopplöst att försöka läsa sig
till alla potentiella värden på "m_className" dvs namn på tabeller som
kan tänkas bli anropad via denna typ av kod.
Om man försöker med "find references" i utvecklingsmiljön så får man
ett antal olika träffar varifrån exekveringen kan härstamma, och om
man försöker söka vidare på varifrån respektive
anrop kommer ifrån så får man ibland ingen träff. Då kan man tyvärr
inte dra slutsatsen att eftersom det inte verkar finnas några anrop så
är den koden oanvänd och kanske till och med kan tas bort.
Det kan man tyvärr inte pga att övrig potentiell reflection-kod kan
tänkas anropa den kod som inte ser ut att bli anropad, och den koden i
sin tur kan alltså via reflection anropa den ovanstående koden med ett
värde (som förstås kommer från hastabellen) som kommer att hamna i
fältet m_className.
Konsekvensen av ovanstående blir sannolikt att utvecklaren som har
sett ovanstående (dvs "save" + m_className) inte vågar ta bort en
metod som börjar med "save" för även om den i praktiken aldrig blir
anropad längre så är det svårt att säkerställa.
Självklart är det mesta möjligt att försöka säkerställa med mer eller
mindre omfattande detektivarbete, men det finns det knappast någon som
brukar ha tid med, och i en refaktoriseringsvänlig applikation som de
flesta brukar vilja ha, så ska det inte heller behöva vara komplicerat
att konstatera huruvida en metod används eller inte, och i en
genomsnittlig applikation med ett antal år på nacken så finns det inte
heller några omfattande testsviter som kommer att upptäcka ifall det
smäller någonstans om man provar att plocka bort en metod.
Även om du själv börjar duktigt med disciplinerat utvecklande av
regresionstester så kommer applikationen mycket sannolikt att så
småningom förvandlas till legacy där de olika utvecklarna slarvar med
det automatiserade testandet.
När det gäller reflektionen, så kan vi fortsätta med "person"-exemplet
ovan som ett exempel på vad som kan gå snett under applikationens
livslängd.
Det kan t.ex. vara så att meoden "savePerson" initialt inte var
implementerad dvs den hanteras automatiskt via vidarebefordran till
persistence-klassen, men så småningom kan det t.ex. komma ett nytt
krav på att all inmatad adress-information skall ignoreras om den inte
är både fullständigt ifylld och är rimlig enligt validering, och då
skall i stället ett externt web service -anrop hämta
folkbokföringsadressen m.h.a. pesonnumret och persistera den adressen
som kommer därifrån.
Det naturliga stället att placera den typen av kod (som validerar
datat och eventuellt hämtar ersättningsdata från ett externt system)
skulle vara applikationslagret, som då kan återanvändas från olika
klienter till systemet (t.ex. webbklienter eller web service
klienter). Från den implementationen kan man explicit implementera det
anrop som tidigare kördes automatiskt till save-metoden i
persisterings-lagret.
Ett exempel på ett osäkerhetsmoment som då skulle uppstå i den nämnda
reflektions-baserade applikationen är att hur vet man att all kod som
anropade persisteringsmetoden verkligen alltid blir anropad via den
nya implementerade metoden i applikationslagret ? Dvs hur vet man att
strict layering alltid tillämpas och att inte persisterinsmetoden blir
anropad via någon genväg utan att komma genom applikationslager-
metoden.
Det är INTE säkert att en sökning på en konstant av typen
PersistenceLayerPersonActions.SAVE_PERSON kommer att ge svaret dvs
även om man får noll träffar kan förekomsten av följande typ av
metoder göra att man inte vågar dra några slutsatser:
pesistenceLayerGenericObject.execute("save" + m_className, hashTable);
Om man däremot visste att den här typen av reflektionskod inte
förekommer i applikationen skulle man enkelt kunna söka på en
förekomst av den aktuella persiseringsmetoden för att se om det kanske
finns några direkta anrop till persisteringslagret som nu måste gå via
applikationslagret (tidigare kanske inte applikationslagret har gjort
så mycket mer än att helt enkelt skicka vidare till persisteringen så
därför har det funkat att hoppa över applikationslagret).
Om en applikation har 10+ år på nacken med åtskilliga utvecklare som
har kommit och gått kan man inte heller försöka dra några slutsatser
som att "nä men så kan vill ingen ha gjort" utan man måste faktiskt
räkna med allt, och som sagt var tror jag inte att många långlivade
applikationer i framtiden heller kommer att ha omfattande sviter med
regressionstester.
I vissa typer av applikationer finns det ett motiverat behov av att
använda reflection, t.ex. om man ska implementera ett POJO-ramverk
(typ hibernate) som ska kunna hantera alla världens klasser som är
okända för ramverks-utvecklaren, och inte ska kräva något speciellt
interface utan skall använda getters/setters via reflektion. När den
gäller den egna verksamhetsspecifika koden däremot så anser jag att
det är helt fel att själv skriva reflection-kod för sin egen
verksamhetsspecifika applikation i en normal exekvering (men däremot
för kodgenerering kan reflektion användas).
Med andra ord håller jag med Johsuha Bloch och Martin Fowler's
rekommendationer om reflection:
"...As a rule, objects should not be accessed reflectively in normal
applications at run time..."
respektive
"... So, in the future, if you feel you need to conquer a complicated
problem using reflection, just remember one rule: don't do it at
runtime."
(
http://java.sun.com/docs/books/effective/
http://www.javaworld.com/javaworld/jw-11-2001/jw-1102-codegen.html?page=7
)
> > samt i princip helt saknar JUnit/TestNG-tester som
> > utvecklaren kan köra (men lyckligtvis finns det i alla fall en
> > testavdelning som verkar göra ett bra jobb).
>
> Personligen skulle jag inte bygga vare sig ett statiskt typat eller dynamiskt typat / hashtable system utan att testdriva det,
> men visst är det ännu något dumdristigare att göra det i ett dynamiskt typat / hashmapbaserat system än i ett verkligen hårt typat system.
Pesonligen tycker jag att det är olämpligt att använda ett dynamiskt
typat språk (eller otypad hashtabells/reflektions-arkitektur i ett
statiskt typat språk) för att bygga ett affärskritiskt system som man
vet långsiktigt kommer att behöva förvaltas av många olika utvecklare.
Det låter onekligen jättefint att du skulle TDD:a men jag tvivlar på
att det är särskilt många utvecklare som _verkligen_ skulle testdriva
all kod på ett strikt sätt.
Det finns säkerligen många som gärna hävdar att de vill tillämpa TDD,
och som har viss förmåga att skriva JUnit-tester (åtminstone på lägre
nivå med enklare utility-metoder), men när det verkligen kommer till
kritan och aldrig skriva kod förrän man har en röd test, så tror jag
faktiskt det är ytterst få som verkligen kommer att göra det
disciplinerat under applikationens livslängd.
Även om du själv nu tillhör den minoritet som jobbar på det viset så
kommer systemet sannolikt, under dess livslängd, att utvecklas även av
andra som inte har den disciplinen och/eller kunskapen och slarvar med
testerna, och då kommer de så småningom att sitta där och inte våga
refaktorisera med de konsekvenser de innebär.
> > Många metoder är också åtskilliga hundra rader långa med en hög
> > cyklomatisk komplexitet (t.ex. finns det metoder som har 40+ möjliga
> > evauleringsvägar, men alltså med noll stycken möjliga
> > regressionstester som utvecklaren kan köra).
> Ok, de kan uppenbarligen inte skriva underhållsbar kod, vilket självklart är farligare när man inte har tester och inte heller ens den lilla, lilla trygghet ett typsystem ger dig om du inte har tester, men
> det här ser vi varje månad hos olika kunder, så det är absolut inte något som har med just denna typen av arkitektur att göra. Men det är definitivt inte bra.
Jag håller inte med om det där med "lilla, lilla", utan det är
faktiskt på det viset att även om det inte finns några tester över
huvud taget i en applikation så finns det faktiskt många fler
refaktoriseringar som man ändå enkelt kan och vågar göra om man vet
att applikationen saknar reflektionsanrop eller skickar omkring
hashtabeller med strängnycklar som kan finnas hårdkodade på olika
ställen (eller kan konkateneras på ett sätt i delar av applikationen
som kan göra eventuella hashnycklar ännu svårare att hitta).
Man kan t.ex. flytta metoder och döpa om metoder/typer för att
förbättra semantiken (för läsbarhet har ju ett stort samband med
underhållsbarhet) och man kan extrahera metoder och ändra
metodsignaturer utan att oroa sig för att det finns dynamiska delar
som kommer sluta fungera.
>
> > Eftersom detta är en diskussionsgrupp för Scala som uppmuntrar
> > immutability kan det också vara värt att nämna att hashtabellen som
> > skickas runt överallt är mutable, och den muteras också ofta, dvs
> > input parametern kan i vissa fall djupt nere i en if-sats skickas
> > vidare till en annan metod som populerar hahtabellen med lite mer
> > värden. Det finns alltså inte så mycket som gör applikationen särskilt
> > refaktoriseringsvänlig...
>
> Ser man på hur REST / JSON-världen ser på data så handlar det ofta om att det är helt ok att utöka, lägga till saker (och det gör en vettig OO-värld också i och med subklasser),
> och som konsument skall du inte
> bry dig om data du inte förväntar dig. Om man är mycket strikt med det du måste ha, men var väldigt liberal med allt annat data så landar man i något av en sweetspot när det
> gäller förändringsbar kod. Att stenhårt kolla att allt ser ut exakt som du förväntar dig, vare sig du skall använda det eller inte skulle motsvara att i ett OO-system kolla att
> det du får in är av exakt rätt typ istället för att kolla
> instanceof (d.v.s. du skulle rata alla subklasser). Så länge du följer Liskov fungerar det precis likadant med en hashtabell som med en klasshierarki.
Angående Liskov, så ja visst kan du definiera en metod som tar emot en
formell parameter av typen Map, och sedan använda en konkret instans-
parameter med t.ex. klaserna HashMap och HashTable, men det kanske
inte var det du menade med referensen till Liskov, som handlar om att
klientkoden på ett transparent sätt ska kunna anropa metoder på en
bastyp utan att behöva ta hänsyn till de konkreta subtyperna.
Med en typad programmering så kan du t.ex. ha följande klasser:
class Animal...
class FlyingAnimal extends Animal // fåglar alltså
class WalkingAnimal extends Animal
... plus eventuella nya subtyper som kommer att kunna hanteras utan
att ändra metoden nedan (Open-Closed Principle)
och någonstans i systemet finns en metod som inte bryr sig om
subtypen:
public void killAnimal(Animal animal) {
animal.setLivingStatus(LivingStatus.DEAD);
persist(animal);
}
Här nedan utgår jag från att databasen är modellerad på det viset att
det finns en Animal-tabell med de gemensamma fälten, t.ex. ett fält
"Livingstatus", och sedan finns det ytterligare två tabeller
FlyingAnimal och WalkingAnimal med de egenskaper som är unika, t.ex.
"vingbredd" eller dylikt för en fågel.
När det gäller den aktuella applikationen som har beskrvits för mig,
så är namnet på hashnycklarna lika med namnet på subtabellerna, med
andra ord skulle ovanstående metod behöva implementeras med följande
typ av if-sats-programmering:
(nedan hårdkodar jag för enkelhetens skull eftersom jag inte orkar
definierar konstanter för exemplet, men konstamter används oftast i
den aktuella applikationen)
public void killAnimal(Hash hashTableWithSomeKindOfAnimal) {
Hash subHashWithSomeAnimalSubtype;
// nu måste vi få tag i en referens till hashtabellen som kan ligga i
olika nycklar (motsvarande tabellnamnet):
if(hashTableWithSomeKindOfAnimal.exists("FlyingAnimal")) {
subHashWithSomeAnimalSubtype =
hashTableWithSomeKindOfAnimal.getSubHash("FlyingAnimal");
}
else if(hashTableWithSomeKindOfAnimal.exists("WalkingAnimal")) {
subHashWithSomeAnimalSubtype =
hashTableWithSomeKindOfAnimal.getSubHash("WalkingAnimal");
}
/ och här får vi förstås en icke-tillämpning av Open-Closed
Principle :-(
// else {
subHashWithSomeAnimalSubtype.setInt("LivingStatus",
LivingStatus.DEAD);
Hash animalHash =
HashCreator.createHashWithNamedRootelement("Animal");
animalHash.copySubElementsFrom(subHashWithSomeAnimalSubtype);
persist(animalHash);
}
Jag har hört att den här typen av if-sats-programmering förekommer i
kopiösa mängder i den aktuella applikationen dvs att man kontrollerar
vilken subtyp som skall hanteras men som har olika namn på
strängnycklarna i hashtabellen.
Det går säkert att hashtabells-programmera på ett bättre sätt än ovan,
men jag har lite svårt att förstå vilken typ av Liskov-polymorfism du
använder på dina hashtabeller.
Antagligen skulle det vara vettigare (jämfört med ovanstående typ av
hastabells-kod alltså) att bastabellen alltid ligger på en första nivå
och sedan inuti har man sub-hashtabeller motvarande de olika "sub-
databastabellerna", men sedan måste man ju också kunna hantera parent-
child-relationer på något sätt också, och för att då veta om en sub-
hashtabell är en parent, child, eller sub-tabell så förmodar jag att
man någonstans måste trycka in styrparametrar för detta i
hashtabellerna
(såvida man inte använder metadatabas-programmering och kollar inte
bara foreign key relationer mellan det som finns i hashtabellen utan
kanske kan luska ut om de även har en gemensam foreign key och då dra
slutsatsen att det handlar om en subtabell)
Det framgår dock inte på något sätt på vilket sätt de olika koncepten
är relaterade till varandra via den enda datatypen som är en
hashtabell.
Med egendefinierade abstrakta datatyper så framgår däremot modellen på
ett tydligt sätt, dvs kan man se på en klass vilka eventuella
interface den implementerar och vilken basklass den eventuellt ärver
ifrån, och man kan titta på metodsignaturerna för att bilda sig en
uppfattning om hur koncepten är relaterade till varandra.
Exempelvis kan en Person-klass ha metoderna "addAddress(Address
address)" och List<Address> getAddresses()" och vidare kanske man kan
se att Address är ett bastyp (interface eller basklass) med olika
implemenationer såsom ElectronciAddress och PhysicalPostalAddress.
Genom att navigera runt i koden kan man alltså relativt enkelt bilda
sig en uppfattning om hur koncepten hänger ihop, men hur skall något
motsvarande vara möjligt om det bara finns en generell hashtabell som
användas för att implementera datat för alla koncept i domänen ?
Inom Domain-Driven Design brukar det hävdas att "koden är
modellen" ( http://www.google.se/search?q=DDD+%22code+is+the+model%22
) men det anser jag vara oförenligt med att använda hashtabeller för
datat.
> Om alla bara validerar exakt det som är viktigt för dem och ignorerar allt annat så får du dessutom mindre sköra testsviter, enklare att mocka (du mockar bara det som behövs, inte allt),
> och ett väldigt lättändrat system utan att en ändring slår på irrelevanta saker. Den statiskt typade OO-lösningen på detta problemet är att skapa många små interface, ofta så små att ingen enskild klass /
> tjänst implementerar bara ett interface, utan att varje roll är ett nytt interface (en vy) anpassad för konsumenten. Det ger ett fantatiskt fint objektorienterat system (jag är inte ironisk), men det är
> mycket brus i förhålande till signalen i ett sådant system. Väljer man ett dynamiskt typat system / hashmaps så får du samma effekt out of the box p.g.a. duck typing och du slipper skapa massa
> artifakter (alla små interface).
Det där låter som det gamla vanliga kortsiktiga tänkandet, att just nu
maximera hastigheten och just nu vinna lite tid på att slippa skapa
interface.
Koden skriver du en gång, men den kommer att läsas åtskilliga gånger
men med en svårbegriplig otypad kodbas kommer det att straffa sig i
längden.
Men visst, det är så verkligheten ser ut, kunden vill ha snabbt
resultat, och chefen/projektledaren vill att utvecklaren ska leverera
snabbt, och utvecklaren vill visa sig duktig och leverera snabbt
vilket är bra i löneförhandlingen, och om några år har utvecklaren
dragit vidare till något annat jobb medan det finns ny personal som
sitter och svär över att varenda j-a metod tar emot och returnerar en
hashtabell.
> > Det kanske finns en och annan hackare som tycker att det här låter som
> > en trevlig arkitektur att jobba med, men själv har jag den
> > uppfattningen att kod bör vara självbeskrivande i största möjliga
> > utsträckning, och man bör alltid sträva efter att den som läser koden
> > inte ska behöva hoppa in i metoderna som blir anropade och läsa
> > implementationerna, för att kunna förstå den yttre/anropande koden.
>
> Att koden skall vara självbeskrivande håller jag helt med om, men faktum är att det inte finns någon motsättning här. Det kan bli exakt lika läsbart i hashmapsfallet,
> och det går också (inte ovanligt) med rätt verktyg att sätta upp så att du i en given funktion inte kan utröna om objektet du jobbar på är en vanlig instans av en klass
> eller en hashmap. Konsumentkoden kan se exakt likadan ut.
Jaså, då tycker du kanske att följande är ett s.k. "intention-
revealing interface" (för du gillar väl DDD-koncept):
public Map getPerson(Map hashWithPersonId)
som ur läsbarhetssynpunkt är likvärdigt med följande metodsignatur
(?):
public Person getPerson(String personId)
I så fall är vi verkligen inte överens.
Om jag ska försöka anropa någon av metoderna ovan så kan jag i det
sistnämnda fallet förstå vad jag ska skicka in som parameter och kan
också enkelt ta reda på hur jag får ut t.ex. namnet på personen via en
typad metod på den abstrakta datatypen.
I det förstnämnda fallet skulle jag antingen behöva titta i koden för
att se vilken parameter som behövs eller så skulle jag kanske råka
känna till (eller så kanske det står det i dokumentationen som jag
eventuellt tror mig kunna lita på) att för just denna metoden finns
det en tillhörande konstant-klass PersonConstants så att jag kan
trycka in ett värde med t.ex.
'hashWithPersonId.putString(PersonConstants.PERSON_NUMBER,
"700101-1234")'.
När det gäller returtypen så kan jag också kolla i samma konstant-
klass för att gissa hur jag ska få ut namnet, t.ex. m.h.a. en
eventuellt förekommande PersonConstants.FIRST_NAME som hashnyckel.
Jag förstår f.ö. inte vilken typ av verktyg du syftar på, men anser
att koden skall kunna läsas av en normalbegåvad människa utan hjälp av
verktyg, och om det krävs specialverktyg för att kunna tolka den,
annars är det fel på koden. Det är i alla fall min uppfattning om vad
läsbar kod betyder.
> > När man jobbar med en HOA av den ovan beskrivna typen så kan det ofta
> > vara väldigt svårt att läsa i implementationen av en metod för att
> > t.ex. bilda sig en uppfattning om hur den ska anropas, och vilka sub-
> > hashtabeller och sub-sub-sub-hashtabeller som ibland måste vara
> > popluerade med vilka värden i olika scenarios.
> Så kan det absolut vara. Så kan det lika gärna vara i ett aggregat med objekt.
Det brukar finnas en gräns för hur mycket som kan ingå i ett aggregat
som är skapat med en egendefinierad typ.
I en hashtabell kan en utvecklare ha tryckt in hur mycket som helst i
sub-sub-hashar, men huvudproblemet är inte att vad som helst kan ha
skickats in, utan det är att metoder som tar emot och returnerar
hashtabeller inte har något "intention-revealing interface".
> Du kan väldigt sällan se på en objektgraf vilka av alla tillstånd du skulle kunna sätta som är
> giltiga tillstånd, speciellt på helheten. Istället kommer du få runtimeexception om programmerar fel. Det går att undvika det genom att göra allting (och därmed hela graferna)
> immutable och aldrig låta grafen inta ett felaktigt tillstånd, men det är inte direkt så att Java skulle hjälpa till med utan du får koda in ganska mycket explicit för att det skall funka.
> Det är enklare i ett språk där allting är immutable. Men det intressanta i programmeringsfelsfallet är att har du testdrivit ditt system så kommer du ta den programmeringebuggen direkt
> i vilket fall som helst och kombinerar du det dessutom med ett DbC-tänkande skall det mycket till för att det skall slippa igenom nätet.
Du verkar ha väldigt höga tankar om alla framtida utvecklare som ska
vidareutveckla hashtabells-applikationen.
Jag skulle gissa att 90% av alla utvecklare inte skulle kunna säga
något alls om vad Design By Contract är, och antagligen 99% kan inte
definiera vad en invariant är.
Det verkar faktiskt inte heller som att du själv verkligen vet vad DbC
handlar om, för du tidigare har skrivit om att "folk inte kollar sitt
indata" och nu skriver i samband med DbC att det inte skall slippa
genom nätet, och lite längre ner att "DbC-principer som inte släpper
in ogiltiga kombinationer genom grindarna".
Du verkar alltså blanda ihop DbC med något som brukar kallas "defensiv
programmering" och tror att DbC handlar om att skriva kod som
validerar preconditions.
Det gör det inte utan DbC går snarare ut på det motsatta dvs att man
_inte_ ska testa preconditions, utan helt enkelt förutsätta att
klienten respekterar kontraktet, som definierar preconditions och
postconditions.
Och hur ska klienten då veta vad kontraktet är på en metod som tar
emot en hashtabell, dvs hur ska klienten veta vad vederbörande ska
skicka in till metoden, dvs vilka sub-hashtabeller som ska finnas och
vad nyckelnamnen ska vara? Kanske genom att den som skapade metoden
dokumenterade den och sedan litar (enligt DbC) på att klientkoden inte
kommer att skicka in något annat än det som står i dokumentationen?
Sedan kanske man också ska lita på att den dokumentationen kommer att
bli uppdaterad när någon kommer uppdatering en metod så att den
behöver ett nytt hash-värde som input?
> > För att utvecklaren ska kunna förstå hur en befintlig metod skall
> > anropas (t.ex. om man vill försöka anropa den med en ny typ av
> > klientkod, t.ex. för att exponera en metod för web services anrop) så
> > måste vederbörande i princip debugga sig in i metoderna genom att
> > klicka in sig via webbläsaren på vanliga användningsfall med en
> > breakpoint till den metod som man tror kommer att anropas i ett visst
> > scenario, för att se den totala mängden av hashtabells-värden som
> > verkar krävas i ett normalt fall.
>
> Bristen på dokumentation eller någon slags schema verkar ju vara total
Du tror alltså verkligen på att dokumentation skulle fungera i en
hashtabells-arkitektur och att den kommer att överensstämma med
verkligheten dvs koden ?
Det gör inte jag och där är jag rätt säker på att jag är i gott
sällskap, och trodde faktiskt det var en tämligen universellt
accepterad (dvs inte särskilt kontroversiellt alls) erfarenhet att
dokumentation sällan/aldrid brukar hållas så uppdaterad att den går
att lita på (i egenutvecklade verksamhetsspecifika applikationer
alltså, men däremot i generella ramverk och bibliotek, t.ex Spring och
Apache Commons, så är situationen mycket bättre avseende uppdaterad
dokumentation).
Med en typad arkitektur har du klart bättre möjligheter att hålla
dokumentationen av dina kontrakt uppdaterade, dvs om du ändrar en
metod som förändrar något i kontraktet så kan det påverka andra
metoder också som anropade den metod du ändrade på, och genom en IDE-
sökning på användadet av metoden (som är lätt utan en reflektions-
arkitektur) så hittar du enkelt andra metoder vars dokumentation
eventuellt också måste ändras. Om du däremot använder en generell
hashTabell som används för datat för samtliga domänkoncept så blir det
inte lika lätt att hitta sånt som kan påverkas av en ändring inuti en
av alla procedurella metoder som arbetar med datat i den överallt
förekommande hashtabell-typen.
> och det du beskriver här är definitivt inte det sättet jag vill lära mig ett interface på, men jag tycker ändå du buntar ihop många saker du anser vara negativa och påskiner att de hör
> ihop eller beror på varandra, men så måste det absolut inte vara. Jag bygger gärna dynamiskt typade system och ganska ofta löst typade också, men med
> ett starkt BDD och DDD-tänkande och med DbC-principer som inte släpper in ogiltiga kombinationer genom grindarna för varje tjänst / lager / <din-favorit-modulariserings-teknik>.
Som sagt, DbC handlar inte om att förhindra något utan om att
förutsätta att klienten respekterar dina (förhoppningsvis)
väldefinierade kontrakt på dina metoder.
Ja, det stämmer att jag har nämnt flera olika negativa saker.
Det finns dock en gemsam nämnare, nämligen att både hashtabeller och
annvändandet av reflektion försämrar förvaltningsbarheten, med otydlig
kod som är svår att våga refaktorisera.
Samma sak gäller förstås bristen på tester och höga cyklomatiska
komplexiteter o.s.v. dvs det är negativt för förvaltningsbarheten.
> >> Om detta är ett filter innebär det nog att man skulle få ungefär 0 st Python/Ruby-hackers genom filtret. :-)
>
> > Ja, en sådan utvecklare som inte reagerar negativt på att exponera
> > hashtabeller i publika metod-signaturer (i stället för egentypade
> > domänobjekt som inkluderar verksamhetslogiken) skulle knappast kunna
> > passera genom mitt filter i alla fall, om jag hade haft inflytande i
> > rekryteringsprocessen.
> Som sagt, du sågar bl.a. REST och JSON (vilket du självklart får göra - det finns många som inte tycker om det, och det är helt ok!), men det fungerar
> otroligt bra och ger helt andra fördelar när det gäller flexibilitet än många rigida arkitekturer. Om man sen inte förstår att med frihet kommer ansvar så får man snart problem.
Jag anser att den slutsasen är felaktig eftersom jag, som sagt var,
anser att JSON är ett format för att utbyta data och som alltså inte
alls behöver implicera att man parsar ett JSON-objekt till en
hashtabell som man sedan skickar vidare till övriga lager.
> När det gäller var verksamhetslogiken skall ligga så är mitt defaultval ofta samma som ditt - i domänobjeken i många typer av system,
> men i andra typer så är det datadrivna, regelmotorbaserade tänkandet som är "rätt". Separationen i sig är alltså viktig för samma regel skall jobba på många olika slags data t.ex.
> eller appliceras under olika förhållanden. Att trycka in en objektmodell (normal OO alltså) i ett sådant system blir oerhört komplext, alldeles för mycket kod, och oflexibelt.
> Det jag försöker säga är att du sågat ett system (främst) för dess val av designprinciper, utan att vi vet något alls om systemets karaktär. Är det ett typiskt data-drivet transformationsproblem
> (pipes-and-filters) skulle jag säga att de antagligen har gjort precis rätt val, men det enda vi får reda på är att det är ett stort företag, vilket är alldeles för lite information för att dra en
> enda slutsats. Det finns många system där en statiskt typad domänmodell är helt fel val, inte minst i rent funktionella problem. Jag har vid några tillfällen angripit ett problem jag uppfattat som
> ett objektorienterat problem med min default DDD/OO-approach, med sedan insett felet, backat ur, slickat såren, och löst det den rent funktionellt datadrivna vägen - och fått en enkel, elegant lösning.
> Alla typer av problem kan lösas på många sätt, men ofta är en, två, ibland rent av tre av lösningarna riktigt lämpliga och det stora flertalet blir mycket krångligare än problemet självt (accidental
> complexity), men det finns ingen lösning som överglänser andra helt kontextlöst.
> Så jag ber ödmjukast om att inte automatiskt hålla med, och hoppas på en efterföljande intressant debatt där vi alla kan lära oss lite nya angreppssätt, för och nackdelar med
> olika designprinciper och vad som passar bra till vad.
Det aktuella systemet är ett informationssystem som innehåller väldigt
mycket verksamhetslogik.
Jag avslöjar inte vilken branch det gäller, men det finns alltså
väldigt mycket logik av den typen som jag exemplifierade med lite
längre upp dvs typ så här:
if((hashTableWithOrder.isTrue(OrderConstants.PAID) &&
hashTableWithOrder.isTrue(OrderConstants.SHIPPED)) { ...
Det är alltså inte en vanlig java.util.Map som används utan en
egendefinierad hashtabells-variant med lite mer typade metoder för
boolean, int, och string etc. men denna egna klassen används alltså
överallt som databärare för alla koncept som applicerar kopiösa
mängder av procedurell kod enligt ovanstående exempel.
/ Tomas
Tomas Johansson
> intressant blogg som reflekterar detta?
Inte som jag känner till och har hittat.
Jag har trott/hoppats att det beror på att det är så ovanligt, att
nästan ingen alls brukar bygga system där man skickar omkring
hashtabeller, men där kanske jag hade fel, för om jag inte helt
missförstod Niclas så är det tydligen vanligt i REST/JSON-
applikationer att de parsar in JSON-strukturerna till en Map som sedan
skickas vidare.
:-(
/ Tomas