Daar is 'n vreemde verskynsel wat by sagteware-uitgewers ontstaan het. Dit blyk dat mense geneig is om hul begrip van wat 'n kwaliteitsproduk beter maak te keer, of dit is ten minste waar as dit kom by diegene wat die bemarking doen. Dit gaan in die lyn van: "Hulle produk het een miljoen reëls kode, maar ons s'n het twee miljoen, dus moet ons produk beter wees."
Niemand weet waar hierdie 'more is more' soort denke vandaan kom nie, toe almal destyds so hard gewerk het om 'n 'less is more' filosofie te skep. Dit het waarskynlik begin met joernalistiek van verbruikersgraad, omdat baie skrywers gehore probeer beïndruk deur groot getalle aan te haal. Vir die meeste dinge werk dit - hierdie piepklein skyfie bevat 200 terabyte data, die SVE kan 48 miljard instruksies per sekonde verwerk - en skrywers is nie altyd tegnologies vaardig genoeg om te verstaan dat dieselfde nie van toepassing is op die bronkode nie.
Maar doeltreffendheid in kodering gaan nie net oor die skep van noukeurige algoritmes nie. Dit gaan ook daaroor om afval te verminder. Dit beteken vermorsing in terme van hoeveel tyd u spandeer om probleme op te los, vermorsing in te veel rekenaarbronne, en selfs afval in terme van hoeveel pizzakaste u span teen die einde van die week op kantoor opgestapel het. Ideaal gesproke wil u al hierdie dinge besnoei.
Waarna ons in hierdie artikel gaan kyk, is dit wat u kan doen om doeltreffendheid te verhoog en produktiwiteit te verhoog.
1. Bou 'n bevorderlike werkomgewing
Elke kodeerder werk onder unieke omstandighede, en ons lesers is 'n baie uiteenlopende klomp, so dit sal vir sommige van u makliker wees om hierdie voorstelle te implementeer as vir ander.
Baie geluk, as u 'n vryskut is, want u is reeds 'n meester van u eie werksomgewing. Natuurlik sal dit verander as u 'n kliënt besoek en op die terrein moet werk, maar dit is steeds 'n lieflike posisie om te wees as u 'n sukses daarvan kan maak.
As u die bestuurder van 'n ontwikkelingspan is, kan hierdie voorstelle ook help om u span tot die beste doeltreffendheid te bewerkstellig. Of as u 'n ontwikkelingspan is, wil u dalk sommige van hierdie idees aan u bestuurder voorstel, of ten minste 'n skakel na hierdie bladsy stuur en hoop op die beste.
Oorweeg dit om spanlede toe te laat om te telekommunikasie
Programmering is deels 'n oefening in logika, maar dit is selfs meer 'n kreatiewe uitdaging. Die beste programmeerders kan weerskante van hul brein in dieselfde mate as enige taak gebruik. Die wetenskap erken al lank dat kreatiewe mense snags hul beste werk doen, en dit is iets wat ons almal ervaar het. Waarom dring die meeste bestuurders aan op 'n tradisionele 9 tot 5-roetine?
Eintlik weet ons reeds die antwoord daarop. Dit gaan deels oor beheer, en dit gaan deels oor sake geriefliker vanuit 'n sake-oogpunt (of ten minste 'n bestuurspunt). Maar dat die aandrang op roetine en ligging die doeltreffendheid en produktiwiteit van die span benadeel.
Wat u moet besef, is dat u koders waarskynlik die hele nag besig was om die nuutste wedstryd te probeer, of miskien het hulle gaan partytjie hou, of bloot met familie moes kuier. Dit beteken dat hulle nie net op hul topproduktiwiteitsvlak kom wanneer hulle Maandagoggend werk toe is nie, maar dat hulle alreeds van energie en moegheid vir die hond is.
Dit is 'n uitstekende manier om produktiwiteit en moraal te verbeter om werkers 'n keuse te gee oor wanneer hulle werk - en dit is ook ideaal - Solank hulle die werk verrig en uitstekende resultate vir die gehalte lewer, moet u nie omgee wanneer, waar of hoe hulle dit bereik nie.
Die uitsondering is as u noue samewerking nodig het, maar in werklikheid doen die meeste kodes beter as hulle oorbly om dinge op hul eie manier te doen, en die behoefte aan noue samewerking is skaars. Die opsie om in die kantoor te kom, moet nog steeds daar wees, maar daar is geen realistiese rede waarom dit nodig sou wees nie, tensy u aan geheime militêre projekte werk.
As vryskut kan u ook sien dat die belangrikste punt hier is dat as u die meeste van u werklike koderingswerk snags doen, u waarskynlik meer sal doen. Laat laataand is daar minder afleidings, dit is stiller, en jy sal meer kreatief voel.
Vermy musiek
Ons het almal die mal filmstereotipes gesien waar 'n super-grungy überhacker hul koptelefoon en 'jam' aan die doodsmetaal aantrek terwyl hulle moeiteloos die skerms van kode uithaal sonder om eers te asem te haal. En ons almal wat regtig in die regte wêreld kodeer, weet hoe belaglik hierdie beeld is.
Maar as u na musiek luister terwyl u werk, wees versigtig. Dit is maklik om jouself te laat nadink oor die musiek in plaas van jou werk, en sommige soorte musiek kan 'n soporiese effek hê. As u in die gimnasium oefen, kan die regte soort musiek u inspireer om daardie ekstra paar reps uit te stoot. Niemand het dit nog ooit reggekry om musiek te skep wat jou sal inspireer om die lyn met die ontbrekende semi-kolon te vind nie, of om die regte keuse te maak tussen die gebruik van 'n for-loop of 'n while-lus nie. Electric Dreams is die naaste wat ons daaraan gekom het.
Probeer netjies hou
Die rommel kan vreemd vertroostend wees, maar dit kan jou ook vertraag. U kan maklik 20 minute verloor op soek na iets wat verlore geraak het, en dan vergeet waarom u dit in die eerste plek wou hê.
So, vir al die ongerief wat dit veroorsaak, hoekom is ons – party van ons ten minste – so verslaaf aan rommel? Organisasiekenner en skrywer, Julie Morgenstern, beweer dit is omdat hierdie goed ons met ons verlede verbind en 'n rol speel in die definisie van ons identiteit. Marcus Geduld, 'n onderwyser en verhoogregisseur gebaseer in New York, stel voor dat dit is omdat rommel verkieslik is bo 'n "steriele" omgewing, en vergelyk die chaos van rommel met 'n affirmasie van vryheid en kreatiwiteit.
Daar is egter geen twyfel dat die vermindering van rommel jou sal help om afleiding en disorganisasie te vermy nie. As sodanig is dit 'n waardige doel om te bereik. Hou in elk geval 'n paar heilige voorwerpe in die buurt wat jou beter en minder gestres laat voel, maar moenie dit oordoen nie. Opruiming is een van die moeilikste dinge om te doen vir die meeste mense, en dit is nie net ons fisiese nie desktops wat moet decluttering, maar dikwels ons rekenaar desktops ook. As jy regtig daarmee sukkel, kan jy probeer om 'n minimalistiese DTE soos Fluxbox te gebruik, wat jou nie regtig toelaat om enige rommel te hê nie.
Maar te midde van al hierdie opruimings, moenie oorboord gaan nie. Daar is baie goeie wetenskap wat daarop dui dat 'n bietjie chaos in die omgewing moontlik bevorderlik is vir kreatiwiteit. Een van die mees aangehaalde stukkies navorsing hieroor is 'n joernaalinskrywing in sielkundige wetenskap deur Vohs, Redden & Rahinel vir die Universiteit van Minnesota met die titel Fisiese orde lewer gesonde keuses, vrygewigheid en konvensionaliteit, terwyl wanorde kreatiwiteit lewer. Waarskynlik is die rede waarom die koerant waaraan joernaliste vashou, duidelik tot die gevolgtrekking gekom dat: 'deelnemers in 'n wanordelike kamer kreatiewer was as deelnemers in 'n ordelike kamer.'
Veel minder gewild is uiteenlopende sienings, soos Omgewingsversteuring lei tot selfregulerende mislukking (Chaye & Zhu, 2014), gepubliseer in die Journal of Consumer Research. Hierdie studie het bevind dat mense wat in wanordelike omgewings werk, hul vermoë om take te verrig, aangetas het.
Waar laat dit jou dan? Moet u in chaos of steriliteit werk? Die antwoord blyk te wees om 'n balans te vind waar dit net chaoties genoeg is om u geïnspireer te hou, maar nie soveel dat u afgelei word of probleme ondervind nie.
Laat 'n bietjie ruimte agter jou om jou gedagtes vinniger te laat verloop
Dit is 'n goeie idee om genoeg ruimte te hê om rond te dwaal as u beraadslaag. Baie van die beste admirale en generaals in die geskiedenis was bekend vir die lang tyd wat hulle om die dek deurgebring het tydens die beplanning van gevegstrategieë.
Nie net vegtende mans volg hierdie gebruik nie. Baie Boeddhistiese monnike beywer hulle ook vir 'wandelmeditasie' en glo dat dit die helderheid van die gees help bevorder. As u veral 'n knorrige programmeringsprobleem het om op te los, kan u help om u bene 'n bietjie te rek met 'n meditatiewe stap om die dek. Hier is dit duidelik dat 'n gebrek aan rommel u weer sal help om dit te doen sonder om in die hospitaal te beland.
Neem as baas 'n versigtige benadering tot kritiek op kreatiewe pogings
Daar is niks verkeerd met opbouende kritiek nie, maar u moet die regte oomblik kies en op die regte manier benader, of dit kan terugbrand deur u personeel in die toekoms minder produktief te maak. Eerder as om hulle te inspireer en insig te gee, kan u hulle eintlik bang maak om risiko's te neem, wat 'n goeie manier is om kreatiwiteit te vernietig. Marieke Roskes, in Beperkings wat kreatiewe prestasie help of belemmer: 'n motiverende benadering, bied 'n raamwerk vir hoe om kreatiewe werkers se motivering te hanteer, en spesifiek ook hoe om onbedoelde demotivering daarvan te vermy (Creativity & Innovation Management, Vol 24, Iss 2, 2015).
2. Vestig 'n goeie SOP
Daar is baie pakkende neigings in sakebestuur en programmeringsprosedures wat in teorie baie meer sinvol klink as wat dit in die praktyk blyk te wees. Of 'n spesifieke benadering vir u werk of nie, hang af van u doelwit, en wat u persoonlik as 'n suksesvolle resultaat beskou.
Een voorbeeld van 'n metodologie waarvoor ek gewerk het - en net so vinnig laat val het - is paarprogrammering (nie verwar met PEAR-programmering nie). Terwyl sommige mense hierdie werkmetodologie regtig bewonder en die plek daarvan in die rats ontwikkelingsparadigma prys, vind ons dat dit vreeslik ondoeltreffend is. Dit het aanvanklik twee programmeerders vir elke werkstasie geverg, dus betaal jy twee keer soveel vir minder werklike ontwikkelingswerk. Ons het ook gevind dat dit baie stadiger was om op hierdie manier te werk as gevolg van die gereelde stop / begin-vloei en die neiging tot onnodige dialoog.
Die voordele van paarprogrammering was dat dit meer natuurlike dokumentasie en strenger dokumentasie tot gevolg gehad het. Dit het ook toelaat dat foute makliker raakgesien word en dat daar voorstelle gemaak kan word oor die opskerping van 'n algoritme. Op dieselfde tyd het dieselfde voordele egter ook probleme geskep, want soms was die aanpassings en aanpassings nie regtig nodig nie.
'N Ander risiko by hierdie benadering is dat u die effek wat deur Roskes geïdentifiseer is, kan kry, waar programmeerders huiwerig is om dinge te probeer, omdat hulle nie wil regstel nie. U kan vind dat persoonlikheidsbotsings opvlam waar die een ontwikkelaar baie pedanties en tradisioneel is, maar die ander kreatiewer en spontaan.
Programmeerders noem dikwels dat hulle parprogrammering verkies. Dit is moontlik omdat dit die sosiale interaksie geniet wat dit bied, maar dit dra niks by tot die doeltreffendheid van die produksie nie, behalwe as 'n moraalversterker.
Wat u dus moet vasstel, is wat eintlik vir u ontwikkelaars werk en wat nie. Vir die dinge wat nie werk nie, is dit beter om dit weg te gooi, selfs al is dit 'n baie trending praktyk. Wat die span help om vinnig vordering te maak, is 'n goeie ding. Maar as hulle opgeweeg word met 'n metodologie wat nie by hul styl pas nie, sal dit uiteindelik tot probleme lei.
3. Moedig mondelinge dokumentasie aan
Alhoewel dit lyk asof verbositeit ondoeltreffendheid sal verhoog, kan die klein hoeveelheid tyd wat dit neem om meer kommentaar en akkuraatheid in kommentaar te lewer, baie probleme bespaar namate die projek voortgaan of hersienings ondergaan.
4. Ontmoedig onnodige dokumentasie
Goedgeskrewe kode is dikwels selfdokumenteer. As dit duidelik is wat 'n funksie doen uit die naam wat u daaraan gegee het (wat bykans altyd die geval moet wees), is dit oorbodig om meer beskrywing by te voeg. Dieselfde geld vir veranderlike naamgewing en terugkeerwaardes. Uit die naam moet dit duidelik blyk wat hulle doen, en in die gevalle waar dit nie moontlik is nie, moet u 'n beskrywing daarvan in kommentaar lewer.
5. Wit spasie is jou vriend
Om wit spasie toepaslik in u kode te gebruik, is waardevol om die kode makliker te maak om te lees, te hersien en te verstaan. Dit gaan gepaard met goeie dokumentasie en die skryf van selfdokuminerende kode. Dit is moontlik vir enige ervare programmeerder - of miskien selfs 'n nie-programmeerder - om 'n kopie van u bronkode op te tel en onmiddellik te verstaan wat die doel van elke funksie is en hoe dit werk. Ideaal gesproke moet iemand in staat wees om te leer om uit niks meer te programmeer as om u goedgeskrewe kode te bestudeer nie.
6. Verkies eenvoud bo kompleksiteit
Hoe meer ingewikkeld u kode is, hoe moeiliker kan dit wees om dit te ontrafel. Ironies genoeg is dit van toepassing op die programmering van kortpaaie, soos om korthaar-kondisies te gebruik in plaas daarvan om dit volledig uit te skryf. Dit bespaar tyd in die skryfwerk, maar 'n minder ervare programmeerder wat later u kode sal binnekom, sal moontlik nie u voornemens verstaan nie.
7. Toets volledig
Kode moet inkrementeel en gereeld getoets word. Voordat u iets ontplooi, moet u soveel as moontlik in die huis toets, selfs al word u eerste weergawe Alpha genoem.
8. Gebruik weergawebeheer
U moet mal wees om nie weergawebeheer op 'n groot projek te gebruik nie. Daarsonder is u nie beskerm teen u eie foute nie, en is dit ook vir 'n ander spanlid baie maklik om u kode per ongeluk (of opsetlik) te saboteer deur dit oor te skryf met iets wat u nie behaag nie.
Deur hierdie agt sleutelvoorstelle in ag te neem, kan u u eie strategie ontwikkel om die meeste doeltreffendheid vir u en enige spanlede waarmee u werk, te benut. U hoef dit nie noodwendig almal toe te pas nie, en sommige is miskien nie eens prakties vir u nie, maar enige kombinasie daarvan sal waarskynlik daartoe lei dat u minder moeite doen. 'N Produktiewer vloei sal mettertyd vir homself betaal, selfs al is dit net in terme van stresvermindering en gee u meer tyd vir uself. Dit is die moeite werd om na te streef.
Kommentaar Kommentaar