Å vedlikeholde koden

Git, Pull Requests, Kvalitet, Workflows, Fire Eye-Prinsippet, Formater

Som nevnt i det forrige kapittelet, er Devops viktig for å vedlikeholde kode, men gjett hva – dette er også en teaminnsats, og i tillegg en forretningskritisk prioritet, fordi dårlig kode fører til dårlige ting.

Koding “Fri for alle” – hvor utviklere bare utvikler som de føler for – er langt, langt unna hvordan kode skal vedlikeholdes i et flott produktkodeoppslag.

Et av de oversette “hvorfor”-spørsmålene her er at koden er en intellektuell eiendel (IP) eid av selskapet og har en monetær verdi, om ikke i regnskapet så som en mulig eiendomsverdi hvis selskapet selges. Det alene gjør det verdt å holde koden vedlike.

Ytterligere – hvorfor skal koden være lesbar og oversiktlig? De viktigste funksjonene bør dokumenteres, minst på høydeplan (det er ekstremt vanskelig å holde dokumentasjon oppdatert i et raskt utviklingsmiljø, og kunne sakte ned utvikling mye).

Å ha koden i et git-arkiv sikrer at nye versjoner kan legges til og man alltid kan gå tilbake og spore hva som ble lagt til av hvem, og hvis du bruker et oppgavehåndteringssystem for å håndtere din backlog, kan du også spore billetten eller oppgaven bak, noe som gjør for en veldig god dokumentasjon av historien.

Dette er nyttig for å se hvorfor noe ble endret og hva som utløste det. Ved å jobbe i grener har utviklerne sin egen distribuert kopi av koden på sin egen datamaskin og kan samarbeide lett ved å trekke oppdateringer av koden hvis en annen utvikler har vært i gang med enten samme gren eller hvis nye funksjonsgrener ble lagt til hovedgrenen under en produksjonsutgivelse.

Les mer i "The CTO Playbook" tilgjengelig på Amazon/Kindle.