Skip to content

Tanker om stack og kodevalg

Daniel Jackson edited this page Sep 1, 2021 · 6 revisions

Stack

Stacken vår bestemmes neste ukene, og vil avhenge av hvem vi får inn og hva de kan bidra med - men foreløpig kan det se ut som vi:

  • Bygger backend i et rammeverk som prioriterer utviklerhastighet, som Ruby on Rails eller tilsvarende.
  • Enten bygger frontend i React et.al, basert på et API fra backend,
  • eller bygger frontend mest mulig i et fullstack rammeverk og kun skiller ut noen få ting til mer avansert javascript om det trengs.

Prinsipper

Mennesker foran kode

Det viktigste for at lokaler.lnu.no skal bli vellykket sett med et kode-perspektiv, ikke bare nå i 2021 men fremover, er at vi klarer bygge et godt miljø rundt koden.

Derfor er det viktigste vi gjør å ta vare på de folka som vil være med å kode.

Derfor vil også de som stiller opp ha stor innflytelse på stacken til kodebasen, og en av de viktigste momentene når vi skal bestemme stack for 0.1-versjonen er hvem vi har med oss som kan gjøre en innsats.

Lesbar og enkel å bidra til

Det er ingenting vi skal gjøre her som er veldig nybrottsarbeid kodemessig.

Vi kan og bør derfor bruke solide rammeverk med lang fartstid i stedet for å roll our own eller bygge noe på det kuleste nye, så koden blir forståelig og mulig å arve for et nytt team.

Foreløpig tror vi at Rails er rett backend. Rails er stabilt, godt dokumentert, mulig å forstå, kommer til å være her om 10 år, og sannsynligvis det enkleste å bygge raskt i - men om vi får med oss noen som er ekspert på Laravel, Django, eller andre i samme sjanger så er det mulig vi går den veien!

Vi bruker standardløsningene så ofte som mulig, og avviker fra det kun når vi skal bygge noe som faktisk er nytt. Vi trenger ikke en egen autentiseringsløsning - standardpakkene fungerer nok fint og gir mer tid til å bygge noe nyttig for folk!

Vi må rydde underveis og holde kodekvaliteten høy. F.eks. bruker vi Rubocop i Rails for å sikre at formatering og kodestil er mest mulig lik mellom ulike programmerere - så det skal bli enklere å forstå for andre. Om vi griser til kodebasen vår, så går det ut over alle andre som skal bidra. God testdekning så vi vet alt fungerer, og så refaktorere til koden er ren og pen er derfor viktig.

Utviklingshastighet over millisekunder reponstid

Det skal være gøy å kode, og vi skal neppe ha millioner av brukere. Vi kan derfor prioritere utviklingshastighet over applikasjonens hastighet, og velge rammeverk som gjør det enkelt å lage ting - selv om det ikke er den raskeste koden.

Gleden kommer når folk bruker det

Den skikkelige gleden kommer når folk blir glade av å bruke det vi har bygget. Derfor vil vi hjelpe hverandre bli gode på å shippe kode som endrer folks liv - både gjennom å prioritere det som er viktigst og gjennom å bryte opp arbeidet i riktige bolker.