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 in coderen gaat niet alleen over het maken van strakke algoritmen. Het gaat ook om het kunnen verminderen van verspilling. Dit betekent verspilling in termen van hoeveel tijd je kwijt bent aan het oplossen van problemen, verspilling in termen van het verbruiken van te veel computerhulpmiddelen en zelfs verspilling in termen van het aantal pizzadozen dat je team tegen het einde van de week op kantoor heeft gestapeld. In het ideale geval wilt u al deze dingen beperken.
Hoe u de codeerefficiëntie kunt verbeteren in 8 eenvoudige stappen
Dus wat we in dit artikel zullen bekijken, zijn de dingen die je zou kunnen 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, omdat je je eigen werkomgeving al beheerst. Dat gaat natuurlijk veranderen als je een klant gaat bezoeken en ter plekke moet werken, maar het is nog steeds een mooie positie om erbij te zijn als je er een succes van kunt maken.
Als u de manager bent van een ontwikkelingsteam, kunnen deze suggesties ook helpen om uw team maximale efficiëntie te geven. Of als u een medewerker van een ontwikkelingsteam bent, wilt u misschien een aantal van deze ideeën aan uw manager voorleggen of hem 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 al het antwoord daarop. Het gaat deels om controle, en het gaat er deels om zaken handiger te maken vanuit een zakelijk oogpunt (of op zijn minst een management-oogpunt). Maar dat aandringen op routine en locatie is schadelijk voor 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.
Door werknemers een keuze te geven over wanneer ze werken - en idealiter ook waar - is dit een uitstekende manier om de productiviteit en het moreel te verbeteren. Zolang ze de klus hebben geklaard en uitstekende uitstekende resultaten hebben behaald, zou u zich niet moeten bekommeren om wanneer, waar of hoe ze dit 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 een freelancer zie je ook het belangrijkste punt hier is dat als je het meeste van je echte codeerwerk 's nachts doet, je waarschijnlijk meer gedaan krijgt. Er zijn minder afleidingen 's avonds laat, het is stiller en je zult je creatiever voelen.
Vermijd muziek
We hebben allemaal die waanzinnige filmstereotypen gezien waarbij een paar superfreaks überhacker hun koptelefoon opdoen en jammen op death-metal terwijl ze moeiteloos schermvullingen van code draaien zonder zelfs maar te stoppen om te ademen. En iedereen die echt in de echte wereld codeert, weet 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 vreemd genoeg geruststellend zijn, maar het kan je ook vertragen. Je kunt gemakkelijk 20 minuten verliezen op zoek naar iets dat verloren is gegaan in de puinhoop, en dan vergeten waarom je het in de eerste plaats 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 docent en toneelregisseur uit New York City, suggereert dat dit komt doordat rommel beter is dan een ‘steriele’ omgeving. Hij vergelijkt de chaos van rommel met een bevestiging van vrijheid 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 zeker voor dat je een paar heilige objecten om je heen hebt die je beter en minder gestrest laten voelen, maar overdrijf het niet. Opruimen is een van de moeilijkste dingen om te doen voor de meeste mensen, en het zijn niet alleen onze fysieke desktops die opgeruimd moeten worden, maar vaak ook onze computerdesktops.
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 midden in dit opruimen niet overboord. Er is genoeg goede wetenschap die suggereert dat een beetje chaos in de omgeving in feite bevorderlijk kan zijn voor creativiteit. Een van de meest geciteerde stukjes onderzoek hiernaar is een dagboek in Psychological Science van Vohs, Redden & Rahinel voor de titel University of Minnesota 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.
Waar ga je heen? Moet je in chaos of onvruchtbaarheid werken? Het antwoord lijkt te zijn om een balans te vinden waarbij het gewoon chaotisch genoeg is om je geïnspireerd te houden, maar niet zozeer dat je wordt afgeleid of problemen 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 als je overweegt. Veel van de beste admiraals en generaals in de geschiedenis stonden bekend om de lange tijd die ze brachten tijdens het plannen van gevechtsstrategieën.
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 constructieve kritiek, maar je moet het juiste moment kiezen en het op de juiste manier benaderen, of het kan averechts werken door je personeel in de toekomst minder productief te maken. In plaats van ze te inspireren en inzicht te geven, kun je ze in feite bang maken om risico's te nemen, wat een goede manier is om creativiteit de kop in te drukken. Marieke Roskes, in 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 in de bedrijfsvoering en programmeerprocedure die in theorie veel zinniger klinken dan ze in de praktijk blijken te zijn. Of een bepaalde aanpak voor u werkt of niet, hangt af van uw doel 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 programming (niet te verwarren met PEAR-programmering).
Hoewel sommige mensen deze werkmethodologie echt bewonderen en de plaats ervan in het agile ontwikkelingsparadigma prijzen, ontdekten wij dat deze vreselijk inefficiënt was.
Om te beginnen waren er voor elk werkstation twee programmeurs nodig, dus je betaalde twee keer zoveel voor minder daadwerkelijk 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-programmering waren dat het resulteerde in meer natuurlijke documentatie en strengere documentatie. Het maakte het ook mogelijk om bugs gemakkelijker te herkennen en om suggesties te doen om een algoritme aan te scherpen. Tegelijkertijd leidden dezelfde voordelen echter ook tot problemen, omdat de aanpassingen en aanpassingen soms niet echt nodig waren.
Een ander risico met deze aanpak is dat je het effect kunt krijgen dat door Roskes is geïdentificeerd, waar programmeurs misschien aarzelend zijn om dingen te proberen omdat ze niet gecorrigeerd willen worden. Je kunt personageconflicten tegenkomen waarin de ene ontwikkelaar heel pedant en traditioneel is, maar de andere is creatiever en spontaner.
Programmeurs geven vaak aan dat ze liever programmeren met paren. Het is mogelijk dat dit komt omdat ze genieten van de sociale interactie die het biedt, maar dit draagt niets bij aan de efficiëntie van de productie, behalve misschien als een morele booster.
Dus wat u moet vaststellen, is wat echt werkt voor uw ontwikkelaars en wat niet. Voor de dingen die niet werken, is het beter om ze weg te gooien, zelfs als ze een fel trending practice zijn. Wat het team ook helpt om snel vooruitgang te boeken, is een goede zaak. Maar als ze worden belast met een methodiek die niet bij hun stijl past, zal dit 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 met 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 variabele naam- en retourwaarden. Uit de naam moet duidelijk zijn wat ze doen en in die gevallen waarin dat niet mogelijk is, zou je een beschrijving daarvan in opmerkingen moeten 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 voor een groot project. Zonder dit, bent u niet beschermd tegen uw eigen kleine fouten, en is het ook heel gemakkelijk voor een ander teamlid om uw code per ongeluk (of opzettelijk) te saboteren door deze te overschrijven met iets dat u niet bevalt.
Conclusie
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.
Heb je vragen? Stel ze hier. 0 Reacties