5 Berømte Programmeringscitater, forklaret

at være programmør er at tilmelde dig et liv med konstant læring. Fountain af nye-nye funktioner, nye sprog, nye værktøjer, nye rammer—aldrig stopper fosser. Men datalogi er også et overraskende traditionelt felt, der er baseret på tidstestede principper. Vi har tilføjet objektorienteret programmering, moderne udstyr og kunstig intelligens. Men på trods af disse ændringer, mange af de indsigter, der først blev formuleret for en generation siden, gælder stadig i dag.

i denne artikel har jeg dissekeret et par af mine yndlingscitater om datalogi. Den eneste betingelse, jeg sætter, er, at hvert citat skal være mindst tyve år gammelt. For mens gammel teknologi hurtigt bliver ubrugelig, har de gamle Bud fra vores programmeringsforfædre meget mere opholdskraft.

“alle problemer i datalogi kan løses af et andet niveau af indiretning.”- David hjul

her er et ofte gentaget compsci-citat, som få udviklere ønsker at forklare. Men det er en af mine foretrukne programmerings sandheder, fordi det rammer kernen i, hvad kodning handler om.

den nemmeste måde at begynde at tænke på iretning er at forestille sig lag. Sig for eksempel, at du har et lille projekt, der skal passe komponent A til komponent B:

begge komponenter er standardiserede, så du kan ikke bryde dem åbne og ændre den måde, de fungerer på. Du kan bygge en helt ny komponent (PlugTwoProngVariant), men det er meget arbejde og unødvendig duplikering. En bedre tilgang er at tilføje et lag mellem de to stykker — en adapter, der passer ind i begge komponenter og oversætter mellem dem.

nu, hvis indirection bare handlede om at tilføje et nyt lag til at passe uforenelige stykker sammen, ville det være rart, men snævert nyttigt. Men ideen om at løse problemer ved at bygge omkring dem er et koncept, der strækker sig fra bunden til toppen af computing. Du ser det, når du forsøger at tilpasse en ny datamodel til en gammel brugergrænseflade. Du ser det, når du forsøger at tilpasse en ældre applikation til en ny backend for internettjenester. Du ser det, når du har brug for at spænde på funktioner på højere niveau som logning og caching eller koordinere tjenester på højere niveau som messaging og transaktioner. Og øverst i pyramiden kommer du til sjældne emner som maskinindlæring (når du ikke kan kode den adfærd, du har brug for, skal du skrive et andet lag kode, der finder ud af det for dig).

masser af mennesker vil fortælle dig, at kodning handler om at skrive eksplicitte instruktioner på et sprog, som selv idiotcomputere kan forstå. Men Davids citat afslører en bedre indsigt. God programmering handler om at klatre op ad abstraktionsstigen for at komme til de mest generelle løsninger.

Bonus relateret citat:

Indirection er kraftfuld, men der er en omkostning til kompleksitet. Folk citerer meget sjældent Hjulers øjeblikkelige opfølgningsanmærkning om indirection:

“men det vil normalt skabe et andet problem.”- David hjul

denne sandhed har holdt programmører i erhvervslivet lige siden.

om enkelhed

“enkelhed er en forudsætning for pålidelighed.”- Edsger Dijkstra

der er ingen mangel på kloge programmører, der advarer os om ikke at overkomplicere vores kode. Men få sætter omkostningerne ved kompleksitet klarere end den hollandske computervidenskabspioner Edsger Dijkstra.

her er indsigten: du vælger ikke enkelhed som en gave til fremtiden. Du gør det ikke, fordi du forventer chancen for at genbruge din kode, eller fordi du vil have den til at se renere ud ved en kodeanmeldelse, eller fordi du vil gøre det lettere at ændre. (Selvom alle disse fordele er værdifulde!) Du gør det, fordi enkelhed er en forudsætning. Uden enkelhed kan du aldrig have pålidelig kode, som du kan stole på for at drive en virksomhed eller håndtere dine data.

for at acceptere Dijkstras punkt skal vi omdefinere, hvad “god kode” betyder. Det er ikke den korteste kode. Det er ikke nødvendigvis den hurtigste kode. Det er bestemt ikke den klogeste kode. Det er kode, der kan stole på.

Bonusrelateret citat:

en af de bedste måder at holde kode enkel er at huske, at mindre er mere. Dijkstra tilbyder en måling, der hjælper os med at huske det:

“hvis vi ønsker at tælle kodelinjer, skal vi ikke betragte dem som ‘producerede linjer’, men som ‘brugte linjer.'”—Edsger Dijkstra

om læsbarhed og omskrivninger

“det er sværere at læse kode end at skrive det.”- Joel Spolsky

ved første øjekast synes dette citat af programmellegenden og medskaberen Joel Spolsky at være sandt, men bedragerisk overfladisk. Ja, kode kan være tæt, kortfattet og kedeligt lang. Og det er ikke bare andres kode. Hvis du ser på dit eget arbejde fra et år siden, har du sandsynligvis brug for lidt tid til at sortere den logik, du engang kendte intimt.

men Spolskys indsigt kommer med en vri. Faren for kode, du ikke kan læse, er ikke kun det åbenlyse (det er svært at ændre det og forbedre det). I stedet er den større fare, at kompleks kode ser ud til at være værre, end den faktisk er. Faktisk er byrden ved at forsøge at forstå en andens allerede skrevne kode så stor, at du måske bliver fristet til at gøre det, Spolsky kalder den værst mulige fejl—beslutter at omskrive koden fra bunden.

det er ikke, at omskrivninger ikke kan forbedre arkitekturen i et system. De kan helt sikkert. Men disse forbedringer kommer på store omkostninger. De nulstiller uret ved test og fejlrettelse, to aktiviteter, der tager langt længere tid end blot kodning. Omskrivninger er fristende, fordi de spiller på en af de mest almindelige forstyrrelser i programmeludvikling: vi undervurderer indsatsen for at gøre ting, der er konceptuelt enkle. Det er derfor, de endelige 5% af et projekt tager 50% af tiden. Nemme ting kan være overraskende tidskrævende! Og intet virker lettere end at løse et problem, du allerede har løst.

så hvis du ikke skulle omskrive alt for at gøre det perfekt, hvad er den bedre løsning? Svaret er at få alle udviklere involveret i konstant bid-størrelse refactoring. Dette giver dig små, kontinuerlig kode forbedring-reelle belønninger med minimale risici. Du kan forbedre læsbarheden undervejs.

Bonusrelateret citat:

hvis du stadig er i tvivl om vigtigheden af læsbarhed, hjælper Martin Birger med at sætte det i perspektiv:

“enhver fjols kan skrive kode, som en computer kan forstå. Gode programmører skriver kode, som mennesker kan forstå.”- Martin Birger

med andre ord er en programmørs job ikke kun at få tingene til at fungere, men at få tingene til at give mening.

om gentagelse

“gentag ikke dig selv. Hvert stykke viden skal have en enkelt, entydig, autoritativ repræsentation i et system.”- Andy Hunt og Dave Thomas

enhver selvrespektende programmør ved, at gentagelse er hjertet i meget ondt. Hvis du skriver det samme på forskellige steder, laver du ekstra arbejde med at skrive, teste og debugging. Endnu værre, du introducerer muligheden for uoverensstemmelser — for eksempel, hvis en del af koden opdateres, men andre, lignende rutiner bringes ikke til enighed. Et inkonsekvent program er et program, du ikke kan stole på, og et program, du ikke kan stole på, er ikke længere en levedygtig løsning.

kode er dog ikke det eneste sted, hvor gentagelse skaber kaos. Denne version af den berømte “gentag ikke dig selv” (tør) regel udvider princippet om ikke-duplikering til at dække de andre steder, hvor uoverensstemmelser kan skjule. Vi taler ikke længere om kodeduplikation. Vi taler også om gentagelse i et system — og et system har mange forskellige måder at kode viden på. De omfatter:

• Kodesætninger
• Kodekommentarer
• udvikler-eller klientdokumentation
• Dataskemaer (for eksempel databasetabeller)
• andre specifikationer, som testplaner, arbejdsgangsdokumenter og byggeregler

alle disse niveauer kan overlappe hinanden. Og når de gør det, risikerer de at introducere forskellige versioner af den samme virkelighed. Hvad sker der for eksempel, hvis dokumentationen beskriver en måde at arbejde på, men applikationen følger en anden? Hvem ejer sandheden? Hvad sker der, hvis databasetabellerne ikke matcher datamodellen i koden? Eller kommentarerne beskriver driften af en algoritme, der ikke svarer til dens faktiske implementering? Hvert system har brug for en enkelt, autoritativ repræsentation, hvorfra alt andet stammer.

i øvrigt er konkurrerende versioner af sandheden ikke kun et problem i små projekter eller dårligt designet kode. Et af de bedste eksempler brød ud i offentligheden med kampen mellem HTML5 og HTML5. En lejr hævdede, at specifikationen var den officielle sandhed, og søgere skulle rettes for at følge den. Den anden fraktion hævdede, at bro.ser adfærd var de facto standard, fordi det er, hvad designere havde i tankerne, da de skrev hjemmesider. I sidste ende vandt bro.ser-versionen af sandheden. Fra det tidspunkt var HTML5, hvad bro.sere gjorde — inklusive de genveje, de tillod, og de fejl, de accepterede.

Bonus relateret tilbud:

muligheden for kode og kommentarer til at modsige hinanden har åbnet en heftig debat om, hvorvidt kommentarer gør mere skade end gavn. Fortalerne for ekstrem programmering behandler dem med åben mistanke:

“kode lyver aldrig; kommentarer gør nogle gange.”- Ron Jeffries

om hårde problemer

“der er kun to hårde ting inden for datalogi: cache ugyldiggørelse og navngivning af ting.”- Phil Karlton

ved første øjekast virker dette citat som en morsom, men almindelig programmeringsvittighed. Kontrasten mellem en noget, der lyder svært (cache invalidation) og noget, der lyder smertefrit (navngivning ting) er øjeblikkeligt relatable. Hver programmør har investeret timers arbejde med at løse et latterligt trivielt problem, som et par parametre, der er bestået i den forkerte rækkefølge eller en inkonsekvent aktiveret variabel (Tak JavaScript). Så længe mennesker har brug for at samarbejde med maskiner for at få tingene gjort, programmering vil være en mashup af systemplanlægning på højt niveau og trivielle skrivefejl.

men hvis du tager et andet kig på Phil Karltons citat, er der mere at pakke ud. At navngive ting er ikke svært, bare fordi en programmørs liv regelmæssigt ødelægges af små hovedpine. Det er også fordi spørgsmålet om navngivning er faktisk kanten af hver programmør vigtigste job: programmel design. Med andre ord, Hvordan skriver du kode, der er klar, ren og konsekvent?

der er mange måder at få navngivning forkert på. Vi har alle set variabler opkaldt efter datatyper (myString, obj), forkortelser (pc for produktkatalog), nogle trivielle implementeringsdetaljer (swappable_name, formUserInput), eller endda intet overhovedet (ret_value, tempArray). Det er let at falde i fælden med at navngive en variabel baseret på hvad du laver med det i det øjeblik snarere end hvad det indeholder. Og boolske værdier er særligt vanskelige — er progress indstillet, når fremskridt starter, angiver, at du skal vise fremdriftsoplysninger i brugergrænsefladen eller markere noget helt andet?

men variabelnavne er kun begyndelsen. Navngivningsklasser rejser spørgsmålet om, hvordan du deler kode i uafhængige dele. Navngivning af offentlige medlemmer former, hvordan du præsenterer grænsefladen, der gør det muligt for en del af din applikation at interagere med en anden. Låsning af disse navne beskriver ikke bare, hvad et stykke kode kan gøre, det bestemmer, hvad det vil gøre.

Bonus relateret tilbud:

“der er to hårde ting i datalogi: cache ugyldiggørelse, navngivning af ting og off-by-one fejl.”- Leon Bambrick