6 ting jeg vil unngå i 2019

Dette året vil jeg unngå rar CSS, tungtvindt kode og serverkonfigurering.

Jørgen har mange ting han vil starte med i 2019, men minst like mange ting han vil unngå. BEM-CSS, for eksempel. 📸: Ole Petter Baugerød Stokke
Jørgen har mange ting han vil starte med i 2019, men minst like mange ting han vil unngå. BEM-CSS, for eksempel. 📸: Ole Petter Baugerød Stokke Vis mer

2018 var året hvor alle utviklere skulle bli fullstack. Plutselig var det ingen rene frontend- og backend-utviklere, bare en bønsj med kodere som skulle mestre JavaScript like godt som Go, SQL og produksjonssetting.

Og egentlig er ikke det en dum utvikling: Ikke bare kan man skrive JavaScript foran og bak, nå. Men utvalget av tjenester for produksjonssetting, slik som Heroku og Netlify og Google Cloud Platform, har også gjort det enklere for utviklere å publisere kode.

2018 var året hvor JavaScript virkelig skulle gjøres proft. Rammeverk som Angular hadde allerede tatt web-apper til neste nivå, mens det i 2018 var React som stod midt i manesjen.

CSS gikk fra å være noe designere syslet med, til å få en plass i spot-lyset sammen med JavaScript. Og Java – vel, Java gjorde akkurat det samme som året før. Det ble brukt. Mye.

2019 er året hvor vi får enda bedre tjenester, språk og rammeverk for å lage fantastiske webtjenester. Med valgmulighetene som finnes må man også si nei til mye. Det er rett og slett ikke tid til alt.

Her er listen over det jeg ikke vil drive med i 2019.

#1. BEM og CSS-rammeverk

Vær så snill la meg slippe å se folk bruke BEM til CSS-struktur i 2019.

Aldri hørt om BEM, sier du? Det var da enda godt. Kort forklart er det en måte å strukturere CSS-klasser på slik at man tydelig uttrykker forskjell på komponenter og barn og så videre.

Ulempen er at når noen på prosjektet først har begynt med BEM, så må alle fortsette med det. Fordi ellers begynner CSS-en å se ut som Frankenstein-monsteret.

Hvis du ser CSS-klasser av typen photo__image eller carousel__caption--story, da vet du at du har å gjøre med en BEM-er på teamet ditt.

Jeg nekter å lære BEM, eller andre CSS-rammeverk som prøver å fjolle til CSS-en min med morse-lignende syntaks.

Nå som grid virkelig har slått gjennom håper jeg vi også kan slutte å bruke Bootstrap og Foundation og alle disse idiotiske CSS-rammeverkene som gjør at alt på nett ser helt likt ut.

Lag din egen CSS fra scratch. Det har aldri vært enklere, og siden din kommer til å bli bedre av det. Og hvis du ikke finner ut av noe, stjæl det fra bootstrap. Nå som CSS i JavaScript er en greie, gir det ikke mening lenger å arve store rammeverk.

#2. Server-side Java

Ja, norske utviklere, jeg vet dere elsker Java. Men jeg forstår ikke hvorfor!

Hvorfor vil dere ha et språk hvor man må skrive ørten hundre linjer for å oppnå nesten ingen verdens ting?

Selv Dropwizard, som liksom skal være et enkelt rammeverk, har så voldsom struktur at jeg får helt fnatt.

Og ja, jeg forstår at det kanskje er jeg som er problemet her. At om jeg setter meg mer inn i ting, så forstår jeg det nok. At det sikkert er superkjekt med nullpekere, sterke typer, interfacer og hauger av mapper med Java-filer. Som man selvsagt må bruke en editor som IntelliJ for å maskere over.

Jeg skjønner at dere trives i fortet dere har bygd. Men Node er så vanvittig enkelt, og går så fort, og funker helt greit. Jeg tror jeg holder meg til Node i 2019 også.

#3. TypeScript

Øy, proffe utviklere, slutt å tulle med JavaScriptet mitt!

Litt av sjarmen til JavaScript er at det er litt rotete og lavterskel. At man skal kunne cowboy-programmere litt, og få ting opp kjapt. Jeg frykter at utviklere presser for hardt på for å profesjonalisere JavaScript, og ødelegger enkelheten i språket.

Hvorfor skal vi importere tunge prosedyrer fra andre språk for å føle oss bedre som JavaScript-utviklere? JavaScript er kult fordi det er enkelt og fleksibelt! Kan vi ikke bare holde oss til det ECMAScript dikterer?

Og ja, jeg forstår at på større prosjekter med massevis av kode som deles av hauger av funksjonalitet så gir kanskje TypeScript mening. Men ikke i mine bittesmå applikasjoner. Ja til cowboy-koding i 2019 også!

#4. Redux

Jeg forstår fortsatt ikke helt hvorfor jeg trenger Redux. Men jeg føler meg som en tulling fordi jeg ikke kan det.

Det er kanskje en liten løgn. Fordi jeg forstår jo hvorfor det er kjekt med en sentral state som alle kan abonnere på i en applikasjon. Det jeg ikke forstår er hvorfor det skal lages så himla komplisert med «actions» og «reducere».

Kan ikke heller React-folka lage noe som integreres bedre i React? Så kan vi droppe hele Redux? Det virker jo som alle klager på det, uansett.

Jeg har også registrert at det er noe som heter Redux Saga, som tilbyr enda mer spaghettikode på toppen av Redux. Tror jeg dropper det jeg, ass.

#5. Testdekning

Husker du når testdekning var en greie? Ofte ledet an av en eller annen gjøkete «tech lead» som ville vise at:

– Her på huset skriver vi «trygg» kode!

Hva nå enn det betyr.

– Nå har vi 90 prosent testdekning! ble det gjerne proklamert.

Så da er vel produktet vårt trygt da. Eller?

Jeg lar vær å skrive automatiske tester, jeg. I 2019 også. Det går faktisk ganske greit. Bare skriv liten, enkel kode istedet. Så ordner det seg nok.

«Bare skriv liten, enkel kode istedet.»

#6. Docker

Ok, så misliker jeg kanskje ikke Docker. Det jeg misliker er at koderepoet mitt skal inneholde informasjon om serveren det kjøres på. Og at jeg må sitte og konfigurere det!

Dessuten må jeg ha det masete Docker-ikonet på toppen av Mac-en min som stadig maser om oppdateringer og restarter, samtidig som det bruker mer minne enn Slack.

Personlig foretrekker jeg at noen som faktisk forstår Linux tar seg av DevOps-biten. Så kan koden min trekkes inn i en mappe og startes når ting er satt opp.

#7. Jira og Scrum

Det er 2019, kan vi ikke bare sitte sammen og lage ting? Må vi ha drita lange møter hvor vi flytter ting opp og ned i Jira og diskuterer hva som er en «user story» eller ikke?

Må vi diskutere for ørtende gang hva som er oppgavene til en produkteier, hvem som skal tvinges til å være SCRUM master, og hvem som hører til i et SCRUM-team og ikke?

Kanskje vi kan unngå å bruke halve året på diskutere hva som er forskjellen på estimering i «story points» og timer? Kanskje vi kan slippe å ha lange backlog-grooming-møter fordi produkteieren ikke forstår hvordan en story skal formuleres?

Kan vi slutte å tro at alt som foregår i Jira er SCRUM? Kan vi slutte å ha standupmøter hvor vi «rapporterer »til produkteieren? Kan vi slutte å ansette folk direkte i SCRUM-roller, slik at vi aldri kan skrote rammeverket?

Neida, bare tulla, vi tar et år til med SCRUM, folkens.