Archive for the ‘Programmering’ Category

Generationsklyftor

maj 20, 2010

I flera av intervjuerna i boken ”Secrets of a Rock Star Programmer” (Ja, det är en samling intervjuer med duktiga utvecklare) diskuteras om hur de som nu utbildas till programmerare saknar vissa, enligt de intervjuade viktiga kunskaper, eftersom de aldrig har använt X (typ emacs) för att Y (typ skriva sin egen tcp/ip-stack). Ett ganska tramsigt synsätt som en äldre generation alltid har haft på en yngre. Men när jag läser det kommer jag ihåg vad jag själv konstaterade när jag började läsa datateknik under första halvan av 90-talet; det som intresserade mig inom datateknik var inte alls samma saker som hade fått mina lärare att studera ämnet. Och när jag tänkte närmare på det var det alldeles självklart varför det var så. Utvecklingen går helt enkelt så snabbt att ett datatekniskt intresse betydde en sak på 80-talet, en annan på 90-talet och självklart ytterligare en sak år 2010. Medan jag var intresserad av den skapande delen av programmering verkade många lärare lockats mer av själva hålkorten än programmeringen man skulle ha dem till. Och hur skulle det kunna vara annorlunda? Under min tid har aldrig hårdvaran varit något man behövt ta särskilt mycket hänsyn till och aldrig något jag varit intresserad av, medan hårdvara under hålkortens tid var en så väsentlig bit att ett intresse för det antagligen var nödvändigt för att härda ut.
Och vad innebär då det? Jo, precis som inom alla andra yrken kan en generationsklyfta vara i vägen vid kommunikation även inom datatekniska yrken. Och eftersom generationsklyftorna kommer så mycket oftare blir kommunikationsproblemen också så mycket vanligare. Det gäller till exempel när högskolor ska försöka locka till sig datateknikstudenter, när it-företag ska utforma anställningsannonser, när anställda på en utvecklingsavdelning ska försöka samarbeta.

Språk och programmering

maj 2, 2010

I ett avsnitt av Filosofiska rummet i SR P1 handlade det om ”… hur språkbruket påverkar vårt sätt att tänka”. En hel del i sig tankeväckande aspekter diskuterades, men särskilt intressant tycker jag det är att man lätt kan se att mycket av dessa diskussioner om vårt vardagliga tal- och skriftspråk också är direkt överförbart på  hur vi använder ord för att namnge saker när vi modellerar och programmerar.
Två exempel från programmet:

På en fråga om tvåspråkighet och hur man använder olika språk i olika sammanhang kom man in på ordet ”ångest”. Den danska sångerskan i studion hade förstått att man i Sverige kan använda det ordet på ett ganska avslappnat sätt, till skillnad från i Danmark där ”angst” endast har den tunga medicinska innebörden. Lingvisten Sven Strömqvist kunde då berätta att man gjort försök som visat att att det var mätbara skillnader i hur mycket hjärnan var tvungen att arbeta när man man utsatte försökspersoner för entydiga respektive mångtydiga ord. Inte särskilt konstigt kanske eftersom hjärnan måste se till att undertrycka alternativa betydelser och associationer. Men anpassat till vår modellerings- och programmeringsvärld innebär det att det faktiskt är mätbart viktigt att man använder så exakta och lättolkade benämningar som möjligt för att underlätta både för sig själv och andra. Det gällar att inte bara hitta beteckningar som kan tolkas rätt, utan beteckningar som bara kan tolkas rätt!

Sven Strömqvist berättade också att det finns forskning som visar att försökspersoner som får ta del av en berättelse med mer precisa ordval kommer ihåg mer av berättelsen än försökspersoner som fått ta del av berättelsen med mer allmänna ordval. Exemplet i programmet var att en uggla beskrevs som att den antingen flaxade ut ur sitt bo eller bara lämnade det. Bättre, mer precisa ordval i vår programmeringsvärd borde därmed också göra det enklare för oss själva och andra att komma ihåg modeller och programkonstuktioner!

Självrannsakan: Inversion of Control bara för testbarhetens skull? Och vadådå, skulle det vara så farlig?

februari 11, 2010

När man skriver kod som ska enhetstestas är det lätt att hemfalla åt att slentrianmässigt se till att injicera beroenden i en klass istället för att kapsla in dem, bara för att man vet att klassen kommer att bli lättare att testa. Som allt annat man gör slentrianmässigt finns det såklart en fara i det, själva definitionen av slentrian innebär att man gör något utan att tänka efter.
Så för att förhoppningsvis stilla den gnagande känslan av oro tänkte jag i alla fall för mig själv fundera igenom vad jag tycker. Det handlar alltså om hur IoC står i förhållande till inkapsling. Är det alltid ok att injicera beroenden i sin klass?
Man kommer kanske lätt undan om man kan motivera injiceringen med att man på sätt och viss bara följer strategy-mönstret. I ärligheten namn kräver detta att man faktiskt har tänkt sig att injicera olika implementationer av beroendet även utanför testkoden. Ett annat fall där det känns designmässigt korrekt att bryta ut beroendet är när man kan motivera det med någon form av loose coupling (svag koppling? ) eller separation of concerns.
Men om man till slut kommer fram till att man skulle vilja använda IoC primärt för att göra en klass testbar så har jag bestämt mig för helt enkelt se på det pragmatiskt; visst bryter man inkapslingen och då gäller det att väga nackdelarna med detta mot fördelarna med ökad testbarhet. Om man ser på inkapslingen som ett sätt att göra det svårare för programmerare att använda en klass ”fel”, det vill säga genom att injicera ett annat beroende än vad som ursprungligen var tänkt, så håller jag med min förre detta kollega Göran Krampe som en gång konstaterade något liknande ”Jag har sett mer problem med klasser där man inte fått göra det man vill  än med klasser där man får”. Det ligger väl i linje med idén om att man måste lita på att de som ska använda ens kod vet vad de sysslar med. Med detta sagt så är det naturligtvis inte så att testbarhet alltid går före inkapsling. Snarare gäller det att vid varje tillfälle ställa dessa två mot varandra och känna efter vad som är viktigast. Och min känsla är att testbarheten ofta i praktiken är mer värd än inkapslingen.