5 trinn for koding for neste utvikler

De fleste av oss tenker sannsynligvis ikke på utvikleren som skal vedlikeholde koden vår. Inntil nylig gjorde jeg det heller ikke. Jeg skrev aldri bevisst uklart kode, men jeg etterlot heller aldri noen brødsmulekrummer.

Kent Beck om gode programmerere:

Enhver tosk kan skrive kode som en datamaskin kan forstå. Gode programmerere skriver kode som mennesker kan forstå.

Douglas Crockford om gode dataprogrammer:

Det koker ned til kommunikasjon og strukturene du bruker for å lette den kommunikasjonen. Menneskelig språk og dataspråk fungerer veldig forskjellig på mange måter, men til slutt bedømmer jeg et godt dataprogram etter dets evne til å kommunisere med et menneske som leser det programmet. Så på det nivået er de ikke så forskjellige.

Det er vanskelig å oppdage formål og intensjon selv i den best skrevne koden. Alle brødsmulekrummer som forfatteren etterlater, kommentarer, utfyllende navngiving og konsistens, er enormt nyttig for neste utviklere.

Jeg begynner med å se etter mønstre. Mønstre kan finnes på mange steder, inkludert variabelnavn, klasseoppsett og prosjektstruktur. Når de er identifisert, gir mønstre innsikt i den forrige utviklerens intensjon og hjelper til med å forstå koden.

Hva er et mønster? Et mønster er en gjenbrukbar løsning på et tilbakevendende problem. Tenk på en dør. Når et rom må tillate mennesker å komme inn og ut og samtidig opprettholde isolasjon, implementeres dørmønsteret. Nå virker dette åpenbart, men på et tidspunkt var det det ikke. Noen opprettet dørmønsteret som inkluderte dørhåndtaket, hengslene og plasseringen av disse komponentene. Gå inn i ethvert hjem og du kan identifisere enhver dør og dens komponenter. Stilene og fargene kan være forskjellige, men komponentene er de samme. Programvare er det samme.

Det finnes kjente programvaremønstre for vanlige programvareproblemer. I 1995 ble “Design Patterns: Elements of Reusable Object-Oriented Software” publisert som beskriver vanlige programvaremønstre. Denne boken beskriver vanlige problemer som oppstår i de fleste programvareapplikasjoner og tilbyr en elegant måte å løse disse problemene på. Utviklere skaper også sine egne mønstre mens de løser problemer de møter regelmessig. Selv om de ikke publiserer en bok, hvis du ser nøye nok, kan du identifisere dem.

Noen ganger er det vanskelig å identifisere mønstre. Dette gjør det vanskelig å forstå koden. Når du befinner deg i denne situasjonen, inspiser koden, se hvordan den brukes. Start en omskriving. Spør deg selv, hvordan ville du oppnå det samme resultatet. Ofte når du reiser gjennom tankeprosessen til en algoritme, får du innsikt i den andre utviklerens implementering. Mange av oss har tilbøyeligheten til å omskrive det vi ikke forstår. Motstå denne impulsen! Den eksisterende implementeringen er testet i praksis og din er det ikke.

Noen kode er bare irriterende, ta kontakt med en kollega — et annet sett med øyne hjelper alltid. Gå gjennom koden sammen. Du vil bli overrasket over hva dere to vil finne.

Her er 5 tips for å etterlate brødsmulekrummer for neste utviklere

1. Mønstre
Bruk kjente mønstre, lag dine egne mønstre. Hold deg til et konsistent paradigme gjennom hele koden. For eksempel, ikke ha 3 tilnærminger til datakjøring.

2. Konsistens
Dette er langt det viktigste aspektet ved koding. Ingenting er mer frustrerende enn å finne inkonsistent kode. Konsistens tillater antagelser. Hver gang et spesifikt programvaremønster oppstår, bør det antas at det oppfører seg på samme måte som andre forekomster av mønsteret.

Inkonsistent kode er et mareritt, tenk deg å lese en bok der hvert ord betyr noe annet, inkludert det samme ordet på forskjellige steder. Du måtte slå opp hvert ord og bruke store mengder mental energi på å oppdage intensjonen. Det er frustrerende, kjedelig og smertefullt. Du blir gal! Gjør ikke dette mot neste utvikler.

3. Utfyllende navngiving
Dette er ditt språk. Dette er ordene i historien din. Vev dem godt.

Dette inkluderer klassenavn, metodenavnavn, variabelnavn, prosjektnavn og egenskapsnavn.

Ikke gjør:

if(monkey.HoursSinceLastMeal > 3)
{
    FeedMonkey();
}

Gjør:

int feedInterval = 3;

if(monkey.HoursSinceLastMeal > feedInterval)
{
    FeedMonkey();
}

Det første eksemplet har 3 hardkodet i if-setningen. Denne koden er syntaktisk korrekt, men intensjonen med tallet 3 forteller deg ingenting. Når du ser på egenskapen den evalueres mot, kan du anta at det virkelig er 3 timer. I virkeligheten vet vi det ikke. Vi gjør en antagelse.

I det andre eksemplet setter vi 3 til en variabel kalt ‘feedInterval’. Intensjonen er klart angitt i variabelnavnet. Hvis det har gått 3 timer siden siste måltid, er det på tide å mate apen. En bieffekt av å sette variabelen er at vi nå kan endre fôringsintervallet uten å endre logikken.

Dette er et konstruert eksempel, i et stort stykke programvare er denne typen kode selvdokumenterende og vil hjelpe neste utvikler med å forstå koden.

4. Kommentarer
Kommentarer er et tveegget sverd. For mye kommentering øker vedlikeholdskostnadene, for lite etterlater utviklere usikre på hvordan koden fungerer. En tommelfingerregel er å kommentere når den gjennomsnittlige utvikleren ikke vil forstå koden. Dette skjer når antagelsene ikke er åpenbare eller koden er uvanlig.

5. Kode enkelt
Etter min faglige mening er det å skrive kompleks kode det største misstakket blant utviklere.

Steve Jobs om enkelhet:

Enkelt kan være vanskeligere enn kompleks: Du må jobbe hardt for å få tankene dine rene for å gjøre det enkelt. Men det er verdt det til slutt fordi når du kommer dit, kan du flytte fjell.

Kompleksitet kommer i mange former, noen av dem inkluderer: fremtidssikring, altfor komplekse implementeringer, for mye abstraksjon, store klasser og store metoder.

For mer om å skrive ren og enkel kode, se Uncle Bobs bok Clean Code og Max Kanat-Alexanders Code Simplicity

Avslutning

Å lese kode er vanskelig. Med noen få enkle trinn kan du sikre at neste utvikler vil forstå koden din.