4 tips om te coderen terwijl we onze eigen psychologische tekortkomingen overwinnen

Als we nu de keuze zouden hebben tussen één stuk taart of een hele taart over een maand, zouden we waarschijnlijk voor het eerste kiezen. Deze psychologische vooringenomenheid staat bekend als 'Tijdvoorkeur' of 'Uitstelkorting'.

We hebben allemaal dit mooie voorbeeld gezien van kinderen die proberen vol te houden door geen marshmallow te eten, in de hoop op een grotere beloning:

Bij het schrijven van code worden we vaak geconfronteerd met hetzelfde probleem, namelijk dat we moeten kiezen tussen de kortetermijnvoordelen van slechte praktijken en de langetermijnkosten die het met zich meebrengt.

Zie ook: IoT en codering - wat zijn de meest populaire programmeertalen?

Hier zijn vier voorbeelden van wanneer en hoe we onze vooringenomenheid kunnen overwinnen om op de lange termijn winst te maken.

1. Schrijf eenheidstest, voor uw eigen voordeel

We hebben er allemaal over gelezen, geleerd en gehoord. Testen zijn een goed voorbeeld van iets waarvan ik weet dat ik het zou moeten doen voor de lange termijn, maar het staat me in de weg als ik de klus nu probeer te klaren.

Hier zijn een paar gedachten die kunnen helpen bij het balanceren van deze vergelijking:

• Tests zorgen ervoor dat er niets kapot gaat als je dingen verandert . Dat betekent dat je je code kunt wijzigen en ter plekke weet of alles werkt. Hierdoor kun je vrijer werken, zelfs nu.
• Tests helpen bepalen wanneer iets "goed genoeg" is. Tests bepalen wat het betekent voor een stuk code om te "werken". Hierdoor kunt u in feite minder uitgeven tijd om dingen te optimaliseren die u niet echt hoeft te optimaliseren.
• Tests helpen bij het schrijven van herbruikbare code . Je kunt grotere dingen samenstellen uit kleinere modulaire stukken. Langzaam bouw je een indrukwekkend arsenaal aan herbruikbare bouwstenen op, klaar om op jouw commando te gebruiken.

Wees ook trots op de tests die je schrijft. Zie alle groene indicatoren die boven je code hangen. Weet dat uw praktijk en ethiek uitstekend zijn. Daar is geen schande in.

2. Maak code herbruikbaar terwijl u werkt

Het schrijven van herbruikbare code heeft vele voordelen op de lange termijn en ook enkele directe voordelen. Ontwerp waar mogelijk uw code zodat deze opnieuw kan worden gebruikt. Publiceer/exporteer het dan naar de open source.

U hoeft geen uren te besteden aan het publiceren van pakketten. In plaats daarvan kunt u deze kleine componenten naar Bit exporteren. Hier is een blogpost van Ran Mizrahi waarin wordt uitgelegd waarom en hoe u kleine componenten in enkele seconden kunt exporteren.

Je kunt heel snel een arsenaal aan herbruikbare React- of Angular-componenten of een mooie reeks hulpprogramma-functies creëren.

De inspanning is laag en de webweergave van Bit's community Hub biedt een snel overzicht van de documenten, tests, downloads en meer van uw component, wat onmiddellijke voldoening geeft met uw werk dat nu beschikbaar is voor de wereld. Je kunt het ook delen met je team of de community.

3. Kopieer en plak niet. Gewoon niet doen.

Een klassiek voorbeeld. Door te kopiëren en plakken wordt de klus nu veel sneller gedaan, maar door duplicaties is onze codebase morgen moeilijker te onderhouden en ontstaat er een steeds groter wordende technologische schuld.

Elke kleine wijziging zal op meerdere plaatsen moeten worden aangebracht en problemen zullen vaak pas worden gevonden bij het rollen naar productie.

Wat kunnen we doen? Nou, kopieer en plak geen code! Gewoon niet doen. Zoek / maak / deel in plaats daarvan herbruikbare componenten. Sindre Sorhus heeft meer dan 1.000 kleine pakketjes vrijgegeven. Pakketten zijn moeilijk en 1.000 is veel.

We kunnen Bit gebruiken om dit proces gemakkelijk te maken (componenten exporteren in seconden) en een haalbaar doel stellen, zoals 100 componenten herbruikbaar maken. U zult merken dat ongeveer 100 voldoende is om het aantal duplicaties drastisch te verminderen, en al snel zult u zien dat hergebruik veel sneller gaat dan dupliceren.

4. Documenteer je code, vertel een verhaal

Goede documentatie betekent dat als ik morgen zou worden opgegeten door wilde coyotes, iemand anders mij kan vervangen. Ongetwijfeld belangrijk, maar op dit moment niet mijn eerste zorg. Ik zou liever de klus klaren dan me zorgen te maken over "ik in de toekomst" of degenen die me zullen volgen. Ik zal me er later zorgen over maken als ik er op tijd bij ben. Dit soort (zeer menselijke) prioriteiten stellen leidt tot hiaten en slordigheid in de documentatie.

Er is echter een ander standpunt dat ik kan omarmen om ervoor te zorgen dat ik mijn documentatie niet verwaarloos.

Zowel de code zelf als de documentatie zijn representaties van het logische verhaal dat ik vertel. Door op te schrijven wat elk deel van mijn code doet, de argumenten die het ontvangt, de resultaten toe te voegen, enkele voorbeelden toe te voegen enzovoort, krijg ik ook een goed beeld van de verhaallijn van de code die ik aan het schrijven ben. Ik begrijp hoe het werkt als onderdeel van het grotere geheel.

Goede documenten laten zien dat u volledig begrijpt wat u doet en hoe u het doet. Als het verhaal niet klopt, is het beter om erachter te komen via de documenten dan via de code zelf.

Uiteindelijk is onze wilskracht een beperkte hulpbron. Onszelf dwingen om elk uur van elke dag tegen onze eigen psychologie te vechten, is een zware strijd om te winnen. Het omarmen van goede praktijken is echter een routine en als we onszelf onmiddellijke beloningen geven om het te doen, kunnen we uiteindelijk veel meer bereiken.

Per slot van rekening is één marshmallow per keer echt niet genoeg.