I en serie intervjuer får vi träffa några av Citerus utvecklare ute på uppdrag. Först ut är Johan Östling, en av Citerus starkaste lingvister med erfarenhet av ett stort antal programmeringsspråk.
Hej Johan!
Berätta om ditt uppdrag.
Jag kodar backendtjänster i Kotlin – hade förmånen att få lära mig Kotlin som en del av uppdraget. Just nu skriver vi rätt vanliga “omvandla data från format A till format B”-tjänster, och då blir det mycket trevligare att använda ett uttrycksfullt språk utan onödiga upprepningar till skillnad från Java som hade varit alternativet i det här fallet.
Varför valde ni just Kotlin? Vad har varit positiva överraskningar i språket? Vad har du saknat från andra språk?
Jag var inte med i beslutet kring att prova Kotlin, det var innan jag började. Jag tror det handlade om att tillräckligt många var missnöjda med pratigheten i Java, och ville prova ett alternativ. Däremot är konsensus bland alla team som provat det att Kotlin har gjort oss mer produktiva på kort tid, koden blir mindre och tydligare än i Java. Dessutom har det varit enkelt för nya teammedlemmar att sätta sig in i Kotlin, även helt utan förkunskaper.
För mig var en positiv överraskning hur mycket bra grejer de lyft in i språket, utan att det för den skull känns som ett osammanhängade hopplock. Jag har ju en lång erfarenhet med Scala, och mycket av det jag gillar med Scala har Kotlin lånat helt oblygt. En nyhet för mig var deras hantering av null, där man lägger på ett ? i slutet av en typ för att uttrycka samma typ, fast nullable. Det här är första gången jag har provat den konstruktionen i verkligheten, och jag gillar verkligen hur det ser ut och fungerar.
Dock så saknar jag fullt stöd för funktionell programmering som Scala har. Det är en personlig preferens – jag föredrar helt enkelt den paradigmen – men jag måste samtidigt erkänna att bristen på det stödet leder till att koden blir mer likformig och mer Java-lik i tänket, vilket är en kraftigt bidragande orsak till att det är lätt att sätta sig in i vår Kotlinkod för nya teammedlemmar.
Om vi lyfter blicken lite, hur ser arkitekturen ut?
I vårt team har vi en större tjänst och en handfull mindre. Beroende på hur man definierar ordet “micro” så kanske det skulle kunna kallas för microservices. Det är blandat asynkron (via RabbitMQ) och synkron (HTTP) kommunikation mellan tjänsterna. Jag tycker arkitekturen ligger rätt nära en sweet spot i förhållande storlek på tjänster och antalet tjänster. Det är tillräckligt få för att det ska vara enkelt att hålla koll på alla, och de är lagom stora för att man kan säga att de hanterar ett och endast ett avgränsat kontext.
Förutom Kotlin, någon annan lärdom/insikt du gjort/fått i det här uppdraget?
Jag har fått knyta bekantskap med Spring Boot, och det har överlag varit trevligt även om jag inte är helt kompis med all magi som Spring kör under ytan.
Vad skulle du säga varit ditt största bidrag till teamet?
När jag kom in i teamet höll de på att utveckla en ny tjänst som inte hade ett enda lokalt körbart integrationstest hela vägen ner till databas och tillbaks. Mitt största bidrag har varit att införa sådana end-to-end-tester med omkringliggande resurser i Dockercontainers. Nu kör vi den metodiken i alla nya tjänster.
Tack Johan!
Vill du jobba med Johan? Kolla gärna här!
Citerus kör också kurser i Kotlin och Scala. Anmäl dig gärna här:
