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.
Nå bør alle utviklere være fullstack
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.
📍me, needing to style thing
— CSS-Tricks (@css) December 28, 2018
|
|
| _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
📍BEM |
_ _ _ _ _ _ _ _ _ _ _ _ _ _|
|
|
|
📍.header-large h1:not(:first-child) time span
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.
Den årlige CSS-in-JS krigen er i gang!
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.
- Vi tror 2019 blir Kotlins store år!
Bekk kårer Angular, Backbone og Flow som årets tapere.
#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.
watching Josua Bloch, Chief Java Architect @ Google, give a presentation. Reminded why Java is so excessively verbose.. :)
— Jeff Atwood (@codinghorror) January 18, 2010
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.
– Jeg har blitt veldig begeistret for TypeScript
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.
My hobby: stalking @dan_abramov 's Twitter feed to see him helping people who are confused about React/Redux, and pasting in more links :)
— Mark Erikson (@acemarke) April 29, 2017
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.
Slik skriver de testene sine i Sparebank 1
#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?
Fiken blåser i SCRUM og skytjenester, men elsker Kotlin
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.
