Production Quality Code Survival Guide – erfaringer fra en nybegynner på veien fra gutterommet mot All-Pro.

Skrittene fra hobbykode og øvinger fra studietiden til det jeg så riktig pompøst har kalt Production Code Quality er mange og det er vel strengt tatt helt umulig å bli helt utlært, men her er uansett noen av de erfaringene jeg har gjort meg det første året som utvikler.

En forklaring av begrepet Production Code Quality kan jo også være greit. Denne bloggen har en god forklaring: https://javarevisited.blogspot.no/2011/09/how-to-write-production-quality-code.html som kan oppsummeres til følgende:

  • Det forventes at systemet er responsivt. Folk hater å vente!
  • Når noe går galt kan ikke hele systemet tryne!
  • I løpet av tiden systemet er i bruk kan du banne på at all slags input vil dukke opp og alle slags scenarier vil inntreffe.

Så hvilke muligheter har en til å komme opp i marsjfart som fersking? Her er det jeg vil anbefale:

  • Les en god bok om temaet! Det finnes bøker om alt, også god koding. Du finner flere fine bøker som f. eks. The Pragmatic Progammer, Beatiful Code, men den jeg vil anbefale (som nå også har blitt tatt i bruk i internsertifiseringen i firmaet) er Clean Code. Det er vel ikke akkurat en bok en leser fra perm til perm, men heller en slags guidebok i hverdagen.
  • Gjør det enkelt! Skriv kode med fokus på lesbarhet og ikke la deg alltid friste til å refaktorere alt inn på en linje. Det kan ofte ta noen måneder fra du sjekker inn en kodesnutt til den blir satt i produksjon og feil kan bli rapportert inn. Og det blir de! Når det skjer er det mest sannsynlig du som må inn å feilsøke og credden du fikk fra IRC for å være fancy imponerer ingen når feilen er kritisk og du ikke har snøring på hva som har skjedd. For å sitere en klok mann ved navn Brian Kernighan:“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?”
  • Logg! Dette går forøvrig litt i samme spor som punktet over. Det går ikke lang tid før du kommer opp i kompleksitet og snakker med andre systemer du ikke får sett på koden til og da er det greit å logge. Å lese logger er heller ikke spesielt gøy så kryptiske koder og beskjeder anbefales ikke. Logging er som regel noe som blir lagt på helt til slutt (før du går i produksjon), så å lage sin egen lille logger for egen bruk er å anbefale.
  • Spør en erfaren utvikler! Ofte kommer en over relativt “klassiske” programmerings problemer det kan være greit å få litt hjelp til å løse. Eksempler på dette kan være Regular Expressions eller jobbing med datastrukturer. De erfarne driver kanskje  ikke like mye med programmering lenger og blir stort sett mast på når noe ikke funker, så om du nevner RegEx eller sender en mail med HashSet i emnetfeltet vil de som regel stå i kø for hjelpe deg og du vil også lære mye nyttig av en dyktig utvikler!
  • Generelt sett er det også alltid bedre å spørre en gang for mye, slik at en er sikker på at en går frem på best muligmåte. Selv om de erfarne kanskje surmuler litt er de også enige i dette. Det er også lurt å tenke seg nøye om og fokusere på hva som egentlig er problemet som skal løses før en gjør det utviklere liker best, sette igang med å skrive kode. Mang en gang har jeg satt i gang for tidlig og kodet opp en del før jeg fikk den ordentlige forståelsen av problemet jeg skulle løse og da må som regel det meste skrapes.
  • Ha en sandkasse du kan leke i. Når en skal utvikle en liten bit i en komplisert del av systemet kan det ofte være greit å ha et eget lokalt prosjekt til å prøve ut løsningen uten for mye overhead. Logikk som for eksempel skal brukes av en webside kan være greit å verifisere ved hjelp av en liten applikasjon som bruker konsollvinduet.
  • Vær bevisst når du koder. Prøv å løft blikket og tenk fremover. Sjansene for at komponenten med tiden skal utvides er stor så løs det som kan løses generelt generelt og spesialiser ved behov. Muligheten for gjenbruk vil også øke.

Høres dette overkommelig ut ? Bra. Er det noe du savner eller er uenig i ? Bruk gjerne kommentarfeltet.

 

Konsulent og .NET utvikler i Visma Consulting. Del av Nytt Krutt 2011. Master i informatikk fra NTNU.
Kontakt Kristian: