Produkteieren setter seg ned ved siden av deg. “Vi trenger et innloggingssystem”, sier hen. Som utvikler svarer du, forhåpentligvis: “Hvorfor det?”
¶Hvorfor det?
Det er ikke for å være vanskelig. Du har nettopp blitt bedt om å lage en løsning. Hva du skal løse er du ikke sikker på. Faren for å bruke tid på å lage noe som ikke løser noens egentlige problem, er stor.
Du må stille spørsmålet et par ganger til, men til slutt vet du hvilket problem du skal løse. Det neste naturlige spørsmålet er da: “Hva er det minste steget vi kan ta mot å løse problemet?”
Små, langsomme steg er fine greier. Du bruker ikke altfor mye energi på å ta dem, og skulle du oppdage at du er på ville veier tar det relativt kort tid å komme seg tilbake til utgangspunktet igjen.
Disse to spørsmålene er, for meg, kjernen av smidig utvikling. Det er selvfølgelig en del andre ting som inngår i metodikken, men det aller viktigste er å identifisere den faktiske løsningen som skal bygges, for så å ta små skritt på veien mens du hele tiden evaluerer om du er på riktig vei.
Heldigvis opplever jeg at vi, som bransje, er blitt flinkere til å stille disse viktige spørsmålene. Det er ett unntak. Vi utviklere er dårlige på å rette slike spørsmål mot oss selv og verktøyene vi velger å bruke.
¶La oss ta et eksempel
Jeg ser for eksempel at veldig mange der ute bruker React. Er det egentlig så positivt?
Det er ikke det at jeg har noe imot React. Tvert om mener jeg React er et veldig godt verktøy til å løse det problemet det ble designet for å løse: å holde grensesnittet oppdatert med applikasjonens tilstand. Det jeg er mer undrende til er om “alle” har det problemet å løse i utgangspunktet. Er React virkelig nødvendig alle stedene det brukes?
“Det er en grunn til at React er så utbredt som det er,” tenker du kanskje, men jeg er neimen ikke så sikker. “La oss bruke React” er påfallende likt “Vi skal bygge et innloggingssystem”. Det kan godt hende du trenger det på sikt, men det betyr ikke nødvendigvis at du utvikler løsningen raskere ved å håndtere all den kompleksiteten akkurat nå.
For React fører absolutt med seg en hel del kompleksitet.
¶Kompleksitetene med React
React er en egen abstraksjon som ligger på toppen av HTML. I tillegg til å vite hvordan nettleseren fungerer, er det nå også en stor fordel å vite hvordan React interagerer med nettleseren. Bare det å velge React betyr at du, og dine kollegaer, må beherske mer enn om dere bare holdt dere til grunnleggende HTML.
Ikke nok med det. React, i hvert fall slik de fleste bruker det, krever et byggeverktøy. Det finnes flere, men uansett hvilket du velger må du bruke noe tid på å sette det opp slik at det funker bra med resten av systemet. Du kan også banne på at når tiden kommer for å gjøre justeringer, så har det gått så langt tid at du har glemt alt du lærte når du satt det opp. Eventuelt så har personen som satte det opp sluttet.
Frontenden din må nå også innhente informasjonen som brukeren vil se, som et eget steg. Du må derfor ta stilling til hvordan (REST, GraphQL, m.m.) og hva brukeren skal se mens informasjonen lastes inn. Hvordan, eller om, informasjonen skal mellomlagres er også noe du må ha en plan for.
Hvis du også har tatt det vanlige valget om at frontenden skal være én “side” og en kodebase, må du også finne ut hvordan adressefeltet i nettleseren skal håndteres, og hvordan du skal håndtere alle tilstander som vil oppstå på tvers av alle sider. Ettersom alt nå egentlig bare er én side, må du også finne ut hvordan du håndterer at hele appens CSS er lastet inn samtidig.
All kompleksiteten nevnt over har ingenting med problemet som skal løses å gjøre. Det er utelukkende kompleksitet som stammer fra valget av å bruke React. Hadde valget istedenfor falt på å servere ren HTML fra backend, ville mye av kompleksiteten forsvunnet.
Det er lett å tenke at du en eller annen gang kommer til å trenge mer enn hva du får ut av boksen med HTML, og at du derfor like godt kan innføre all kompleksiteten med en gang. Jeg tenker at det uansett er lurt å utsette det så lenge som mulig. Det er overraskende mye som kan løses med ren HTML om dagen, og selv når du trenger noe mer så kan du spare mye tid ved å bruke React bare der du trenger det.
Hvis du for eksempel trenger en skreddersydd datovelger i et skjema, så implementer bare selve datovelgeren i React, og len deg på standard nettleseroppførsel når du skal sende datoen til backend. Eller hvis du har én komplisert side med mye dynamisk oppførsel og tilstand som lett kan komme ut av synk, så bruk React på den ene siden.
Når du bruker React akkurat der du trenger det, så reduserer du også mengden kompleksitet som må håndteres. Kanskje du ikke trenger et eget tilstandsbibliotek ala Redux hvis du kun bruker React for en enkelt komponent eller side om gangen. Kanskje dataen som trengs for å vise komponenten kan lastes sammen med siden, og dermed spare deg for asynkrone kall til backend? Kanskje du ikke trenger noe spesielt for å håndtere CSS, da du uansett bare har den CSSen som gjelder for en enkelt side lastet inn samtidig?
¶Unngå unødvendig kompleksitet
Poenget her er ikke at React, eller noe annet tilsvarende rammeverk for den saks skyld, er negativt. Faktisk kunne jeg skrevet en tilsvarende artikkel om mikrotjenester, bruk av skytjenester og AI.
Poenget er at vi bør unngå unødvendig kompleksitet der vi kan. Der vi ikke kan unngå den, burde vi begrense det til der det faktisk har nytte for seg. Målet med dette er å utvikle raskere, gjennom å lage mindre kompliserte løsninger der vi kan slippe unna med det.
Smidig utvikling, rett og slett.
