– Alle elsker å snakke om den nyeste "bleeding edge"-teknologien. Det er veldig lite fokus på hvordan man faktisk skal vedlikeholde systemene.
Det sa Merethe Granevang på AdaCon-konferansen som ble avholdt på Ada Lovelace-dagen den 10. oktober i Oslo.
– Nei, dette handler ikke bare om kvinner
Granevang er seniorutvikler i Creaza, og med 18 års utviklererfaring har hun også erfaring med teknisk gjeld – gamle løsninger som koster mye tid og penger å vedlikeholde.
På konferansen delte hun sine beste råd til utviklere om hvordan de kan unngå teknisk gjeld – og at koden blir så utdatert og vanskelig å jobbe med at du til slutt blir nødt til å kaste alt på skraphaugen og begynne på nytt.
#1: Velg et rammeverk med lang levetid
Det finnes en masse rammeverk der ute, og det kommer hele tiden nye. Granevang fraråder utviklere til å ukritisk hoppe på det nyeste.
– Du må velge et rammeverk med lang levetid. Hvis rammeverket dør, får du ingen oppdateringer, advarte hun tilhørerne på AdaCon-konferansen.
Hvis du bruker et rammeverk som er i ferd med å bli mindre populært, risikerer du at du ikke lenger får sikkerhetsoppdateringer, og heller ikke oppdateringer som gir støtte for ny funksjonalitet i HTML og JavaScript.
Du kan også risikere å bli bundet til gamle byggeverktøy som ikke fungerer på nyere operativsystemer. Og det kan bli vanskelig å ansette utviklere.
«Er det mye brukt, er det liten risiko for at det vil dø med det første.»
Det er selvfølgelig ikke alltid lett å vite om hvorvidt et rammeverk kommer til å ha lang levetid eller ikke. En måte å finne ut det på er rett og slett å se på hvor populært det er, gjennom undersøkelser som State of JS, stjerner på GitHub, og så videre.
– Er det mye brukt, er det liten risiko for at det vil dø med det første.
Og her gjelder det ifølge Granevang å se på trender over lang tid. Selv om mange snakker om alternativer til React, er React fortsatt ett av de mest brukte rammeverkene – og vil neppe forsvinne på lenge.
#2: Gjør det typesikkert
Granevang oppfordrer til å bygge en frontend som er typesikker.
– Da jeg først begynte å bruke TypeScript hatet jeg det! Nå har jeg jobbet med det i seks år.
Hun fortalte at hun aldri vil gå tilbake til vanlig JavaScript på store kodebaser eller kodebaser der mange utviklere jobber sammen.
– Det gjør koden så mye mer robust. Og det er så mye enklere å hoppe inn i ukjent kode og begynne å jobbe med den når den er typesikker.
#3: Bruk bare biblioteker du faktisk trenger
Vær forsiktig når du tar i bruk eksterne biblioteker. Biblioteker har gjerne avhengigheter, som igjen har avhengigheter, og så videre.
Det å holde alle bibliotekene oppdatert kan være et stort puslespill, og fort ende opp i det Granevang kalte "maintenance hell".
– Velg bare de bibliotekene du faktisk trenger!
– Overvåk avhengighetene til bibliotekene, og "wrap" bibliotekene i gjenbrukbare komponenter. Da er det lettere å bytte ut bibliotekene.
#4: Lag gjenbrukbare komponenter
Du bør lage gjenbrukbare komponenter. Og for å gjøre det lettere for utviklere på teamet å komme inn og enkelt ta komponenter i bruk anbefaler Granevang at du organiserer og visualiserer komponentene i et system.
– Bruk verktøy som Storybook til å visualisere det, eller du kan bare lage ditt eget.
Granevang anbefaler at når du skal lage en komponent, så bør du tenke først igjennom hva komponenten skal brukes til – og deretter hvordan den skal implementeres.
#5: Snakk med backend-utviklerne
Mange har en tendens til å tenke på datastruktur som et backendproblem – og noe backendutviklerne skal få styre med alene.
– Men mitt råd er at frontend og backend samarbeider. For det er kanskje frontendutviklerne som skal bruke dataene.
#6: Tenk tilgjengelighet fra start
Frontendløsningen du lager må være tilgjengelig for alle. Granevang råder alle frontendutviklere til å lese seg opp på hvilke lover og regler som gjelder.
Hun advarte også mot å la tilgjengelighet være en "ettertanke", noe man tenker at man skal fikse til slutt.
– Det er mye lettere å kode for tilgjengelighet mens du jobber, enn å legge det til senere. Da må du kanskje skrive om store deler av koden.
Her bør man følge web-standarder, og bruke HTML-tagger slik de er ment brukt.
– Hvis du trenger en knapp, bruk en knapp – ikke en div stylet som en knapp!
Granevang minnet også om viktigheten av å huske alt-tekster på alle media-elementer, og sørge for at rekkefølgen på DOM-elementer er slik at de gir mening for de som bruker skjermlesere.
«Hvis du trenger en knapp, bruk en knapp – ikke en div stylet som en knapp!»
– Unngå kortvarige trender
Ifølge Granevang er det mange grunner til teknisk gjeld, og det hun kalte en "akkumulering av suboptimale løsninger":
Kanskje har koden blitt mer kompleks over tid, prosjektet har endret retning slik at logikken ikke lenger gir mening, eller det er kanskje mange midlertidige "quick-fixer" som ingen har hatt tid til å rydde opp i.
Det kan også være gjort feil underveis, og kanskje enkelte av bibliotekene og rammeverkene man har brukt er utdaterte.
For å få ryddet opp i teknisk gjeld må det legges planer og settes av tid, og man må forklare viktigheten overfor prosjektlederne. Jo lenger man venter, jo mer ressurser krever det å rydde opp.
Frykter mer bruk-og-kast-koding
Det viktigste man kan gjøre for å unngå å havne i slike situasjoner, er å lage kode som er enkel å vedlikeholde og enkel å forstå.
– Og så må du gjøre alt du kan for å unngå kortlevde trender! sa Granevang.
Du kan se hele foredraget – og alle de andre AdaCon-foredragene på YouTube her: