3 geweldige manieren om eenvoudige code te schrijven

Het leven is heel eenvoudig, maar we staan ​​erop het ingewikkeld te maken.

Image Credits: unsplash.com Tom Grimbert

Het schrijven van eenvoudige code is eigenlijk heel eenvoudig. Maar we maken het een ingewikkelde zaak door het 'klaar voor de toekomst' te maken.

En als we eenmaal leren om deze waan van toekomstgereedheid te overwinnen, zou onze code niet alleen eenvoudiger en schoner worden, maar we zouden ook groeien als een geweldige ontwikkelaar.

Laat het me uitleggen.

Terug in mijn hoogtijdagen in het programmeren werd me bij elke gelegenheid dogmatisch geleerd.

"Schrijf nooit twee keer dezelfde code".

"Je moet je code opnieuw bepalen en herbruikbaar maken voor het" grotere goed ". Maak de code vergelijkbaar met een zwarte doos die door elke andere ontwikkelaar onder de zon kan worden gebruikt. Geweldige ontwikkelaars laten de grotere code achter als hun eeuwige erfenis.

Tot zover gaat het goed.

Behalve dat mijn code-creaties geleidelijk evolueerden naar lelijke klontjes monsterlijke nietsheid die bijna onmogelijk te begrijpen en te interpreteren werden. Mijn code hygiëne ging voor een gooi en ik begon dagen en maanden te verspillen met het “corrigeren” en “herrijzen” van de demonen die ik had gecreëerd.

Programmeren is moeilijk. Wanneer je een programma schrijft, kan er overal een tot een miljarden regels code zijn en ga je fouten maken. Soms zijn ze groot, soms zijn ze klein, maar ongeacht de grootte, ze nemen allemaal de tijd om te zoeken en problemen op te lossen. Soms heb je hulp nodig om uit de "gevaarlijke" draaikolk van "hulpeloosheid" te komen die je snel opzuigt.

En soms heb je gewoon ... een rubberen eend nodig.

Het concept van de badeend werd voor het eerst genoemd door Deane Parker in zijn uitstekende post “How to Give a Good Conference Talk”, waar hij het oefenen van een presentatie hardop beschreef om het beter te maken. Het idee van het gebruik van een eend als klankbord is niet nieuw, maar waar het scoort scoort in de eenvoud van gebruik en de effectiviteit.

Het grootste voordeel van het gebruik van een badeend als klankbord is dat het geduldig is, het je niet beoordeelt en vooral, het kost de tijd van iemand anders niet. Het is iets magisch om je problemen hardop uit te leggen, zelfs tot iets levenloos als een badeendje, dat je kan helpen de oplossing voor je problemen te vinden.

Terwijl je je code doorloopt en deze regel voor regel aan de badeend uitlegt, stop je jezelf en begin je aan de situatie van buitenaf te denken. Je dwingt jezelf om jezelf te beoordelen en een objectief begrip te krijgen van alles wat je in de 'hitte' van het moment hebt geschreven.

En dan krijg je vroeg of laat je 'AH-HA'-moment. Het antwoord komt gewoon naar je toe.

En zo voelt het bijna elke keer: "Duh! Ik wist dat!"

Hier zijn enkele dingen die de badeendsessies me hebben geleerd over het schrijven van betere code.

Het schrijven van een herbruikbaar onderdeel is niet ELKE KEER vereist.

Sommigen zullen beweren dat je altijd moet proberen om je componenten zo herbruikbaar mogelijk te maken, omdat het vereist dat je al die kwaliteitsproblemen moet doorstaan, wat er ook gebeurt, en betere software zal produceren. Dit zou geweldig zijn als uw enige doel was om de beste software ter wereld te maken, maar niemand betaalt u om dat te doen.

Nee, u wordt betaald om software van voldoende kwaliteit te schrijven binnen de toegewezen tijd en budget. Als u onnodige tijd besteedt aan het vergulden van uw code, kunt u zich cool voelen, maar het is ronduit verspillend. Je moet een streep in het zand trekken van hoe goed dit product echt moet zijn en je daaraan houden, anders zul je nooit eindigen.

Je zult het niet nodig hebben

YouArentGonnaNeedIt (vaak afgekort als YAGNI) is een praktijk voor extreme programmering waarin staat:

"Implementeer altijd dingen wanneer je ze echt nodig hebt, nooit wanneer je gewoon voorziet dat je ze nodig hebt."

Zelfs als u helemaal, helemaal, helemaal zeker bent dat u later een functie nodig hebt, voer deze dan nu niet uit.

Er zijn twee hoofdredenen om YagNi te oefenen:

  • U bespaart tijd omdat u vermijdt om code te schrijven die niet vereist is
  • Uw code is beter omdat u deze niet vervuilt met 'gissingen' die min of meer verkeerd blijken te zijn, maar toch blijven hangen.

Maak het eenvoudigste ding dat mogelijk zou kunnen werken.

Extreme programmering noemt twee gouden regels om eenvoudige code te schrijven.

· Implementeer eerst een nieuwe mogelijkheid op de meest eenvoudige manier die u kunt bedenken die "mogelijk zou kunnen werken". Bouw niet veel geweldige superstructuren, doe niets bijzonders, zet het er gewoon in om het te laten werken. Laat de code de Eenheidstests doorstaan ​​voor de nieuwe functie (en alle functies, zoals altijd).

· Ten tweede en dit is van cruciaal belang voor de regel, refactor het systeem als de eenvoudigst mogelijke code inclusief alle functies die het nu heeft. Volg de regel van OnceAndOnlyOnce en de andere codekwaliteitsregels om het systeem zo schoon mogelijk te maken.

Onthoud altijd dat we niet op zoek zijn naar de snelste manier; we zijn op zoek naar het eenvoudigste resultaat. Dus we breken eerst de bestaande methode in stukjes. Dat laat de bestaande testgevallen lopen. Vervolgens wijzigen we (eenvoudig, nu) een van de weinige methoden om de volgende testcase te behandelen, enzovoort.

Probeer de eend de volgende keer dat je vastzit

Het sorteren van bugs, problemen en algemene raadsels is een fundamenteel onderdeel van de programmering. Dus het ontwikkelen van technieken om je een weg door de bugs te banen en je weg uit de bindingen te vinden is net zo cruciaal als het leren van alle syntaxis.

En als je vastzit en er niets lijkt te werken, probeer dan de badeend.

Dus ga erop uit en zoek je eigen rubberen eend, of het nu het klassieke gele badspeelgoed is of een verkleed als een piraat - kies er een die je comfortabel vindt en bij je persoonlijkheid past.

Ga je gang; Praat met hem, stel vragen, leg je problemen hardop uit, ruim je spinnenwebben op en lever grote waarde in je code.

Zoals Chris Pine terecht heeft gezegd.

“Programmeren gaat niet over wat je weet; het gaat erom wat je kunt bedenken. "
Over de auteur-:
Ravi Rajan is een wereldwijde IT-programmamanager gevestigd in Mumbai, India. Hij is ook een fervent blogger, Haiku-poëzieschrijver, archeologieliefhebber en geschiedenismaniak. Maak contact met Ravi op LinkedIn, Medium en Twitter.

Dit verhaal is gepubliceerd in The Startup, de grootste publicatie over ondernemerschap van Medium gevolgd door +402.714 mensen.

Abonneer u om onze topverhalen hier te ontvangen.