Forståelse begynner med uttrykksfulle navn

I 2018 ble jeg med på et stort prosjekt halvveis gjennom utviklingen. De opprinnelige ingeniørene hadde gått videre og etterlatt seg komplisert og udokumentert kode. Å jobbe med denne typen kode er utfordrende fordi du ikke kan skille rørleggerarbeidet fra forretningsdomenet. Dette gjør feilsøking vanskelig og endringer uforutsigbare fordi du ikke vet hvilken påvirkning de har. Det er som å prøve å redigere en bok uten å forstå ordene.

Mange ingeniører tror at suksess måles når koden kompilerer. Jeg mener det er når en annen ingeniør (eller deg selv om seks måneder) forstår “hvorfor” i koden din. De opprinnelige ingeniørene hemmet fremtidige ingeniører ved ikke å dokumentere og bruke obskure navn. Navnene er noen ganger det eneste vinduet inn i den forrige ingeniørens tankeprosess.

Donald Knuth sa berømt:

Programmer er ment å bli lest av mennesker og bare tilfeldigvis for datamaskiner å utføre. – Donald Knuth

Navngiving

Navngiving er vanskelig fordi det krever merking og definering av hvor og hvordan en del passer inn i en applikasjon.

Phil Karlton, mens han var hos Netscape, observerte:

Det er bare to vanskelige ting innen datavitenskap: cache-invalidering og navngiving av ting.
— Phil Karlton

Vi ser koden vår gjennom linsen av ord og navn vi bruker. Navn skaper et språk for den neste ingeniøren å forstå. Dette språket maler et bilde av hvordan forfatteren bygget bro mellom forretningsdomenet og programmeringsspråket.

Ludwig Wittgenstein, en filosof i første halvdel av det 20. århundre, sa:

Grensene for mitt språk betyr grensene for min verden. – Ludwig Wittgenstein

Språket i programvaren vår er bare så beskrivende som navnene vi bruker, og å bruke vage navn gjør programvarens formål utydelig; å bruke beskrivende navn bringer klarhet og forståelse.

Tenk deg å besøke et land hvor du ikke snakker språket. En enkel forespørsel som å spørre om å bruke toalettet bringer forvirrede blikk. Manglende evne til å kommunisere er frustrerende, kanskje til og med skummelt. En ingeniør føler det samme når de konfronteres med forvirrende, uklare, eller enda verre, misvisende navn.

Denne følelsen oppleves best.

Erfaring

Undersøk det første kodeutdraget, hva gjør denne koden? Hva er hvorfor?

Ta deg tid.

public class StringHelper
{
    public string Get(string input1, string input2)
    {
        var result = string.Emtpy;
        if(!string.IsNullOrEmtpy(input1) && !string.IsNullOrEmtpy(input2))
        {
            result = $"{input1} {input2}";
        }
        return result;
    }
}

Koden ovenfor er en enkel sammenkjeding av to strenger. Det koden ikke forteller deg er “hvorfor.” “Hvorfor” er så viktig, uten det er det vanskelig å endre oppførsel uten å forstå påvirkningen. Selvfølgelig vil undersøkelse av kodens bruk sannsynligvis avsløre “hvorfor,” men det er poenget. Du bør ikke måtte oppdage kodens formål, i stedet burde forfatteren ha etterlatt seg ledetråder, det er deres ansvar å gjøre det.

La oss se på koden igjen, men med litt “hvorfor” strødd inn.

Igjen, ta deg tid, observer forskjellen du føler når du leser denne koden.

    public class FirstAndLastNameFormatter
    {
        public string Concatenate(string firstName, string lastName)
        {
            var fullName = string.Emtpy;
            if(!string.IsNullOrEmtpy(firstName) && !string.IsNullOrEmtpy(lastName))
            {
                fullName = $"{firstName} {lastName}";
            }
            return fullName;
        }
    }

“Hvorfor” bringer koden til live, det er en historie å lese.

Kommuniser

Å kommunisere intensjonen og designet til den neste ingeniøren lar programvare leve og vokse fordi hvis ingeniører ikke kan modifisere programvaren, dør den. Dette er en tragedie, enda mer når det er et resultat av dårlig design og mangel på uttrykksfullhet — hver er forebyggbar med kunnskap.

Gjør den neste ingeniøren en tjeneste og vær uttrykksfull i koden din. Bruk beskrivende navn og fang opp “hvorfor” fordi hvem vet, den neste ingeniøren kan være deg selv.