Hvorfor F#? En kærlighedserklæring til kvalitet

copenhagen software fsharp dotnet .net

Forhistorie

I denne artikel får du svar på to primære spørgsmål: “hvorfor F#” og “hvad kræver det at komme i gang?”. Men før vi kommer til det, få du en forhistorie, så du har konteksten med.

En af vores kunder driver en større tjeneste til  musikstreaming.

Deres software er splittet op i 10+ microservices alle bygget op i C#/ASP.NET og integreret med REST API’er. De havde allerede et meget velfungerende teknisk setup, da vi kom ind i projektet.

Seks udviklere, ingen testere og op til tusindvis af automatiserede tests understøttede en samlet applikation, der betjente 100.000+ samtidige brugere. Opdateringer blev deployet i et continuous delivery setup, således at der mange gange dagligt blev leveret ny software.

Det var på stort set alle måder et ret avanceret setup og et meget modent udviklingsmiljø, vi kom ind i. Det var også en virksomhed og et team der var på en rejse, hvor vi passede perfekt ind. 

Hvad var målet?

Som rendyrket softwarevirksomhed og konkurrent til en af de musiktjenester, der ofte nævnes som eksempel på moderne softwarevirksomheder, var kravene til performance meget høje. Det betød, at der var et meget højt fokus på kvaliteten af softwaren og arkitekturen, og krav om et meget fleksibelt deployment setup. Stabilitet og performance er også meget vigtige i et marked med kræsne brugere og store spidsbelastninger. 

Målet var ikke bare høj kvalitet – målet var perfektion. I DevOps, i koden, i teamet – alt omkring tjenesten skulle køre i absolut højeste gear.

Det var her, vi kom ind i billedet.

Softwarearkitekturen

Som tidligere nævnt var applikationen delt op i en række mindre, selvstændige services. Det er nærmest en nødvendighed for den type applikation fordi dele af den (betalingsmodul og loginmodul for eksempel) slet ikke har det samme behov for kapacitet, som andre moduler.

Det fleksible microservices setup giver mulighed for at ”skrue op” for kapaciteten automatisk, når behovet er der. Det betyder at services der kører konstant (spillelister for eksempel) har brug for en stabil, men også forudsigelig høj kapacitet, mens andre (brugeroprettelse) har brug for en mere fleksibel løsning. Kører der for eksempel en større marketingkampagne i en periode, kan antallet af nye brugere mangedobles.

Fordi den samlede tjeneste er en white label-løsning, har serviceudbyderen ikke nødvendigvis adgang til information om, hvilke af deres partnere, der kører hårdt på med en kampagne i en given periode. Det betyder at de er nødt til at kunne reagere hurtigt og håndfast på øgede krav til kapacitet.

Ikke overraskende, men arkitekturen var skræddersyet til dette setup.

Ligesom det høje fokus på kvalitet, lå en microservice-baseret arkitektur perfekt til vores kompetencer.

Hvad var målet?

Målet var, kort fortalt, en bedre softwareapplikation. En applikation der, kan bære forretningen over en periode på 10 år.

Der var fem mere konkrete mål:

  • Koden skulle kunne videreudvikles i 10 år
  • Koden skulle kunne deployes kontinuerligt (mange gange om dagen)
  • Koden skulle være let at læse
  • Koden skulle kunne testes
  • Teknisk gæld skulle kunne betales af med det samme

For at levere på disse mål anvendte vi en række sunde programmeringsprincipper fra funktionsorienteret programmering, herunder immutability og structural equality, for at nævne et par stykker. Disse principper bragte os et langt stykke af vejen mod vores mål, men det var også tydeligt, at C# til dels stod i vejen for, at vi kunne levere på det niveau, vi gerne ville. 

Derfor begyndte vi gradvist at anvende F# der, hvor det gav strategisk mening. Men hvorfor F#? Fordi du automatisk følger en række af de førnævnte principper, når du skriver F#. Vi oplevede derfor øget produktivitet, færre fejl og mere koncis og læsbar kode.

Og selvfølgelig fordi sprogene kan sameksistere i harmoni, fordi de afvikles på .NET platformen, hvorfor F# var det oplagte valg. Vi kunne anvende F# strategisk, uden at skulle sætte farten ned eller skrive allerede fungerende kode om.

Hvad vi lærte

Før du kan komme i gang med F#, er der nødt til at være to ting på plads:

  • En kritisk masse af udviklere med interesse for F#
  • Peer review proces – læs eventuelt vores tanker om code reviews her

Mængden af udviklere skal til, fordi der skal være nogle at sparre med i processen frem mod idiomatisk F#, og fordi et større team gør dig mindre sårbar. Men bemærk: F# er så nemt at komme i gang med, at i ikke behøver erfarne F# udviklere fra start.

Peer review processen er vigtig, fordi det er en god platform til vidensdeling på tværs af teamet. Ikke bare i forhold til at lære nyt, men også i det daglige arbejde. Code reviews er den fælles platform, der binder vores filosofi og principper for softwareudvikling sammen, og sikrer at den bliver spredt fra vores arkitekter til juniorer og udviklere hos kunderne.

Vi satte hurtigt et meget stærkt hold fra vores side, og de har, udover at løse denne konkrete opgave for vores kunde, også været evangelister internt i Copenhagen Software. Det er nu en fast begivenhed for vores konsulenter at tage på konferencen F# eXchange i London hvert forår.

Hvor vi endte

I skrivende stund har teamet netop fejret et helt år uden nedbrud i systemet – imponerende i betragtning af, at der er tale om en enorm tjeneste til musikstreaming.

I det forløbne år har teamet deployet kodeændringer 10-20 gange om dagen med automatiske tests, og de har haft 100.000+ samtidige brugere.

Udover 10-års perspektivet, som vi af gode grunde ikke har afprøvet, lever kodebasen og teamet, der arbejder i den, op til de oprindelige målsætninger.

Kodebasen er ikke udelukkende i F# i dag – der er stadig masser af C# i applikationen, men der er services, der udelukkende er skrevet i F#.

Nysgerrig efter mere?

Denne artikel er baseret på vores ekstremt populære foredrag “F# – hvorfor, hvordan og til hvad?”. Det er et foredrag vi har holdt for blandt andet Dansk IT, SimCorp, Jyske Bank og Mødegruppe for Funktionelle Københavnere.

Er du interesseret i at få den fulde historie med mulighed for at stille spørgsmål undervejs? Læs mere om foredraget her.