5 Berømte Programmering Sitater, Forklart

å være programmerer er å registrere deg for et liv med konstant læring. Fontenen av nye-nye funksjoner — nye språk, nye verktøy—nye rammer-stopper aldri gushing. Men datavitenskap er også et overraskende tradisjonelt felt som er jordet i tidstestede prinsipper. Vi har lagt til objektorientert programmering, moderne maskinvare og kunstig intelligens. Men til tross for disse endringene, er mange av innsiktene som først ble formulert for en generasjon siden, fortsatt sanne i dag.

i denne artikkelen har jeg dissekert noen av mine favoritt sitater om datavitenskap. Den eneste betingelsen jeg angir er at hvert sitat må være minst tjue år gammel. Fordi mens gammel teknologi raskt blir ubrukelig, har de gamle budene til våre programmeringsforfedre mye mer utholdenhet.

“Alle problemer i datavitenskap kan løses av et annet nivå av iretning.”- David Wheeler

Her er et ofte gjentatt compsci-sitat som få utviklere vil forklare. Men det er en min favoritt programmering sannheter, fordi det slår i hjertet av hva koding handler om.

den enkleste måten å begynne å tenke på indirection er å forestille seg lag. For eksempel, si at du har et lite prosjekt som må passe komponent A til komponent B:

begge komponentene er standardiserte, Slik At du ikke kan bryte dem opp og endre måten de fungerer på. Du kan bygge en helt ny komponent (PlugTwoProngVariant), men det er mye arbeid og unødvendig duplisering. En bedre tilnærming er å legge til et lag mellom de to delene — en adapter som passer inn i begge komponentene og oversetter mellom dem.

nå, Hvis indirection handlet om å legge til et nytt lag for å passe inkompatible stykker sammen, ville det være fint, men smalt nyttig. Men ideen om å løse problemer ved å bygge rundt dem er et konsept som strekker seg fra bunnen til toppen av databehandling. Du ser det når du prøver å tilpasse en ny datamodell til et gammelt brukergrensesnitt. Du ser det når du prøver å tilpasse et eldre program til en ny webtjeneste backend. Du ser det når du trenger å stroppen på høyere nivå funksjoner som logging og caching, eller koordinere høyere nivå tjenester som meldinger og transaksjoner. Og på toppen av pyramiden kommer du til sjeldne emner som maskinlæring (når du ikke kan kode oppførselen du trenger, skriv et annet lag med kode som vil finne ut det for deg).

Mange mennesker vil fortelle deg at koding handler om å skrive eksplisitte instruksjoner på et språk som selv idiot datamaskiner kan forstå. Men David Wheeler sitat avslører en bedre innsikt. God programmering handler om å klatre på abstraksjonsstigen for å komme til de mest generelle løsningene.

Bonusrelatert sitat:

Indirection er kraftig, men det er en kostnad for kompleksitet. Folk svært sjelden sitere Wheeler umiddelbare oppfølging bemerkning om indirection:

“men det vil vanligvis skape et annet problem.”- David Wheeler

at sannheten har holdt programmerere i virksomhet siden.

På Enkelhet

“Enkelhet er en forutsetning for pålitelighet.”- Edsger Dijkstra

det er ingen mangel på kloke programmerere advarer oss om ikke å overcomplicate vår kode. Men få setter kostnaden for kompleksitet noe klarere enn den nederlandske datavitenskapspioneren Edsger Dijkstra.

her er innsikten: du velger ikke enkelhet som en gave til fremtiden. Du gjør det ikke fordi du forventer muligheten til å gjenbruke koden din, eller fordi du vil at den skal se renere ut ved en kodegjennomgang, eller fordi du vil gjøre det enklere å endre. (Selv om alle disse fordelene er verdifulle!) Du gjør det fordi enkelhet er en forutsetning. Uten enkelhet kan du aldri ha pålitelig kode som du kan stole på for å drive en bedrift eller håndtere dataene dine.

for å akseptere Dijkstras poeng må vi omdefinere hva “god kode” betyr. Det er ikke den korteste koden. Det er ikke nødvendigvis den raskeste koden. Det er definitivt ikke den smarteste koden. Det er kode som kan stole på.

Bonus relatert sitat:

En av beste måtene å holde koden enkel er å huske at mindre er mer. Dijkstra tilbyr en beregning for å hjelpe oss med å huske det:

“hvis vi ønsker å telle linjer med kode, bør vi ikke betrakte dem som ‘linjer produsert’, men som ‘ linjer brukt.'”- Edsger Dijkstra

Om Lesbarhet og Omskrivninger

“det er vanskeligere å lese kode enn å skrive den.”- Joel Spolsky

ved første øyekast, dette sitatet av software legend Og StackOverflow co-skaperen Joel Spolsky virker sant, men utrolig grunt. Ja, koden kan være tett, avvisende og kjedelig lang. Og det er ikke bare andres kode. Hvis du ser på ditt eget arbeid fra et år siden, vil du sannsynligvis trenge litt tid til å sortere gjennom logikken du en gang kjente intimt.

Men Spolskys innsikt kommer med en vri. Faren for kode du ikke kan lese er ikke bare det åpenbare (det er vanskelig å endre det og forbedre det). I stedet er jo større fare at kompleks kode ser ut til å være verre enn den egentlig er. Faktisk er byrden av å prøve å forstå andres allerede skrevet kode så stor at Du kan bli fristet til å gjøre Det Spolsky kaller den verste mulige feilen—å bestemme seg for å omskrive den koden fra bunnen av.

det er ikke at omskrivninger ikke kan forbedre arkitekturen til et system. De kan definitivt. Men disse forbedringene kommer på store kostnader. De nullstiller klokken på testing og bug-fixing, to aktiviteter som tar langt lengre tid enn bare koding. Omskrivninger er fristende fordi de spiller på en av de vanligste skjevhetene i programvareutvikling: vi undergraver innsatsen for å gjøre ting som er konseptuelt enkle. Det er derfor den endelige 5% av et prosjekt tar 50% av tiden. Enkle ting kan være overraskende tidkrevende! Og ingenting virker enklere enn å løse et problem du allerede har løst.

så hvis du ikke bør omskrive alt for å gjøre det perfekt, hva er den bedre løsningen? Svaret er å få hver utvikler involvert i konstant bite-sized refactoring. Dette gir deg liten, kontinuerlig kodeforbedring-ekte belønninger med minimal risiko. Du kan forbedre lesbarheten på veien.

bonusrelatert sitat:

Hvis Du fortsatt er i tvil om viktigheten av lesbarhet, Hjelper Martin Fowler å sette det i perspektiv:

“enhver idiot kan skrive kode som en datamaskin kan forstå. Gode programmerere skriver kode som mennesker kan forstå.”- Martin Fowler

med andre ord, en programmers jobb er ikke bare å få ting til å fungere, men å få ting til å gi mening.

På Repetisjon

“ikke gjenta deg selv. Hvert stykke kunnskap må ha en enkelt, entydig, autoritativ representasjon i et system.”- Andy Hunt Og Dave Thomas

Hver selvrespekt programmerer vet at repetisjon er hjertet av mye ondt. Hvis du skriver det samme på forskjellige steder, gjør du ekstra arbeidsskriving, testing og feilsøking. Enda verre, du introduserer muligheten for inkonsekvenser-for eksempel hvis en del av koden er oppdatert, men andre, lignende rutiner ikke blir enige. Et inkonsekvent program er et program du ikke kan stole på, og et program du ikke kan stole på, er ikke lenger en levedyktig løsning.

koden er imidlertid ikke det eneste stedet hvor repetisjon skaper kaos. Denne versjonen av DEN berømte “don’ t repeat yourself” (DRY) – regelen utvider ikke-dupliseringsprinsippet for å dekke de andre stedene hvor inkonsekvenser kan gjemme seg. Vi snakker ikke lenger om kodeduplisering. Vi snakker også om repetisjon i et system — og et system har mange forskjellige måter å kode kunnskap på. De inkluderer:

• Kodesetninger
• Kodekommentarer
• Utvikler-eller klientdokumentasjon
• dataskjemaer (for eksempel databasetabeller)
• Andre spesifikasjoner, som testplaner, arbeidsflytdokumenter og bygningsregler

alle disse nivåene kan overlappe hverandre. Og når de gjør det, risikerer de å introdusere forskjellige versjoner av samme virkelighet. For eksempel, hva skjer hvis dokumentasjonen beskriver en måte å jobbe på, men søknaden følger en annen? Hvem eier sannheten? Hva skjer hvis databasetabellene ikke samsvarer med datamodellen i koden? Eller kommentarene beskriver driften av en algoritme som ikke samsvarer med den faktiske implementeringen? Hvert system trenger en enkelt, autoritativ representasjon som alt annet kommer fra.

for Øvrig er konkurrerende versjoner av sannheten Ikke bare et problem i småskala prosjekter eller dårlig utformet kode. Et av de beste eksemplene brøt ut i offentligheten med kampen MELLOM XHTML og HTML5. En leir hevdet at spesifikasjonen var den offisielle sannheten, og nettlesere måtte korrigeres for å følge den. Den andre fraksjonen hevdet at nettleseradferd var de facto-standarden, fordi det var det designere hadde i tankene da de skrev nettsider. Til slutt vant nettleserversjonen av sannheten. FRA det tidspunktet VAR HTML5 hva nettlesere gjorde-inkludert snarveiene de tillot og feilene de aksepterte.

Bonus relatert sitat:

muligheten for at kode og kommentarer motsier hverandre har åpnet en opphetet debatt om kommentarer gjør mer skade enn gagn. Talsmenn For Ekstrem Programmering behandle dem med åpen mistanke:

“Kode lyver aldri; kommentarer noen ganger gjør.”- Ron Jeffries

På Harde Problemer

“det er bare to vanskelige ting i datavitenskap: cache invalidation og navngi ting.”- Phil Karlton

ved første øyekast virker dette sitatet som en morsom, men vanlig programmeringsspøk. Kontrasten mellom en noe som høres vanskelig (cache invalidation) og noe som høres smertefritt (navngi ting) er umiddelbart relatable. Hver programmerer har investert timer med arbeid å fikse et latterlig trivielt problem, som et par parametere passert i feil rekkefølge eller en inkonsekvent kapitalisert variabel (Takk JavaScript). Så lenge mennesker trenger å samarbeide med maskiner for å få ting gjort, vil programmering være en mashup av høyt nivå systemplanlegging og trivielle skrivefeil.

Men hvis Du tar en ny titt På Phil Karltons sitat, er det mer å pakke ut. Å navngi ting er ikke vanskelig bare fordi en programmers liv regelmessig blir ødelagt av små hodepine. Det er også fordi spørsmålet om navngivning faktisk er kanten av hver programmers viktigste jobb: programvaredesign. Med andre ord, hvordan skriver du kode som er klar, ren og konsekvent?

det er mange måter å få navn på feil. Vi har alle sett variabler oppkalt etter datatyper (myString, obj), forkortelser (pc for produktkatalog), noen trivielle implementeringsdetaljer (swappable_name, formUserInput), eller ingenting i det hele tatt (ret_value, tempArray). Det er lett å falle i fellen med å navngi en variabel basert på hva du gjør med det i det øyeblikket i stedet for hva det inneholder. Og boolske verdier er spesielt vanskelige-angir progress når fremdriften starter, at du må vise fremdriftsinformasjon i BRUKERGRENSESNITTET, eller flagge noe helt annet?

men variable navn er bare begynnelsen. Naming klasser reiser spørsmålet om hvordan du deler kode i uavhengige deler. Navngi offentlige medlemmer former hvordan du presenterer grensesnittet som gjør at en del av programmet til å samhandle med en annen. Å låse ned disse navnene beskriver ikke bare hva et stykke kode kan gjøre, det bestemmer hva det vil gjøre.

Bonus relatert sitat:

“det er to vanskelige ting i datavitenskap: cache invalidation, navngi ting og off-by-one feil.”- Leon Bambrick