5 Beroemde Programmeercitaten, uitgelegd

als programmeur schrijf je je in voor een leven van constant leren. De fontein van Nieuw-nieuwe functies, nieuwe talen, nieuwe tools, nieuwe frameworks-stopt nooit met gutsen. Maar informatica is ook een verrassend traditioneel vakgebied dat gebaseerd is op beproefde principes. We hebben objectgeoriënteerd programmeren, moderne hardware en kunstmatige intelligentie toegevoegd. Maar ondanks deze veranderingen zijn veel van de inzichten die een generatie geleden voor het eerst werden verwoord, vandaag de dag nog steeds geldig.

in dit artikel heb ik een paar van mijn favoriete citaten over Informatica ontleed. De enige voorwaarde die ik stel is dat elk citaat minstens twintig jaar oud moet zijn. Want terwijl oude technologie snel nutteloos wordt, hebben de oude geboden van onze programmeer voorouders veel meer uithoudingsvermogen.

“alle problemen in de informatica kunnen worden opgelost door een ander niveau van indirecte.”- David Wheeler

hier is een vaak herhaald compsci citaat dat weinig ontwikkelaars willen uitleggen. Maar het is een van mijn favoriete programmeerwaarheden, omdat het de kern raakt van wat programmeren is.

de makkelijkste manier om na te denken over indirectie is door lagen voor te stellen. Stel bijvoorbeeld dat je een klein project hebt dat component A in component B moet passen:

beide componenten zijn gestandaardiseerd, dus je kunt ze niet open breken en de manier waarop ze werken veranderen. Je zou een geheel nieuw component kunnen bouwen (PlugTwoProngVariant) maar dat is veel werk en onnodige duplicatie. Een betere aanpak is het toevoegen van een laag tussen de twee stukken — een adapter die past in beide componenten en vertaalt tussen hen.

als de indirectie alleen maar een nieuwe laag zou toevoegen om incompatibele stukken aan elkaar te laten passen, zou het mooi zijn, maar eng bruikbaar. Maar het idee om problemen op te lossen door er omheen te bouwen is een concept dat zich uitstrekt van de onderkant tot de bovenkant van de computer. Je ziet het als je probeert een nieuw datamodel aan te passen aan een oude gebruikersinterface. Je ziet het als je probeert om een oudere toepassing te passen aan een nieuwe webservice backend. Je ziet het als je functies op hoger niveau zoals logging en caching moet gebruiken, of diensten op hoger niveau zoals messaging en transacties moet coördineren. En aan de top van de piramide krijg je zeldzame onderwerpen zoals machine learning (als je het gedrag dat je nodig hebt niet kunt coderen, schrijf dan een andere laag code die het voor je zal uitzoeken).

veel mensen zullen je vertellen dat programmeren gaat over het schrijven van expliciete instructies in een taal die zelfs idiote computers kunnen begrijpen. Maar David Wheeler ‘ s citaat onthult een beter inzicht. Goed programmeren gaat over het beklimmen van de ladder van abstractie om tot de meest algemene oplossingen te komen.

bonus gerelateerd citaat:

indirectie is krachtig, maar er zijn kosten verbonden aan complexiteit. Mensen citeren zeer zelden Wheeler ‘ s onmiddellijke follow-on opmerking over indirection:

“maar dat zal meestal een ander probleem veroorzaken.”- David Wheeler

That truth has keep programmers in business ever sedertdien.

over eenvoud

“eenvoud is een voorwaarde voor betrouwbaarheid.”- Edsger Dijkstra

er is geen tekort aan wijze programmeurs die ons waarschuwen onze code niet te ingewikkeld te maken. Maar weinigen stellen de kosten van complexiteit duidelijker dan de Nederlandse computerwetenschapper Edsger Dijkstra.

hier is het inzicht: je kiest eenvoud niet als een geschenk voor de toekomst. Je doet het niet omdat je anticipeert op de kans om je code te hergebruiken, of omdat je wilt dat het er schoner uitziet bij een code review, of omdat je het makkelijker wilt maken om te wijzigen. (Hoewel al deze voordelen zijn waardevol!) Je doet het omdat eenvoud een voorwaarde is. Zonder eenvoud, kunt u nooit betrouwbare code die u kunt vertrouwen om een bedrijf te runnen of omgaan met uw gegevens.

om Dijkstra ‘ s punt te accepteren, moeten we herdefiniëren wat “goede code” betekent. Het is niet de kortste code. Het is niet per se de snelste code. Het is zeker niet de slimste code. Het is code die te vertrouwen is.

bonus gerelateerd citaat:

een van de beste manieren om code eenvoudig te houden is te onthouden dat minder meer is. Dijkstra biedt een metric om ons daarbij te helpen:

“als we regels code willen tellen, moeten we ze niet beschouwen als “geproduceerde regels”, maar als “uitgegeven regels”.”- Edsger Dijkstra

over leesbaarheid en herschrijven

“het is moeilijker om code te lezen dan om het te schrijven.”- Joel Spolsky

op het eerste gezicht lijkt dit citaat van software legend en StackOverflow co-creator Joel Spolsky waar, maar bedrieglijk oppervlakkig. Ja, code kan dicht, kort en saai lang zijn. En het is niet alleen andermans code. Als je naar je eigen werk van een jaar geleden kijkt, zul je waarschijnlijk wat tijd nodig hebben om de logica die je ooit intiem kende te doorgronden.

maar Spolsky ‘ s inzicht komt met een twist. Het gevaar van code die je niet kunt lezen is niet alleen het voor de hand liggende (het is moeilijk om het te veranderen en te verbeteren). In plaats daarvan, het grotere gevaar is dat complexe code lijkt erger dan het eigenlijk is. In feite is de last van het proberen te begrijpen van iemand anders al geschreven code is zo groot dat je zou kunnen worden verleid om wat Spolsky noemt de slechtst mogelijke fout te maken—beslissen om die code te herschrijven vanaf nul.

het is niet zo dat herschrijven de architectuur van een systeem niet kan verbeteren. Dat kunnen ze zeker. Maar deze verbeteringen komen met grote kosten. Ze resetten de klok op testen en bug-fixing, twee activiteiten die veel langer duren dan alleen coderen. Rewrites zijn verleidelijk omdat ze spelen op een van de meest voorkomende vooroordelen in software-ontwikkeling: we onderschatten de inspanning om dingen te doen die conceptueel eenvoudig zijn. Daarom duurt de laatste 5% van een project 50% van de tijd. Eenvoudige dingen kunnen verrassend tijdrovend zijn! En niets lijkt makkelijker dan het oplossen van een probleem dat je al hebt opgelost.

dus als je niet alles moet herschrijven om het perfect te maken, wat is de betere oplossing? Het antwoord is om elke ontwikkelaar betrokken te krijgen bij constante hapklare refactoring. Dit geeft u een kleine, continue verbetering van de code-echte beloningen met minimale risico ‘ s. Je kunt onderweg de leesbaarheid verbeteren.

bonus gerelateerd citaat:

als je nog steeds twijfelt over het belang van leesbaarheid, helpt Martin Fowler om het in perspectief te plaatsen:

“elke dwaas kan code schrijven die een computer kan begrijpen. Goede programmeurs schrijven code die mensen kunnen begrijpen.”- Martin Fowler

met andere woorden, de taak van een programmeur is niet alleen om dingen te laten werken, maar om dingen zinvol te maken.

bij herhaling

“herhaal jezelf niet. Elk stukje kennis moet één enkele, ondubbelzinnige, gezaghebbende voorstelling hebben binnen een systeem.”- Andy Hunt en Dave Thomas

elke zichzelf respecterende programmeur weet dat herhaling het hart is van veel kwaad. Als je hetzelfde op verschillende plaatsen schrijft, maak je extra werk met schrijven, testen en debuggen. Erger nog, je introduceert de mogelijkheid voor inconsistenties-bijvoorbeeld, als een deel van de code wordt bijgewerkt, maar andere, soortgelijke routines worden niet in overeenstemming gebracht. Een inconsistent programma is een programma dat je niet kunt vertrouwen, en een programma dat je niet kunt vertrouwen is niet langer een haalbare oplossing.

kunnen voorkomen, maar code is niet de enige plaats waar herhaling schade aanricht. Deze versie van de beroemde” Don ‘t repeat yourself” (DRY) regel breidt het No-duplicatie principe uit naar de andere plaatsen waar inconsistenties kunnen verbergen. We hebben het niet langer over code duplicatie. We hebben het ook over herhaling in een systeem — en een systeem heeft veel verschillende manieren om kennis te coderen. Zij omvatten:

• Codecommentaren
• Codecommentaren
• documentatie voor ontwikkelaars of klanten
• gegevensschema ‘ s (bijvoorbeeld databasetabellen)
• andere specificaties, zoals testplannen, workflowdocumenten en bouwregels

al deze lagen kunnen elkaar overlappen. En als ze dat doen, riskeren ze verschillende versies van dezelfde realiteit te introduceren. Bijvoorbeeld, wat gebeurt er als de documentatie beschrijft een manier van werken, maar de toepassing volgt een andere? Wie bezit de waarheid? Wat gebeurt er als de databasetabellen niet overeenkomen met het gegevensmodel in de code? Of de commentaren beschrijven de werking van een algoritme dat niet overeenkomt met de werkelijke implementatie? Elk systeem heeft een enkele, gezaghebbende vertegenwoordiging nodig waaruit al het andere voortkomt.

Overigens is concurrerende versies van de waarheid niet alleen een probleem in kleinschalige projecten of slecht ontworpen code. Een van de beste voorbeelden barstte in het publiek met de strijd tussen XHTML en HTML5. Een kamp voerde aan dat de specificatie de officiële waarheid was, en browsers moesten worden gecorrigeerd om het te volgen. De andere factie beweerde dat browsergedrag de de facto standaard was, want dat is wat ontwerpers in gedachten hadden toen ze webpagina ‘ s schreven. Uiteindelijk won de browserversie van de waarheid. Vanaf dat moment, HTML5 was wat browsers deden — met inbegrip van de snelkoppelingen die ze toegestaan en de fouten die ze geaccepteerd.

Bonus gerelateerd citaat:

de mogelijkheid dat code en commentaren elkaar tegenspreken heeft een verhitte discussie op gang gebracht over de vraag of commentaren meer kwaad dan goed doen. De voorstanders van Extreme programmering behandelen hen met open argwaan:

“Code liegt nooit; commentaren soms wel.”- Ron Jeffries

over moeilijke problemen

“er zijn maar twee moeilijke dingen in de informatica: cache ongeldigmaking en het benoemen van dingen.”- Phil Karlton

op het eerste gezicht lijkt dit citaat een amusante maar gewone programmeergrap. Het contrast tussen iets dat moeilijk klinkt (cache invalidatie) en iets dat pijnloos klinkt (dingen noemen) is direct relateerbaar. Elke programmeur heeft uren werk geïnvesteerd om een belachelijk triviaal probleem op te lossen, zoals een paar parameters die in de verkeerde volgorde zijn doorgegeven of een inconsistente variabele met hoofdletters (met dank aan JavaScript). Zolang mensen moeten samenwerken met machines om dingen gedaan te krijgen, zal programmeren een mashup zijn van systeemplanning op hoog niveau en triviale typefouten.

maar als je een tweede blik op Phil Karlton ‘ s citaat neemt, is er meer uit te pakken. Dingen benoemen is niet moeilijk alleen maar omdat het leven van een programmeur regelmatig wordt geruïneerd door kleine hoofdpijn. Het is ook omdat de kwestie van de naamgeving is eigenlijk de rand van de belangrijkste taak van elke programmeur: software ontwerp. Met andere woorden, Hoe schrijf je code die duidelijk, schoon en consistent is?

er zijn tal van manieren om Namen verkeerd te krijgen. We hebben allemaal variabelen gezien die vernoemd zijn naar gegevenstypen (myString, obj), afkortingen (pc voor productcatalogus) , enkele triviale implementatiedetails (swappable_name, formUserInput), of zelfs helemaal niets.(ret_value, tempArray). Het is gemakkelijk om te vallen in de val van het benoemen van een variabele op basis van wat je doet met het op dat moment in plaats van wat het bevat. En Booleaanse waarden zijn bijzonder lastig — geeft progress aan wanneer de voortgang begint, aan dat u voortgangsinformatie moet weergeven in de gebruikersinterface, of markeert u iets heel anders?

maar variabele namen zijn slechts het begin. Het benoemen van klassen roept de vraag op hoe je code in onafhankelijke delen verdeelt. Het benoemen van publieke leden vormt hoe u de interface die het mogelijk maakt een deel van uw toepassing om te communiceren met een ander presenteren. Het vergrendelen van deze namen beschrijft niet alleen wat een stukje code kan doen, het bepaalt wat het zal doen.

Bonus gerelateerd citaat:

“er zijn twee harde dingen in de informatica: cache ongeldigmaking, naamgeving dingen, en off-by-one fouten.”- Leon Bambrick