De vreemdste programmeerprincipes waar u nog nooit van gehoord heeft

Advertentie

We hebben je al door de meest essentiële programmeerprincipes 10 basis programmeerprincipes die elke programmeur moet volgenSchrijf altijd code die kan worden onderhouden door iedereen die mogelijk aan uw software gaat werken. Hiertoe zijn hier verschillende programmeerprincipes om u te helpen uw act op te schonen. Lees verder waarover u moet weten, maar er is nog een andere klasse programmeerprincipes die dit kan bewijzen nog voordeliger dan deze.

Terwijl de bovengenoemde principes je leren hoe je moet zijn slim met je code leren de volgende principes je te zijn wijs met uw code. Sommigen van hen zijn vreemd en veel van hen zijn grappig, 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 de meest "officiële" versie is de wet van softwarematige omhulling, beter bekend als Zawinski's wet, genoemd naar Jamie Zawinski en genoemd in De kunst van UNIX-programmering:

“Elk programma probeert uit te breiden totdat het mail kan lezen. De programma's die niet zo kunnen uitbreiden, worden vervangen door de programma's die dat wel kunnen. '

Het heeft het over de neiging van programma's om in de loop van de tijd steeds meer functies aan te trekken en onvermijdelijk af te zwakken naar toenemende complexiteit. U kent dit misschien als voorzien van kruip, dat is de voortdurende toevoeging van nieuwe functies die niets te maken hebben met het hoofddoel van het programma. Feature creep leidt tot een opgeblazen gevoel en een 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 nu en programmeurs hebben hard gewerkt om binnen de limieten te passen. Maar nu we grotere schijven en snellere CPU's en meer RAM hebben, worstelen we nog steeds met het respecteren van limieten. Alles wordt na verloop van tijd opgeblazen. Het is jouw taak om dat onder controle te houden.

2. De 'slechter is beter'-mentaliteit

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

"Software die beperkt is, maar eenvoudig te gebruiken, is wellicht aantrekkelijker voor de gebruiker en de markt dan andersom."

Met andere woorden, het is verstandig om de een probleem uw software wil oplossen en dan zijn heel goed op dat ene ding. Hou het simpel. Hoe meer je jezelf dun verspreidt, hoe onhandelbaarder het project wordt en hoe onwenselijker het wordt voor gebruikers.

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

"Een te complex project zal uiteindelijk te complex worden om zelfs door de eigen ontwikkelaars te worden begrepen."

Het komt van het bredere Peter Principle, dat stelt dat wanneer werknemers worden gepromoot op basis van hun huidige competentie en niet hun verwachte competentie bij hun volgende functie, komen alle medewerkers uiteindelijk terecht in een functie van incompetentie. Neem dat principe en pas het toe op software, en je zult zien waarom slechtere software vaak beter kan.

3. De wet van Eagleson

"Elke eigen code die je zes of meer maanden niet hebt bekeken, kan net zo goed door iemand anders zijn geschreven."

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

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

4. Principe van de minste verbazing

"Als een noodzakelijke functie een hoge verbazingfactor heeft, kan het nodig zijn de functie opnieuw te ontwerpen."

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

Het raakt in wezen de delicate balans tussen innovatie en vertrouwdheid: als een stuk software dat is te anders van andere in zijn soort en voldoet dus niet aan de verwachtingen van de gebruiker ze zullen het waarschijnlijk niet adopteren. Het is beter om te streven naar stapsgewijze verbeteringen die net groot genoeg zijn om indrukwekkend te zijn, maar klein genoeg om vertrouwd 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 u uw code ook schrijft, hoe dan ook robuust test je je modules, het maakt niet uit hoe vaak je je lessen refactoreert, er zal altijd een andere bug zijn.

In zekere zin is dit een bevrijdend principe. Terwijl we zeker moeten streven voor foutloze code is het ook belangrijk om te onthouden dat perfectionisme de vijand van het goede is. Zoek naar bugs, herstel ze wanneer ze zich voordoen en ga verder.

6. De wet van Kernighan

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

Brian Kernighan, precies dezelfde die co-auteur was de C programmeertaal bijbel Waarom C-programmeren nog steeds de moeite waard is om te lerenC is geen dode taal. IEEE Spectrum Magazine rangschikte het zelfs als de nummer 2 toptaal in 2017. Hier zijn vijf redenen waarom. Lees verder , staat bekend om deze inzichtelijke wet. De kern hiervan is dit: schrijven goed code, schrijf leesbaar code, schrijf gemakkelijk code, alles zolang het niet is slim code.

Proberen om je programmeerspieren te buigen met ivoren torencomplexiteit is precies het tegenovergestelde van wat het betekent schrijf schone en betere code 10 tips voor het schrijven van schonere en betere codeSchone code schrijven lijkt eenvoudiger dan het in werkelijkheid is, maar de voordelen zijn het waard. Hier leest u hoe u vandaag kunt beginnen met het schrijven van schonere code. Lees verder . Hoe moeilijker uw code is om te begrijpen, hoe moeilijker het zal zijn om te debuggen wanneer deze onvermijdelijk breekt.

En zoals Robert C. Martin legt uit dat het niet alleen om debuggen gaat:

“Inderdaad, de verhouding tussen lezen en schrijven is meer dan 10: 1. We lezen voortdurend oude code als onderdeel van de poging om nieuwe code te schrijven... [Daarom] maakt het makkelijker om te lezen door het gemakkelijker te maken om te lezen. ”

7. Rubber Duck Debugging

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

Voor het eerst verteld De pragmatische programmeur, rubber duck debugging is wanneer u defecte software debugt door uw code regel voor regel uit te leggen aan een levenloos object (bijvoorbeeld een rubberen eend). Het werkt omdat de handeling van uitleg verschillende delen van je brein triggert, en je zult eerder inconsistenties opmerken en erachter komen waar je fout bent gegaan.

Om deze reden kan een badeend een zijn verrassend handig cadeau voor programmeurs De beste Geek-geschenken voor programmeurs: 20 ideeën voor programmeurs en nerdsOp zoek naar een cadeau voor een programmeur? Hier zijn de beste geekcadeaus, variërend van mechanische toetsenborden tot staande bureaus en meer. Lees verder , of je het nu voor jezelf koopt of voor een programmeermaatje van jou.

8. De Ninety-Ninety Rule

“De eerste 90 procent van de code is verantwoordelijk voor de eerste 90 procent van de ontwikkeltijd. De resterende 10 procent van de code is verantwoordelijk voor de overige 90 procent van de ontwikkeltijd. '

Dit brutale, kleine gezegde van Tom Cargill vormt de kern van waarom programmeren zo frustrerend kan zijn: hoe dicht je ook denkt te zijn dat je klaar bent, je bent veel verder weg dan zelfs uw beste schattingen. Als je denkt dat je klaar bent, ben je nog maar 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

"Het 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 Rule hierboven: hoeveel tijd je ook hebt om een ​​project te voltooien, is precies hoe lang het gaat duren nemen. In softwareontwikkeling is "vroegtijdig afronden" eigenlijk een mythe.

De wet van Parkinson is de reden waarom correcte deadlines cruciaal zijn als u uw software wilt afmaken en verzenden. Dat is de reden waarom moderne professionele programmeurs het vaak aanbevelen agile projectmanagementprincipes Hoe u Agile Project Management-principes kunt gebruiken om uw leven te organiserenAgile, vooral bekend als een methode voor projectbeheer, is een geweldig raamwerk voor het beheren van uw persoonlijke leven. We laten u zien welke principes u kunt lenen - gratis werkblad downloaden inbegrepen! Lees verder en projectbeheertools zoals Asana Trello vs. Asana: De beste gratis tool voor projectbeheer is ...Kiezen tussen Trello en Asana is moeilijk. Hier vergelijken we de gratis plannen en helpen u beslissen welke projectmanagementtool het beste is voor uw team. Lees verder .

10. De wet van Brook

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

De volgende keer dat u te laat bent met een project, wat waarschijnlijk is omdat de meeste programmeerprojecten meer tijd nodig hebben dan toegewezen, moet u er rekening mee houden dat het toevoegen van coders dit niet sneller oplost.

Het zal zelfs waarschijnlijk duren langer vervolledigen. U moet niet alleen de nieuwe coder (s) op snelheid brengen, ze zullen waarschijnlijk ook botsen met de bestaande codeerders. Er zullen meer dingen moeten worden gedocumenteerd, er zal meer bureaucratie nodig zijn om iedereen op dezelfde pagina te houden en er zal meer wrijving ontstaan ​​uit de hele crunch-time ervaring.

Vooruit gaan als programmeur

Nu u deze principes kent, bent u eigenlijk beter geschikt voor de echte wereld programmeren, niet alleen wat je bent tegengekomen op school, in een webcursus of in een bootcamp. Deze principes komen voort uit jaren en jaren van ervaring en mislukkingen.

Met deze hernieuwde wijsheid kun je nu naar a veelgevraagde programmeercarrière 10 computerprogrammeertaken die momenteel in trek zijnAangezien het landen van een programmeeropdracht in het huidige landschap moeilijk kan zijn, kunt u overwegen om u te concentreren op een van de volgende concentraties om uw kansen op succes te vergroten. Lees verder met meer realistische verwachtingen. Leer daarvoor hoe maximaliseer uw kansen op programmeercarrière Hoe u uw programmeermogelijkheden kunt verbeterenAls u hoopt uw ​​programmeercarrière te starten, opnieuw te starten of anderszins te verbeteren, is het niet eenvoudig. Als je op de universiteit zit, is het nu tijd. Hier zijn enkele tips die je ver kunnen brengen. Lees verder . En als je besluit dat programmeren niets voor jou is, maak je geen zorgen - overweeg een van deze niet-coderende technische banen Codering is niet voor iedereen: 9 technische banen die u zonder kunt krijgenWees niet ontmoedigd als u deel wilt uitmaken van het technische veld. Er zijn genoeg banen voor mensen zonder codeervaardigheden! 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!