8 eenvoudige trucs om de codeerefficiëntie te vergroten

Als u zich abonneert op een dienst via een link op deze pagina, kan Reeves and Sons Limited een commissie verdienen. Zie onze ethische uitspraak.

Er is een vreemd fenomeen ontstaan ​​onder software-uitgevers. Er lijkt een tendens te bestaan ​​bij mensen om hun begrip van wat een kwaliteitsproduct beter maakt, om te keren, of dit is tenminste waar als het gaat om degenen die de marketing doen. Het gaat ongeveer zo: “Hun product heeft een miljoen regels code, maar dat van ons heeft er twee miljoen, dus daarom moet ons product beter zijn.”

Niemand weet waar dit ‘meer is meer’-denken vandaan kwam, toen iedereen vroeger zo hard werkte om een ​​‘less is more’-filosofie te creëren. Waarschijnlijk begon het met consumentenjournalistiek, omdat veel schrijvers indruk proberen te maken op het publiek door grote cijfers te citeren. Voor de meeste dingen werkt dit – deze kleine flashdrive bevat 200 terabytes aan gegevens, de CPU kan 48 miljard instructies per seconde verwerken – en schrijvers zijn niet altijd technologisch onderlegd genoeg om te begrijpen dat hetzelfde niet geldt voor de broncode.

Maar efficiëntie bij het coderen gaat niet alleen over het creëren van strakke algoritmen. Het gaat ook om het kunnen verminderen van afval. Dit betekent verspilling in termen van de hoeveelheid tijd die u besteedt aan het oplossen van problemen, verspilling in termen van het verbruiken van te veel computerbronnen, en zelfs verspilling in termen van hoeveel pizzadozen uw team tegen het einde van de week op kantoor heeft opgestapeld. Idealiter wil je op al deze dingen bezuinigen.

Waar we in dit artikel naar kijken, zijn de dingen die u kunt doen om de efficiëntie te verbeteren en de productiviteit te verhogen.

1. Bouw een gunstige werkomgeving

Elke codeur werkt in unieke omstandigheden en onze lezers zijn een zeer diverse groep, dus het zal voor sommigen van jullie gemakkelijker zijn om deze suggesties te implementeren dan voor anderen.

Als je een freelancer bent, gefeliciteerd, want je hebt je eigen werkomgeving al onder de knie. Natuurlijk gaat dat veranderen als je op bezoek gaat bij een klant en op locatie moet werken, maar het is nog steeds een mooie positie als je er een succes van kunt maken.

Als u de manager bent van een ontwikkelteam, kunnen deze suggesties u ook helpen om uw team maximaal efficiënt te maken. Of als u in een ontwikkelingsteam werkt, wilt u misschien enkele van deze ideeën aan uw manager voorstellen of hem of haar op zijn minst een link naar deze pagina sturen en er het beste van hopen.

Overweeg om teamleden te laten telewerken

Programmeren is deels een oefening in logica, maar het is nog veel meer een creatieve uitdaging. De beste programmeurs kunnen beide kanten van hun brein in gelijke mate inzetten voor elke taak. De wetenschap heeft al lang erkend dat creatieve mensen 's nachts hun beste werk doen, en dat hebben we allemaal meegemaakt. Waarom houden de meeste managers dan toch vast aan een traditionele 9 tot 5-routine?

Eigenlijk weten we het antwoord daarop al. Het gaat deels om controle, en deels om het gemakkelijker maken van zaken vanuit zakelijk oogpunt (of in ieder geval vanuit managementoogpunt). Maar die nadruk op routine en locatie schaadt de efficiëntie en productiviteit van het team.

Wat je moet beseffen is dat je programmeurs waarschijnlijk de hele nacht wakker zijn geweest om de nieuwste game uit te proberen, of misschien zijn ze gaan feesten, of moesten ze gewoon gezellig bijkletsen met familie. Het betekent dat wanneer ze op maandagochtend op hun werk verschijnen, je ze niet alleen niet op hun maximale productiviteitsniveau krijgt, maar dat ze al geen energie meer hebben en hondmoe zijn.

Werknemers de keuze geven wanneer ze werken – en idealiter ook waar – is een uitstekende manier om de productiviteit en het moreel te verbeteren. Zolang ze de klus klaren en uitstekende kwaliteitsresultaten behalen, zou het je niets kunnen schelen wanneer, waar of hoe ze dat bereiken.

De uitzondering hierop is wanneer je nauwe samenwerking nodig hebt, maar in werkelijkheid presteren de meeste codeerders beter als ze de dingen op hun eigen manier moeten doen, en de noodzaak voor nauwe samenwerking is zeldzaam. De mogelijkheid om naar kantoor te komen zou er nog steeds moeten zijn, maar er is geen realistische reden waarom dit nodig zou zijn, tenzij je aan uiterst geheime militaire projecten werkt.

Als freelancer zie je ook dat het belangrijkste punt hier is dat als je het grootste deel van je eigenlijke codeerwerk 's nachts doet, je waarschijnlijk meer gedaan krijgt. Er is 's avonds laat minder afleiding, het is rustiger en u voelt zich creatiever.

Vermijd muziek

We hebben allemaal die gekke filmstereotypen gezien waarin een super-grungy überhacker zijn koptelefoon opzet en mee jamt op death-metal terwijl hij moeiteloos schermen vol code draait zonder zelfs maar te stoppen om te ademen. En wij allemaal die in de echte wereld echt coderen, weten hoe belachelijk dat beeld is.

Maar wees voorzichtig als u tijdens het werk naar muziek luistert. Het is vrij gemakkelijk om aan de muziek te denken in plaats van aan je werk, en sommige soorten muziek kunnen een slaapverwekkend effect hebben. Als je gaat trainen in de sportschool, kan de juiste soort muziek je inspireren om net dat extra paar herhalingen te doen. Maar niemand is er ooit in geslaagd muziek te maken die je inspireert om de regel met de ontbrekende puntkomma te vinden, of om de juiste keuze te maken tussen het gebruik van een for-loop of een while-loop. Het dichtst dat we daar ooit bij in de buurt zijn gekomen, is Electric Dreams.

Probeer netjes te houden

Rommel kan op een vreemde manier geruststellend zijn, maar het kan je ook vertragen. Je kunt gemakkelijk twintig minuten verliezen met het zoeken naar iets dat verloren is gegaan in de puinhoop, en dan vergeten waarom je het überhaupt wilde hebben.

Waarom zijn we, ondanks al het ongemak dat het veroorzaakt, zo verslaafd aan rommel? Organisatie-expert en auteur Julie Morgenstern beweert dat dit komt doordat dit spul ons met ons verleden verbindt en een rol speelt bij het definiëren van onze identiteit. Marcus Geduld, een leraar en regisseur uit New York City, suggereert dat dit komt omdat rommel te verkiezen is boven een ‘steriele’ omgeving, en vergelijkt de chaos van rommel met een affirmvrijheid en creativiteit.

Er bestaat echter geen twijfel dat het verminderen van rommel je zal helpen afleiding en desorganisatie te voorkomen. Als zodanig is het een waardevol doel om te verwezenlijken. Zorg er in ieder geval voor dat je een paar heilige voorwerpen bij de hand hebt waardoor je je beter en minder gestrest voelt, maar overdrijf het niet. Opruimen is voor de meeste mensen een van de moeilijkste dingen om te doen, en het is niet alleen fysiek desktops die moeten worden opgeruimd, maar vaak onze computer desktopook. Als je daar echt moeite mee hebt, kun je proberen een minimalistische DTE te gebruiken, zoals Fluxbox, waardoor je niet echt rommel hebt.

Maar ga tijdens al dit opruimen niet overboord. Er is voldoende goede wetenschap die suggereert dat een beetje chaos in de omgeving juist bevorderlijk kan zijn voor de creativiteit. Een van de meest geciteerde onderzoeken hiernaar is een dagboekaantekening in Psychological Science door Vohs, Redden & Rahinel voor de Universiteit van Minnesota, getiteld Fysieke orde produceert gezonde keuzes, vrijgevigheid en conventionaliteit, terwijl stoornis creativiteit produceert. Waarschijnlijk is de reden waarom dit de papieren journalisten zijn die eraan vastklampen, dat er duidelijk wordt geconcludeerd dat: "... deelnemers in een wanordelijke kamer creatiever waren dan deelnemers in een ordelijke kamer."

Veel minder populair zijn afwijkende meningen, zoals Milieudisstoornis leidt tot zelfregulerend falen (Chaye & Zhu, 2014), gepubliceerd in het Journal of Consumer Research. Uit deze studie bleek dat mensen die in een ongeordende omgeving werkten, minder goed in staat waren om taken uit te voeren.

Dus waar laat dit je achter? Moet je in chaos of in steriliteit werken? Het antwoord lijkt te zijn: het vinden van een evenwicht waarbij het net chaotisch genoeg is om je geïnspireerd te houden, maar niet zozeer dat je afgeleid raakt of moeite hebt om dingen te vinden.

Laat wat ruimte achter je om je gedachten te uiten

Het is een goed idee om voldoende ruimte te hebben om rond te dwalen tijdens het nadenken. Veel van de beste admiraals en generaals uit de geschiedenis stonden bekend om de lange tijd die ze besteedden aan het ijsberen over het dek terwijl ze gevechtsstrategieën planden.

Niet alleen vechtende mannen volgen deze praktijk. Veel boeddhistische monniken zijn ook voorstander van 'loopmeditatie' en geloven dat het helpt om de helderheid van de geest te bevorderen. Als je een bijzonder lastig programmeerprobleem hebt om op te lossen, kan het helpen om je benen een beetje te strekken met een meditatieve wandeling over het dek. Uiteraard helpt ook hier weer een gebrek aan rommel je om dit te doen zonder in het ziekenhuis te belanden.

Als een baas, neem een ​​voorzichtige benadering van kritiek op creatieve inspanningen

Er is niets mis met opbouwende kritiek, maar u moet het juiste moment kiezen en het op de juiste manier benaderen, anders kan het averechts werken en uw personeel in de toekomst minder productief maken. In plaats van ze te inspireren en inzicht te geven, kun je ze juist bang maken om risico's te nemen, wat een goede manier is om de creativiteit de kop in te drukken. Marieke Roskes, op Beperkingen die helpen of Hinder creatieve prestaties: een motivationele aanpak, biedt een raamwerk voor het omgaan met motivatie van creatieve werknemers, en specifiek ook om te voorkomen dat ze onbedoeld worden gedemotiveerd (Creativity & Innovation Management, Vol 24, Iss 2, 2015).

2. Zorg voor een goede SOP

Er zijn veel pakkende trends op het gebied van bedrijfsbeheer en programmeringsprocedures die in theorie veel verstandiger klinken dan ze in de praktijk blijken te zijn. Of een bepaalde aanpak voor u werkt of niet, hangt af van uw doelstelling en wat u persoonlijk als een succesvol resultaat beschouwt.

Een voorbeeld van een methodologie die een bedrijf waar ik voor werkte probeerde - en net zo snel liet vallen - is pair-programmeren (niet te verwarren met PEAR-programmering). Terwijl sommige mensen deze werkmethodologie echt bewonderen en zijn plaats in het agile ontwikkelingsparadigma prijzen, vonden we dat het vreselijk inefficiënt was. Om te beginnen waren er twee programmeurs nodig voor elk werkstation, dus je betaalde twee keer zoveel voor minder echt ontwikkelingswerk. We ontdekten ook dat het veel langzamer was om op deze manier te werken vanwege de frequente stop / start-stroom en de neiging tot onnodige dialoog.

De voordelen van pair programming waren dat het resulteerde in meer natuurlijke documentatie en striktere documentatie. Het zorgde er ook voor dat bugs gemakkelijker konden worden opgemerkt en dat er suggesties konden worden gedaan over het aanscherpen van een algoritme. Tegelijkertijd zorgden dezelfde voordelen echter ook voor problemen, omdat de aanpassingen en aanpassingen soms niet echt nodig waren.

Een ander risico van deze aanpak is dat je het door Roskes geïdentificeerde effect kunt krijgen, waarbij programmeurs misschien aarzelen om dingen te proberen omdat ze niet gecorrigeerd willen worden. Het kan zijn dat er persoonlijkheidsconflicten oplaaien waarbij de ene ontwikkelaar erg pedant en traditioneel is, maar de ander creatiever en spontaner.

Programmeurs geven vaak aan dat ze de voorkeur geven aan pair programming. Het is mogelijk dat dit komt doordat ze genieten van de sociale interactie die het biedt, maar dit draagt ​​niets bij aan de efficiëntie van de productie, behalve misschien als moreelbooster.

Wat u dus moet vaststellen, is wat daadwerkelijk werkt voor uw ontwikkelaars en wat niet. Voor de dingen die niet werken, is het beter om ze weg te gooien, ook al zijn ze een populaire praktijk. Wat het team ook helpt om snel vooruitgang te boeken, is een goede zaak. Maar als ze gebukt gaan onder een methodologie die niet bij hun stijl past, zal dat uiteindelijk tot problemen leiden.

3. Moedig uitgebreide documentatie aan

Hoewel het lijkt alsof breedsprakigheid de inefficiëntie zou verhogen, kan de kleine hoeveelheid tijd die het kost om meer detail en precisie in opmerkingen te geven, veel problemen besparen wanneer het project meegaat of herzieningen ondergaat.

4. Ontmoedig onnodige documentatie

Goed geschreven code is vaak zelfdocumenterend. Als het volkomen duidelijk is wat een functie doet op basis van de naam die je eraan geeft (wat bijna altijd het geval zou moeten zijn), dan is het toevoegen van meer beschrijving overbodig. Hetzelfde geldt voor de naamgeving van variabelen en retourwaarden. Uit de naam moet duidelijk blijken wat ze doen, en in die gevallen waarin dat niet mogelijk is, moet je een beschrijving ervan in de opmerkingen opnemen.

5. Witte ruimte is je vriend

Het op de juiste manier gebruiken van witruimte in uw code is waardevol om te helpen de code leesbaarder, overzichtelijker en begrijpelijker te maken. Het gaat hand in hand met goede documentatie en het schrijven van zelfdocumenterende code. Elke ervaren programmeur - of misschien zelfs een niet-programmeur - zou een kopie van uw broncode moeten kunnen ophalen en onmiddellijk begrijpen wat het doel van elke functie is en hoe het werkt. Idealiter zou iemand moeten kunnen leren programmeren vanuit niets anders dan het bestuderen van je goed geschreven code.

6. Geef de voorkeur aan eenvoud boven complexiteit

Hoe complexer u uw code maakt, hoe moeilijker het kan zijn om het te ontwarren. Ironisch genoeg is dit van toepassing op het programmeren van snelkoppelingen, zoals het gebruik van steno-voorwaardes in plaats van ze volledig uit te schrijven. Het bespaart tijd bij het schrijven, maar een minder ervaren programmeur die binnenkomt om uw code later te beoordelen, begrijpt mogelijk niet wat u van plan bent.

7. Test uitgebreid

Code moet stapsgewijs en vaak worden getest. Voordat u iets implementeert, moet u zoveel mogelijk interne tests uitvoeren, zelfs als uw eerste release wordt aangeduid als Alpha.

8. Gebruik versiebeheer

Je zou gek moeten zijn om geen versiebeheer te gebruiken bij een groot project. Zonder dit ben je niet beschermd tegen je eigen kleine fouten, en het is ook heel gemakkelijk voor een ander teamlid om per ongeluk (of opzettelijk) je code te saboteren door deze te overschrijven met iets dat je niet bevalt.

Door rekening te houden met deze acht belangrijke suggesties, kunt u uw eigen strategie ontwikkelen om de meeste efficiëntie te behalen voor u en alle teamleden waarmee u werkt. U hoeft ze niet noodzakelijkerwijs allemaal toe te passen, en sommige zijn misschien niet eens praktisch voor u, maar elke combinatie ervan zal er waarschijnlijk toe leiden dat u uw werk met minder moeite gedaan krijgt. Een productievere workflow zal zichzelf in de loop van de tijd terugbetalen, ook al is het alleen maar in termen van stressvermindering en het geven van meer tijd voor jezelf. Dat is een doel dat de moeite waard is om naartoe te werken.

Bogdan Rancea

Bogdan is een van de oprichters van Inspired Mag en heeft in die periode bijna 6 jarenlange ervaring opgebouwd. In zijn vrije tijd studeert hij graag klassieke muziek en onderzoekt hij beeldende kunst. Hij is ook behoorlijk geobsedeerd door fixies. Hij is al eigenaar van 5.

Heb je vragen? Stel ze hier. 0 Reacties

Laat een reactie achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd *

Rating *

Deze site gebruikt Akismet om spam te verminderen. Ontdek hoe uw reactiegegevens worden verwerkt.