Daar is 'n vreemde verskynsel wat onder sagteware-uitgewers ontstaan โโhet. Daar blyk 'n neiging te wees vir mense om hul begrip van wat 'n kwaliteit produk beter maak om te keer, of dit is ten minste waar wanneer dit kom by diegene wat die bemarking doen.
Dit gaan iets in die lyn van: "Hulle produk het een miljoen reรซls kode, maar ons s'n het twee miljoen, so daarom moet ons produk beter wees."
Niemand weet waar hierdie "meer is meer" soort denke vandaan gekom het, toe almal in die dag so hard gewerk het om 'n "minder is meer"-filosofie te skep.
Waarskynlik het dit begin met verbruikersgraadjoernalistiek, want baie skrywers probeer gehore beรฏndruk deur groot getalle aan te haal. Vir die meeste dinge werk dit - hierdie piepklein flitsskyfie hou 200 teragrepe data, daardie 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 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.
Hoe om koderingsdoeltreffendheid in 8 eenvoudige stappe te verbeter
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 gelyke mate aanwend vir enige taak.
Wetenskap het lankal erken dat kreatiewe mense hul beste werk in die nag doen, en dit is iets wat ons almal ervaar het. So hoekom 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 jy moet besef, is dat jou kodeerders waarskynlik die hele nag wakker was om die nuutste speletjie te probeer, of dalk het hulle partytjie gehou, of bloot met familie moes kuier.
Dit beteken dat wanneer hulle Maandagoggend by die werk opdaag, jy hulle nie net nie op hul hoogste produktiwiteitsvlak kry nie, maar hulle is reeds gedreineer van energie en moeg.
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 wanneer jy noue samewerking nodig het, maar in werklikheid doen die meeste kodeerders beter as hulle oorgelaat word 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 steeds daar wees, maar daar is geen realistiese rede waarom dit vereis moet word nie, tensy jy aan hoogs 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 jy wel na musiek luister terwyl jy werk, wees versigtig. Dit is redelik maklik om te vind dat jy aan die musiek dink in plaas van jou werk, en sommige soorte musiek kan 'n soporiese effek hรช.
Wanneer jy vir 'n oefensessie by die gimnasium gaan, kan die regte soort musiek jou dalk inspireer om daardie ekstra paar herhalings uit te druk. Maar niemand het dit ooit reggekry om musiek te skep wat jou sal inspireer om die lyn met die ontbrekende semikolon te vind, of om die regte keuse te maak tussen die gebruik van 'n for-lus of 'n while-lus nie. Die naaste wat ons nog daaraan gekom het, is Electric Dreams.
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 โ sommige 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 bevestiging 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 tafelrekenaars wat ontruim moet word nie, maar dikwels ook ons โโrekenaarrekenaars.
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 wat 'n maatskappy waarvoor ek gewerk het, probeer het - en net so vinnig laat val het - is paarprogrammering (nie te verwar met PEAR-programmering nie).
Terwyl sommige mense hierdie werkmetodologie regtig bewonder en die plek daarvan in die ratse ontwikkelingsparadigma prys, het ons gevind dat dit verskriklik ondoeltreffend was.
Vir 'n begin het dit twee programmeerders vir elke werkstasie vereis, so jy het twee keer soveel betaal 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.
Gevolgtrekking
Deur hierdie agt sleutelvoorstelle in ag te neem, sal jy jou eie strategie kan ontwikkel om die meeste doeltreffendheid te onttrek vir jou en enige spanlede waarmee jy werk.
Jy hoef nie noodwendig almal toe te pas nie, en sommige is sekerlik nie eens prakties vir jou nie, maar enige kombinasie daarvan sal waarskynlik daartoe lei dat jy jou werk met minder moeite gedoen kry. โn Meer produktiewe werkvloei sal mettertyd vir homself betaal, al is dit net in terme van stresvermindering en om jou meer tyd vir jouself te gee. Dit is 'n doelwit wat die moeite werd is om na te werk.
Kommentaar Kommentaar