De fleste kjenner til denne når de ser den:

$$ E = mc^2 $$

Men om du skulle forklare den for noen som ikke kjenner til den, hvorfor ikke skrive:

$$ Energi = MasseLysetshastighet^2 $$

Det er heldigvis sjelden vare at man må fortelle utviklere at de må navngi variabler med navn som gir mening og uttrykker intensjon og det er sjelden vi ser slik kode i produksjon: var = a, b, c... Grunnen til at man ikke ser sånn kode er at det er vanskelig å lese i etterkant og at kode også fungerer som kommunikasjon og samarbeid mellom mennesker, ikke bare som instruksjoner til maskiner.

Selv om vi som industri har kommet langt i forhold til å ha et bevisst forhold til hvor viktig det er å navngi kode riktig så viser erfaring at de som jobber med å utvikle eller designe programvare bruker mer tid på å lese kode enn å skrive kode. Hvilke grep kan du som utvikler ta for å motarbeide dette?

Bruk folkene rundt deg

Hva gjør du om det er vanskelig å forstå kode du må endre? Endringen kommer kanskje ved at det er kommet et nytt behov, eller at det har oppstått en feil som du må rette. Uansett hvorfor du må endre koden, så er det viktig at du forstår koden du skal endre på før du gjør endringen. Du har sikkert opplevd at en tilsynelatende triviell endring har påvirket deler av systemet på en uforutsett måte. Det kan være manglende automatisk testdekning eller at det finnes avhengigheter som ikke burde være der pga dårlig eller manglende design. Hva kan du gjøre for å redusere risikoen ved en slik endring og i tillegg gjøre det enklere for nestemann som skal endre koden du jobber med?

De fleste som driver med utvikling og design av programvare har et team rundt seg. Om du skal endre eksisterende kode og personen som har skrevet koden er på teamet, ville det vært naturlig å få input fra denne personen. Hva om den personen har sluttet? Jeg er en stor tilhenger av å bruke de folkene rundt meg uansett.

Om det er kode jeg ikke helt forstår, selv om jeg tror jeg har forstått det, så trekker jeg veldig ofte en eller flere på teamet til meg for å hjelpe meg med tankeprosessen. På denne måten får man flere synsvinkler på problemet. Dette er noen eksempler på svar jeg får om jeg trekker på flere som jeg kanskje ikke har reflektert over mens jeg skriver kode:

  • Har jeg klart å kommunisere intensjon?
  • Er denne intensjonen like klar i koden og i testene jeg har skrevet?
  • Bør endringen flagges som en risiko?
  • Bør man varsle at man trenger litt ekstra testing på en del av det berørte systemet?
  • Bør man følge ekstra godt med etter at endringen er produksjonsatt?
  • Har vi dekket alle mulige use case?

Om man går tilbake til erfaringen med at det er vanskeligere å lese kode enn å skrive kode så er det faktisk veldig viktig å få tilbakemeldinger. Min erfaring er at jeg alltid produserer bedre kode om koden jeg skriver har blitt skrevet som et samarbeid mellom flere personer.

Mekanismer for samhandling

Der jeg jobber nå har man innført pull requests for at man alltid skal få en ekstra titt på koden av et teammedlem før endringen blir akseptert. Dette fungerer ofte bra om endringene er isolerte. Jeg mener likevel at tilbakemelding på en pull request ofte kommer for sent. Problemet er at den som skal gi tilbakemelding på en pull request sliter nettopp fordi det at å lese kode er vanskeligere enn å skrive den. Personen som skal akseptere en pull request har ikke hatt samme tid og mulighet til å sette seg inn i problemdomenet. For min del handler en pull request mer om å få på plass en rutine som tilrettelegger kommunikasjon før man aksepterer en endring. Er endringen liten så hjelper det kanskje bare med en samtale rundt endringen. Er det en større endring så kan det hende at en demonstrasjon av hva som er løst og en samtale om hvordan man har tenkt er nødvendig.

Det finnes mange måter å jobbe i team på som vil gjøre at kode som blir skrevet blir lettere å lese og forstå over tid. Parprogrammering, code reviews, pull request for å nevne noen. Hva som passer for deg og ditt team vil helt sikkert variere med teamsammensetting. Det viktigste er å være klar over at det å skape god programvare alltid vil være basert på hvor godt samarbeid man har. Resultatet vil aldri være bedre enn hvordan teamet du jobber på samarbeider og til slutt i hvilken retning dette teamet sammen drar.

Og til slutt

Tror du $$ E = mc^2 $$ var første utkast av den kjente ligningen og tror du at det var en person som kom fram til den uten å samarbeide med flere?

Dette blogginnlegget er forøvrig også et resultat av samhandling hvor jeg har fått konstruktive tilbakemeldinger fra et team rundt meg før det endelige resultatet nådde deg som leser.