5 steg for å kode for neste utvikler

De fleste av oss tenker sannsynligvis ikke på utvikleren som skal vedlikeholde koden vår. Inntil nylig tenkte ikke jeg på ham heller. Jeg skrev aldri tilsiktet obskur kode, men jeg la heller aldri igjen noen brødsmuler.

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:

Alt 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 syvende og sist bedømmer jeg et godt dataprogram ut fra dets evne til å kommunisere med et menneske som leser det programmet. Så på det nivået er de ikke så forskjellige.

Å oppdage formål og hensikt er vanskelig selv i den best skrevne koden. Alle brødsmuler som forfatteren har lagt igjen, kommentarer, utfyllende navngiving og konsistens, er enormt nyttig for neste utviklere.

Jeg starter med å lete etter mønstre. Mønstre kan finnes mange steder, inkludert variabelnavn, klasseoppbygning og prosjektstruktur. Når de er identifisert, er mønstre innsikt i den forrige utviklerens hensikt og hjelper med å forstå koden.

Hva er et mønster? Et mønster er en repeterbar løsning på et tilbakevendende problem. Tenk på en dør. Når et rom må tillate folk å gå inn og ut, men samtidig opprettholde isolasjon, implementeres dørmønsteret. Dette virker åpenbart, men på et tidspunkt var det ikke det. Noen skapte dørmønsteret som inkluderte dørhåndtaket, hengslene og plasseringen av disse komponentene. Gå inn i et hvilket som helst 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 til vanlige programvareproblemer. I 1995 ble Design Patterns: Elements of Reusable Object-Oriented Software publisert, som beskrev vanlige programvaremønstre. Denne boken beskriver vanlige problemer som oppstår i de fleste programvareapplikasjoner og tilbød en elegant måte å løse disse problemene på. Utviklere skaper også sine egne mønstre mens de løser problemer de rutinemessig støter på. Selv om de ikke publiserer en bok, kan du identifisere dem hvis du ser nøye nok.

Noen ganger er det vanskelig å identifisere mønstrene. 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å samme resultat. Ofte når du følger tankeprosessen til en algoritme, får du innsikt i den andre utviklerens implementering. Mange av oss har tilbøyelighet til å skrive om det vi ikke forstår. Motstå denne trangen! Den eksisterende implementeringen er kampprøvd og din er ikke det.

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

Her er 5 tips for å legge igjen brødsmuler for neste utviklere

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

2. Konsistens
Dette er den desidert viktigste aspektet ved koding. Ingenting er mer frustrerende enn å finne inkonsistent kode. Konsistens tillater antakelser. Hver gang et spesifikt programvaremønster oppstås, bør det antas at det oppfører seg likt som andre instanser av mønsteret.

Inkonsistent kode er et mareritt, tenk deg å lese en bok hvor 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 hensikten. Det er frustrerende, kjedelig og smertefullt. Du blir gal! Ikke gjør dette mot neste utvikler.

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

Dette inkluderer klassenavn, metodenavn, 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 hensikten med tallet 3 forteller deg ingenting. Ved å se på egenskapen den evalueres mot, kan du anta at det egentlig er 3 timer. I virkeligheten vet vi ikke. Vi gjør en antakelse.

I det andre eksemplet setter vi 3 til en variabel kalt ‘feedInterval’. Hensikten er tydelig uttalt 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 å forstå koden.

4. Kommentarer
Kommentarer er et tveegget sverd. For mye kommentering øker vedlikeholdskostnadene, for lite gjør at utviklere er usikre på hvordan koden fungerer. En generell tommelfingerregel er å kommentere når den gjennomsnittlige utvikleren ikke vil forstå koden. Dette skjer når antakelsene ikke er åpenbare eller koden er utenom det vanlige.

5. Kod enkelt
Etter min faglige mening er det å skrive kompleks kode den største dumheten blant utviklere.

Steve Jobs om enkelhet:

Enkelt kan være vanskeligere enn komplekst: 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, enkel kode, se Uncle Bobs bok Clean Code og Max Kanat-Alexanders Code Simplicity

Avslutning

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