's Picture

Expressenutvecklaren

Postad av Joel Abrahamsson

För ett par veckor sedan hade vi en konferens för alla utvecklare på Expressen - JensCon 2015. Konferensen bestod till största delen av open space men också av ett antal presentationer. Jag inledde med en kort presentation med titeln "Expressenutvecklaren". I denna berättade jag om några grundprinciper för hur utvecklare på Expressen förväntas arbeta och tänka. Här kommer en summering.

Två grundpelare

Expressenutvecklaren följer över allt annat två grundprinciper. Dessa principer utgör grundpelare för hur vi bygger applikationer som man alltid kan, och ska, stödja sig på. De två principerna är testdrivet och enkelhet.

Testdrivet

När Expressenutvecklaren får ett funktionellt krav beskrivet för sig, läser en user story eller får en idé själv börjar inte Expressenutvecklaren fundera på hur detta kan omsättas till kod. Istället börjar Expressenutvecklaren tänka på hur kravet kan uttryckas i ett test.

Vad menar vi med ett test i det här sammanhanget? Ibland kan det röra sig om ett klassiskt enhetstest men oftast handlar det om vad vi har kommit att kalla för "featuretest". Ett featuretest är en exekverbar specifikation som testar en funktionalitet utifrån-in. Dvs specifikationen beskriver, och testar, en interaktion med applikationen på samma sätt som en verklig användare, dator eller människa, hade interagerat med den.

Om applikationen är beroende av exempelvis en databas för att kunna uppfylla specifikationen stubbar vi normalt sett inte bort denna då vi ser databasen som en del av applikationen, vilket den ju är ur konsumentens perspektiv. Samtidigt är vi pragmatiska och värnar om snabba och deterministiska tester. Således, om applikationen är beroende av någon extern tjänst som applikationen inte själv har kontroll över brukar vi stubba ut denna.

...det vi är intresserade av att testa är att en given funktionalitet fungerar inom ramen för hela applikationen

Vissa hade kanske kallat våra featuretest för integrationstester då de testar flera komponenter på samma gång. Vi tycker dock att "featuretest" eller "end-to-end-test" är bättre namn då det vi är intresserade av att testa är att en given funktionalitet fungerar inom ramen för hela applikationen och vad den själv kan kontrollera. Det viktiga är alltså inte att en given integration fungerar eller att en given kod-funktion fungerar utan att en given del av applikationen fungerar, från anrop till svar.

När vi bygger applikationer med Node.JS skriver vi våra featuretest med testramverket Mocha och tillägget Cakes. Cakes möjliggör att skriva BDD-tester med Given-When-Then-syntax.

Exempel på utskrift från featuretester.
Exempel på utskrift från featuretester.

Enkelhet

Rustad med exekverbara specifikationer strävar Expressenutvecklaren efter att skriva så lite kod som möjligt för att uppfylla testfallen. Fokus läggs på att hitta enkla lösningar och att skriva kod som är så självdokumenterande som möjligt, inte på att skriva den "ultimata" produktionskoden. Termer som modellering, flexibilitet och framtidssäker är i det närmaste skällsord för Expressenutvecklaren.

...Expressenutvecklaren strävar efter att skapa så mycket användarnytta som möjligt

Inte för att begrepp som dessa är oviktiga men Expressenutvecklaren strävar efter att skapa så mycket användarnytta som möjligt och är dessutom medveten om att det är svårt att sia om framtiden. Därför skriver vi inte kod som inte behövs just nu, bara den kod som behövs för att uppfylla det aktuella testfallet.

Med det sagt tar naturligtvis Expressenutvecklaren ansvar för koden och refaktoriserar löpande. Dock är syftet med refaktoriseringen att få koden så enkel och läsbar som möjligt, inte att göra den så generisk eller återanvändningsbar som möjligt.

Låt oss ta ett enkelt exempel. För att uppfylla ett testfall har vi skapat en ny funktion. Funktionen har en parameter och beräknar ett värde som den returnerar. Inuti funktionen gör vi ett antagande av något slag, exempelvis vilket tidzon vi befinner oss i.

Under refaktoriseringen inser vi att funktionen senare kan komma att återanvändas med förändringar i vårar antagande (en annan tidzon). Vi skulle kunna hantera detta redan nu genom att ge funktionen en andra parameter med vilken man kan styra funktionens beteende. Det gör Expressenutvecklaren inte.

Expressenutvecklaren skriver bara den kod som behövs just nu.

Att introducera en andra parameter skulle visserligen göra funktionen mer flexibel men det finns inget verksamhetskrav (i form av testfall) som kräver detta och Expressenutvecklaren introducerar inte komplexitet baserat på gissningar om framtiden. Expressenutvecklaren skriver bara den kod som behövs just nu.

En annan viktig princip för Expressenutvecklaren är att hen skriver kod med andra utvecklare som mottagare. Expressenutvecklaren skriver hellre fem rader kod som är lätta att läsa och följa än en teknikonanimässigt perfekt one-liner.

Mentalitet

Utöver att utveckla testdrivet och att sträva efter enkelhet ställs Expressenutvecklaren dagligen inför en uppsjö frågeställningar och beslut. Då är Expressenutvecklarens mentalitet viktig.

I Management 3.0 av Jurgen Appelo, en bok som är lika bra som dess titel är dålig, söker författaren svar på vad "agilt" är. I begynnelsen, när datorer var ett nytt fenomen, var normaltillståndet inom mjukvaruutveckling kaos. Programmerare hade lite erfarenhet och utvecklingsmetoder var omogna eller rent av obefintliga.

Till en början kunde man vara mycket produktiv. All utveckling var nyutveckling och nybyggarandan var stor men bristen på metoder och etablerade arbetssätt ledde till att man snart körde in väggen. Produktiviteten avtog drastiskt och kvar satt man med svårförvaltade kodbaser.

Som en motreaktion till kaoset sökte mjukvaruutvecklarna ordning. Pendeln svängde rejält åt andra hållet och "software engineering" var fött. Istället för kaos rådde nu istället extrem ordning. Utvecklingen styrdes av väldefinierade processer och metoder.

Problemet var dock att pendeln slagit för långt. Processerna var detaljerade och krävande vilket gjorde utvecklingen tungrodd. De goda delarna från det tidigare tillståndet, såsom snabbrörlighet och kreativitet, hade kvävts.

När pendeln återigen bytte riktning uppstod lättviktiga arbetssätt och metoder. Dessa "agila metoder" placerade sig mellan de två extrema tillstånden. Mellan ordning och kaos.

Om vi definierar agilt som utrymmet mellan ordning och kaos och ser på detta utrymme som en skala, var vill vi då vara på denna skala? Expressen Utveckling värdesätter snabbrörlighet och kreativitet väldigt högt. Därför är det attraktivt att vara nära det kaosliknande tillståndet. Samtidigt behöver Expressen.se, en av Sveriges största nyhetssajter, ha en hög tillgänglighet och våra besökare behöver känna igen sig från ett besök till ett annat. Givet detta strävar vi efter att vara på mitten av skalan men med en klar dragning åt kaoshållet.

Vad har då detta med Expressenutvecklarens mentalitet att göra? Jo, i vardagen har Expressenutvecklaren en mentalitet som drar åt kaoshållet. Expressenutvecklaren jagar hela tiden snabbhet och lättrörlighet. Att lösa verksamhetskrav och skapa användarnytta på så enkla och lättviktiga sätt som möjligt.

Men, om mentaliteten drar åt kaoshållet kommer vi till slut att hamna i totalt kaos. Ett kaos där utvecklingen avstannar för att man inte längre vågar röra koden. Eller för att sajten är nere.

För att balansera mentaliteten behöver och har vi verktyg och arbetssätt som drar åt ordningshållet. Det kan handla om att arbeta testdrivet, att instrumentera applikationer för detaljerad statistik till en tidsseriedatabas, tv-skärmar på väggarna som visar dashboards eller code reviews.

Även dessa återfinns i Expressenutvecklarens vardag men i form av självklarheter snarare än något som man hela tiden strävar efter. Istället är detta något som man regelbundet reflekterar över och ibland uppdaterar eller skapar nytt.

Egenskaper

Utöver mina reflektioner om Expressenutvecklarens två grundpelare och mentalitet hölls även andra presentationer på JensCon. En av dessa hölls av vår kollega Jens Carlén som även han reflekterade över vad en Expressenutvecklare är. Hans angrepssätt var dock lite annorlunda än mitt då han gick igenom ett antal egenskaper som vi värdesätter hos utvecklare på Expressen. Dessa var:

  • Tar initiativ
  • Lyhörd
  • Orädd
  • Flaggar upp problem i tid
  • Går framåt


Vad menas med detta? Jo, Expressenutvecklaren brinner för den eller de applikationer som dess team arbetar med. Expressenutvecklaren strävar alltid efter att dess mobilapp, sajt eller API ska vara så bra som möjligt. Samtidigt ser Expressenutvecklaren till helheten och vad som är bäst för Expressen och alla Expressens användare. Som ett exempel på detta jobbar utvecklarna i det team som bygger vår mobilsajt fokuserat på att göra Expressen.se till världens bästa mobilsajt. Samtidigt bryr de sig om hur redaktörerna arbetar med sajten och skickar pull requests till det team som jobbar med våra innehålls-API:er för att göra dessa bättre.

Expressenutvecklaren låter inte sin applikation fastna i gamla versioner av ramverk. Inte heller räds hen för att deploya till produktion. Bäst exempel på detta är Jens själv som har som vana att uppgradera ElasticSearch eller någon databasinstans till ny version i produktion när han "hade en stund över".

Toppbild: Neil Moralee, från Flickr, creative commons.
Bild från presentation 1: Hernán Piñera, från Flickr, creative commons.
Bild från presentation 2: lifesauntering, från Flickr, creative commons.

PS. Missa inte vår nästa bloggpost, följ oss på Twitter!

Till startsidan