De raarste programmeerprincipes waar je nog nooit van gehoord hebt

We hebben u al door de meest essentiële programmeerprincipes heen geleid 10 Basisprincipes voor programmeren Elke programmeur moet 10 basisprincipes voor programmeren volgen Elke programmeur moet volgen Schrijf altijd code die kan worden onderhouden door iedereen die mogelijk aan uw software werkt. Daartoe zijn hier verschillende programmeerprincipes om je act op te ruimen. Lees Meer waarover je moet weten, maar er is nog een andere klasse van programmeerprincipes die kunnen bewijzen nog gunstiger dan deze.

Terwijl de bovengenoemde principes je leren hoe te zijn slim met jouw code, zullen de volgende principes je leren te zijn wijs met je code. Sommigen van hen zijn vreemd, en veel van hen zijn humoristisch, maar ze zijn allemaal even praktisch en belangrijk. Pas op!

1. Het Bloat-principe

Deze heeft zoveel variaties dat het moeilijk is om er een te kiezen als de belangrijkste. Misschien wel het meest “officieel” versie is de Law of Software Envelopment, meer algemeen genoemd Wet van Zawinski, genoemd naar Jamie Zawinski en genoemd in De kunst van UNIX-programmering:

“Elk programma probeert uit te breiden tot het e-mail kan lezen. Die programma's die niet zo uitgebreid kunnen worden, worden vervangen door programma's die dat wel kunnen.”

Het heeft het over de neiging van programma's om steeds meer functies aan te trekken in de loop van de tijd en onvermijdelijk af te dwalen naar toenemende complexiteit. Je kent dit misschien wel feature creep, wat de voortdurende toevoeging is van nieuwe functies die niets te maken hebben met het hoofddoel van het programma. Feature creep leidt tot bloat en bloat is vaak ongewenst.

Dit kan ook van toepassing zijn op softwareprestaties:

“Software breidt uit om alle beschikbare bronnen te gebruiken.”

In de jaren 90 waren harde schijven en CPU's en RAM veel restrictiever dan tegenwoordig, en programmeurs hebben er hard aan gewerkt om binnen de limieten zoveel mogelijk te passen. Maar nu we grotere schijven en snellere CPU's en meer RAM hebben, hebben we nog steeds moeite om de limieten te respecteren. Alles wordt na verloop van tijd opgeblazen. Het is jouw taak om dat onder controle te houden.

2. Het “Erger is beter” Mentaliteit

Bijna alsof we in reactie op het Bloat-principe de Erger is een betere mentaliteit, voor het eerst bedacht door Richard P. Gabriel in een essay dat hij schreef over softwarekwaliteit:

“Software die beperkt is, maar eenvoudig te gebruiken, kan aantrekkelijker zijn voor de gebruiker en de markt dan het omgekeerde.”

Met andere woorden, het is verstandig om het te achterhalen een probleem uw software is bedoeld om op te lossen en vervolgens te zijn heel goed bij dat ene ding. Hou het simpel. Hoe meer je jezelf verspreidt, des te onhandelbaarder het project zal worden en des te ongewenster het wordt voor gebruikers.

Wat gebeurt er als je dit negeert? Je eindigt met de Software Peter Principle:

“Een al te complex project zal uiteindelijk te ingewikkeld worden om zelfs door zijn eigen ontwikkelaars begrepen te worden.”

Het komt van het bredere Peter Principle, dat stelt dat wanneer werknemers worden gepromoveerd op basis van hun huidige competentie en niet op basis van hun verwachte competentie op hun volgende positie, alle medewerkers uiteindelijk in een incompetentiepositie belanden. Neem dat principe en pas het toe op software, en je zult zien waarom slechter software vaak beter kan.

3. Wet van Eagleson

“Elke code van jezelf waar je zes maanden of langer niet naar hebt gekeken, had net zo goed door iemand anders kunnen zijn geschreven.”

Dit schijnbaar demotiverende gezegde is eigenlijk iets om te omhelzen. Het is een feit dat niemand perfect is. Je zou kunnen denken dat je nu een geniale programmeur bent, maar er is altijd iets meer dat je kunt leren, altijd meer ruimte om te groeien. Als je ooit terugkijkt op oude code en ineenkrimpt, betekent dit waarschijnlijk je hebt sindsdien iets nieuws geleerd.

Anders gezegd: als je terugkijkt op een oud project en je kunt niets zien dat je kunt verbeteren of anders zou doen de volgende keer, sta je waarschijnlijk stil als een programmeur.

4. Principe van de minste verbazing

“Als een noodzakelijke functie een hoge verrassingsfactor heeft, kan het nodig zijn om de functie opnieuw te ontwerpen.”

Voor het eerst gepubliceerd in de IBM Systems Journal al in 1984 is dit principe nog steeds verrassend relevant vandaag - misschien meer dan ooit tevoren.

Het raakt in essentie de delicate balans tussen innovatie en bekendheid: als een stukje software dat is te anders van anderen in zijn soort en voldoet dan niet aan de verwachtingen van de gebruiker ze zullen het waarschijnlijk niet adopteren. Het is beter om te streven naar incrementele verbeteringen die net groot genoeg zijn om indrukwekkend te zijn, maar klein genoeg om bekend te blijven.

5. Wet van Cybernetische entomologie

“Er is altijd nog een bug.”

Vaak genoemd Lubarsky's wet van cybernetische entomologie, het is onduidelijk wie deze Lubarsky eigenlijk is. Zijn principe geldt echter voor alle programmeurs: hoe schoon je je code ook schrijft, hoe robuust je ook je modules test, hoe vaak je ook je lessen refactor, er zal altijd een andere bug zijn.

In zekere zin is dit een bevrijdend principe. Hoewel we zeker moeten doen zich inspannen voor foutloze code is het ook belangrijk om te onthouden dat perfectionisme de vijand van het goede is. Zoek naar fouten, verhelp ze wanneer ze zich voordoen en ga dan verder.

6. Wet van Kernighan

“Het debuggen is twee keer zo moeilijk als het schrijven van de code in de eerste plaats. Daarom, als je de code zo slim mogelijk schrijft, ben je per definitie niet slim genoeg om het te debuggen.”

Brian Kernighan, dezelfde persoon die co-auteur is van de C programmeertaal bijbel Waarom C programmeren nog steeds de moeite waard is Waarom C programmeren nog steeds de moeite waard is C is geen dode taal. IEEE Spectrum magazine rangschikte het zelfs als de nr. 2 toptaal in 2017. Hier zijn vijf redenen waarom. Read More, is beroemd om zijn inzichtelijke wet. De crux ervan is dit: schrijven goed code, schrijf leesbaar code, schrijf eenvoudig code, alles zolang het dat niet is knap code.

Proberen om je programmeerspieren te buigen met ivoren torencomplexiteit is precies het tegenovergestelde van wat het betekent om schoon en beter te schrijven. 10 Tips voor het schrijven van schonere en betere code 10 Tips voor het schrijven van schonere en betere code Schrijven schone code ziet er eenvoudiger uit dan het in werkelijkheid is maar de voordelen zijn het waard. Hier leest u hoe u vandaag schonere code kunt gaan schrijven. Lees verder . Hoe moeilijker je code is om te begrijpen, hoe moeilijker het zal zijn om te debuggen wanneer het onvermijdelijk breekt.

En zoals Robert C. Martin uitlegt, gaat het niet alleen om het debuggen:

“Inderdaad, de ratio van tijd besteed aan lezen versus schrijven is meer dan 10 tegen 1. We zijn voortdurend bezig met het lezen van oude code als onderdeel van de poging om nieuwe code te schrijven ... [Daarom] maakt het gemakkelijk om te lezen, maakt het makkelijker om te schrijven.”

7. Het debuggen van rubberen eendjes

Deze is niet zozeer een principe als wel een techniek, maar het is zo behulpzaam en vreemd dat we het nalaten om het weg te laten.

Eerst verteld in De Pragmatische programmeur, foutopsporing met een rubberen eend is wanneer u foutopsporingsoftware fout opspoort door uw code één voor één uit te leggen aan een levenloos object (bijvoorbeeld een rubberen eend). Het werkt omdat de handeling van uitleg verschillende delen van je hersenen triggert, en je meer geneigd bent om inconsistenties te ontdekken en erachter te komen waar je fout bent gegaan.

Om deze reden kan een rubberen eend een verrassend handig geschenk zijn voor programmeurs. De beste geekcadeaus voor programmeurs: 20 ideeën voor codeerders en nerds De beste geekcadeaus voor programmeurs: 20 ideeën voor codeerders en nerds Op zoek naar een geschenk voor een programmeur? Hier zijn de beste geekcadeaus, gaande van mechanische toetsenborden tot staande bureaus en meer. Lees Meer, of je het nu voor jezelf koopt of voor een programmeermaatje van jou.

8. De negentig-negentig regel

“De eerste 90 procent van de code is goed voor de eerste 90 procent van de ontwikkelingstijd. De resterende 10 procent van de code is goed voor de overige 90 procent van de ontwikkelingstijd.”

Dit brutale, kleine spreekwoord van Tom Cargill vormt de kern van waarom programmeren zo frustrerend kan zijn: hoe dicht je denkt dat je ook bent als je klaar bent, je bent veel verder weg dan zelfs je beste schattingen. Als je denkt dat je klaar bent, ben je pas halverwege.

Het gaat hand in hand met de wet van Hofstadter:

“Het duurt altijd langer dan je verwacht, zelfs als je rekening houdt met de wet van Hofstadter.”

9. De wet van Parkinson

“Werk breidt zich uit om de beschikbare tijd voor voltooiing te vullen.”

Dit ene principe, bedacht door Cyril Northcote Parkinson, is een breder principe dat absoluut van toepassing is op programmeren en gaat hand in hand met de Ninety-Ninety-regel hierboven: hoeveel tijd je ook hebt om een ​​project af te maken, is precies hoe lang het gaat duren. In software ontwikkeling, “vroeg klaar” is zo ongeveer een mythe.

De wet van Parkinson is de reden waarom juiste deadlines cruciaal zijn als u uw software wilt voltooien en verzenden. Dat is de reden waarom moderne professionele programmeurs vaak agile projectmanagementprincipes aanbevelen. Agile Project Management-principes gebruiken om je leven te organiseren Hoe Agile Project Management-principes te gebruiken om je leven te organiseren Agile, het best bekend als een projectmanagementmethode, is een geweldig raamwerk voor het beheren van je priveleven. We laten u zien welke principes u kunt lenen - gratis download van het werkblad inbegrepen! Meer lezen en tools voor projectbeheer zoals Asana Trello versus Asana: de beste gratis tool voor projectmanagement is ... Trello versus Asana: de beste gratis tool voor projectmanagement is ... Het kiezen tussen Trello en Asana is moeilijk. Hier vergelijken we de gratis plannen en helpen u beslissen welke projectbeheertool het beste is voor uw team. Lees verder .

10. Wet van Brook

“Het toevoegen van mankracht aan een laat softwareproject maakt het later.”

De volgende keer dat je te laat bent met een project, wat waarschijnlijk is omdat de meeste programmeerprojecten meer tijd nodig hebben dan is toegewezen, onthoud dat het toevoegen van codeers het niet sneller zal oplossen.

In feite zal het waarschijnlijk duren langer vervolledigen. Niet alleen moet u de nieuwe coder (s) op de hoogte brengen, ze zullen waarschijnlijk ook botsen met de bestaande coders. Meer dingen zullen moeten worden gedocumenteerd, meer bureaucratie zal nodig zijn om iedereen op dezelfde pagina te houden, en er zal meer wrijving komen uit de hele crunch-time ervaring.

Vooruitgaan als programmeur

Nu dat je deze principes kent, ben je eigenlijk beter geschikt voor de echte wereld van programmeren, niet alleen wat je op school hebt gezien, in een webcursus of in een bootcamp. Deze principes komen van jaren en jaren van ervaring en mislukkingen.

Met deze hernieuwde wijsheid kun je nu beginnen aan een veelgevraagde carrière in de programmering 10 Computerprogrammering banen die nu aan vraag zijn 10 Computerprogramma's programmeren die momenteel veel vraag zijn Sinds de landing kan een programmeeropdracht zwaar zijn in het huidige landschap, overweeg om je te concentreren op een van de volgende concentraties om je kansen op succes te vergroten. Meer lezen met meer realistische verwachtingen. Leer daarvoor hoe je je carrièremogelijkheden op het gebied van programmeren kunt maximaliseren. Hoe je je programmeerervaring kunt verbeteren Carrièremogelijkheden Hoe je je programmeermogelijkheden kunt verbeteren Carrièremogelijkheden Als je hoopt te starten, opnieuw te starten of op een andere manier je programmeercarrière te verbeteren, is het niet gemakkelijk. Als je op de universiteit zit, is de tijd nu rijp. Hier zijn enkele tips die u ver kunnen brengen. Lees verder . En als u besluit dat programmeren niet voor u is, wees dan niet bang - overweeg een van deze niet-coderende technische taken in plaats daarvan Coding Is not For Everyone: 7 Tech Jobs die u zonder kunt krijgen Coderen is niet voor iedereen: 7 Technische banen die je zonder kunt krijgen Laat je niet ontmoedigen als je deel wilt uitmaken van het technische veld - er zijn genoeg banen voor mensen die niet weten hoe ze moeten coderen! Lees verder .

Welke van deze principes klinken het meest voor jou? Kent u nog andere rare programmeerprincipes die we hebben gemist? Laat het ons weten in de reacties hieronder!