Temat för Øredev 2013 var “The arts”. Matthew McCullogh gav en passionerad avslutande keynote på onsdagen om att vi utvecklare borde se på vårt yrke som konst och visst, det kanske inte tillhör “de sköna konsterna” men i viss mån kan jag hålla med om att det vi håller på med är konst. Särskilt när vi skriver buggig kod för då blir det ofta konst…igt.

Det finns många sätt att lösa ett problem och vilket man väljer är en smaksak.  Jag tror att vi kodare ibland kan ha en lite för snäv uppfattning om vad som är Rätt Sätt att lösa ett problem, ofta baserat på vad vi läst i facklitteratur och på bloggar. Vi borde vara öppnare för att det kan finnas flera Rätt Sätt och som Mathew säger, om man aldrig tillåts gå utanför ramarna eller utmana gängse normer går man potentiellt miste om nya idéer. Tänk på det nästa gång du gör en code review! 🙂

Detta var ett tema som gick igen på flera av föreläsningarna, t ex i den där Per Eckerdal och Mattias Björnheden från Spotify berättade att de kommit vidare från ett läge där de led av långsam utvecklingstakt och även prestandaproblem i klienterna.

Ett av problemen var att de hade en arkitektur med många (nåja) lager där ny funktionalitet ofta krävde kodändringar i många lager, varav ett dessutom hanterades av ett specialiserat team vars backlog ständigt växte och det blev en flaskhals för övriga team.
Genom att skära bort lager lyckades de komma till ett läge där varje feature team själva kunde ändra i hela kedjan från backend till frontend vilket ökade utvecklingstakten markant. Detta var nog inte gjort i en handvändning men det lät som att resultatet väl rättfärdigade arbetsinsatsen.

En annan ögonbrynshöjare var Spotifys beslut att, med inspiration från Netflix, gå från ett minimalistiskt (renlärigt) REST API som serverade entitetsobjekt (“song”, “artist”, “playlist” osv), till att bygga aggregerade REST tjänster istället, där varje tjänst tillhandahåller all data som krävs för att i appen rendera en viss sida. Ett bra exempel tycker jag på att man vågat tänka annorlunda och utmana best practices och resultatet var enligt föreläsarna mycket gott.

De erkände förvisso att de aggregerade REST tjänsterna, där man inte längre jobbar med entiteter, ger upphov till duplicering i koden som anropar tjänsterna samt försämrar möjligheten att cacha svaren, men detta till trots menade de att resultatet var bättre prestanda i apparna pga mindre nätverksanrop per skärm samt ett smidigare sätt att utveckla då ett feature team själv kan skapa egna REST tjänster efter behov utan att behöva samordna med andra team. En mycket intressant dragning som jag kan rekommendera.

Det här med att skära bort lager (“layers”) var ett annat tema som gick igen under konferensen. Ingen verkar gilla lager längre.
Under rubriken Layers considered harmfull argumenterade Christian Horsdal för att vi allt för lättvindigt bygger in för många lager i våra system. Motiverande faktorer för att använda lager kan t ex vara att man vill abstrahera en viss del av problemdomänen (t ex DAOs), återanvändbarhet och portabilitet. Då dessa faktorer alla är giltiga bör vi tänka oss för innan vi arkitekturerar lager på lager … på lager. Vem har t ex varit med i ett projekt där man faktiskt har bytt databasmotor? Hur ofta återanvänder vi faktiskt klasser som vi lagt energi på att bygga så generella som möjligt? Om det verkligen är återanvändbar kod, bygg ett lib istället. Tips på konversationscitat att slänga sig med: “Use before reuse”.

Värt att tänka på är att varje lager man lägger till adderar overhead både vad gäller prestanda, testning och kodning. I ett system med många lager där man vill lägga till en liten enkel funktion som spänner över alla lager, t ex en ny flagga i databasen som ska visas på en websida, blir det mycket jobb för liten nytta.

Om man tänker i termer av services i stället för lager så får man en skön arkitektur som blir lättare att förstå, lättare att underhålla och man slipper att bli sittande med – hemska tanke! – en monolitisk jätteapplikation.  Nu tror jag inte att så många nya projekt idag bygger monoliter, men rörelsen mot Micro Services tycker jag är intressant. Så har vi t ex byggt alltomstockholm.se , som totalt består av 14 fristående tjänster som alla kan utvecklas, deployas och lastbalanseras individuellt. En mycket stor fördel för oss när vi vidareutvecklar sajten då varje buggfix eller ny feature blir väldigt odramatisk att ta i produktion. Att kalla vår arkitektur för Micro Services är kanske att tänja begreppet men det är i alla fall en service orienterad arkitektur vilket verkar vara i linje med gällande trender. Vi får väl nöja oss med att kalla vår implementation för Mini Services även om man på så sätt går miste om chansen att svänga sig med ett buzz word.

På tal om Micro Services så tog Fred George det begreppet till en helt ny nivå under en den mycket inspirerande föreläsningen “Implementing Microservice architectures”. Fred George är enligt egen utsago mannen som gav konceptet sitt namn. Det här var helt klart den session som gav starkast avtryck på mig under mina tre dagar på konferensen. Jag tror inte jag skulle kunna göra Fred rättvisa genom att försöka sammanfatta hans dragning här utan hänvisar istället till videon som jag hoppas snart dyker upp här: http://oredev.org/2013/videos .

Sammanfattningsvis tycker jag det var en givande konferens där kvaliteten på föreläsningarna varierade men övervägande del var bra. Ett lightning talk om Big Data var 99% säljsnack men det straffades av publiken med utebliven applåd. Aftonbladets gang of five gav konferensen en trea, där min egen röst var på den övre halvan av skalan.

Slutligen vill jag passa på att be alla konferensbesökare om ursäkt för att jag i tre dagar stört ordningen med konstanta hostattacker, som säkert gjort avtryck även på videoinspelningarna som du för övrigt bör spana in. Särskilt Fred George om Micro Services.