Există un fenomen ciudat care a apărut în rândul editorilor de software. Se pare că există o tendință ca oamenii să își inverseze înțelegerea despre ceea ce face ca un produs de calitate să fie mai bun, sau cel puțin acest lucru este adevărat atunci când vine vorba de cei care fac marketing.
Merge ceva de genul: „Produsul lor are un milion de linii de cod, dar al nostru are două milioane, deci produsul nostru trebuie să fie mai bun.”
Nimeni nu știe de unde a venit acest tip de gândire „mai mult este mai mult”, când pe vremuri toată lumea lucra atât de mult pentru a crea o filozofie „mai puțin este mai mult”.
Probabil că a început cu jurnalismul de consum, pentru că mulți scriitori încearcă să impresioneze publicul citând numere mari. Pentru majoritatea lucrurilor, acest lucru funcționează – această unitate flash minusculă conține 200 de terabytes de date, acel CPU poate procesa 48 de miliarde de instrucțiuni pe secundă – iar scriitorii nu sunt întotdeauna suficient de pricepuți din punct de vedere tehnologic pentru a înțelege că același lucru nu se aplică codului sursă.
Dar eficiența în codificare nu înseamnă doar crearea de algoritmi strânși. Este, de asemenea, despre posibilitatea de a reduce risipa. Acest lucru înseamnă pierderi în ceea ce privește cât timp petreceți la rezolvarea problemelor, pierdeți în ceea ce privește consumul de resurse computerizate și chiar risipă în ceea ce privește câte cutii de pizza a strâns echipa dvs. în jurul biroului până la sfârșitul săptămânii. În mod ideal, doriți să reduceți toate aceste lucruri.
Cum să îmbunătățiți eficiența codificării în 8 pași simpli
Deci, ceea ce vom analiza în acest articol vor fi lucrurile pe care le-ați putea face pentru a îmbunătăți eficiența și a crește productivitatea.
1. Construiți un mediu de lucru favorabil
Fiecare programator funcționează în circumstanțe unice, iar cititorii noștri sunt o grămadă foarte diversă, astfel încât va fi mai ușor pentru unii dintre voi să implementeze aceste sugestii decât pentru alții.
Dacă sunteți independent, felicitări, pentru că sunteți deja stăpân pe propriul mediu de lucru. Desigur, asta se va schimba atunci când mergi să vizitezi un client și trebuie să lucrezi la fața locului, dar este încă o poziție plăcută în care poți avea succes dacă poți reuși.
Dacă sunteți managerul unei echipe de dezvoltare, aceste sugestii vă pot ajuta, de asemenea, să vă aduceți echipa la o eficiență maximă. Sau dacă sunteți lucrător într-o echipă de dezvoltare, vă recomandăm să sugerați câteva dintre aceste idei managerului dvs. sau cel puțin să îi trimiteți un link către această pagină și să sperați la cele mai bune.
Luați în considerare posibilitatea de a permite membrilor echipei să efectueze telecomenzi
Programarea este parțial un exercițiu de logică, dar este și mai mult o provocare creativă. Cei mai buni programatori își pot folosi fiecare parte a creierului în egală măsură pentru orice sarcină.
Știința a recunoscut de mult că oamenii creativi își fac cea mai bună muncă noaptea și este ceva ce am experimentat cu toții. Deci, de ce majoritatea managerilor insistă pe o rutină tradițională de 9 până la 5?
De fapt, știm deja răspunsul la asta. Este parțial vorba de control și parțial este de a face lucrurile mai convenabile din punct de vedere al afacerii (sau cel puțin din management). Dar insistența asupra rutinei și a locației afectează eficiența și productivitatea echipei.
Ceea ce trebuie să-ți dai seama este că programatorii tăi au stat probabil trează toată noaptea încercând cel mai recent joc, sau poate au mers la petrecere sau pur și simplu au trebuit să socializeze cu familia.
Înseamnă că, atunci când vin la serviciu luni dimineața, nu numai că nu le aduci la nivelul maxim de productivitate, dar sunt deja epuizate de energie și obosiți de câine.
A oferi lucrătorilor o alegere cu privire la momentul în care lucrează - și în mod ideal și unde - este o modalitate excelentă de a îmbunătăți productivitatea și moralul. Atâta timp cât își fac treaba și obțin rezultate excelente de calitate, nu ar trebui să vă pese de când, unde sau cum o realizează.
Excepția este atunci când aveți nevoie de o colaborare strânsă, dar, de fapt, majoritatea programatorilor se descurcă mai bine atunci când sunt lăsați să facă lucrurile în felul lor, iar nevoia unei colaborări strânse este rară.
Opțiunea de a veni la birou ar trebui să existe în continuare, dar nu există niciun motiv realist pentru care ar trebui să fie necesară, cu excepția cazului în care lucrați la proiecte militare secrete.
În calitate de freelancer, puteți vedea, de asemenea, punctul cheie aici este că, dacă faceți cea mai mare parte a activității dvs. de codificare pe timp de noapte, este posibil să faceți mai mult. Există mai puține distrageri noaptea târziu, este mai liniștit și te vei simți mai creativ.
Evitați muzica
Cu toții am văzut acele stereotipuri nebunești ale filmului în care niște überhacker super-grungy își pun căștile și se blochează de-a lungul metalului mortal, în timp ce scoate fără efort ecrane de cod fără să se oprească nici măcar să respire. Și toți cei care codificăm cu adevărat în lumea reală știm cât de ridicolă este acea imagine.
Dar dacă asculți muzică în timp ce lucrezi, fii atent. Este destul de ușor să te gândești la muzică în loc de munca ta, iar unele tipuri de muzică pot avea un efect soporific.
Când mergi la un antrenament la sală, genul potrivit de muzică te-ar putea inspira să faci acele câteva repetări suplimentare. Dar nimeni nu a reușit vreodată să creeze muzică care să te inspire să găsești linia cu punct și virgulă lipsă sau să faci alegerea corectă între a folosi o buclă for sau o buclă while. Cel mai aproape de asta ne-am apropiat vreodată este Electric Dreams.
Încercați să vă mențineți ordonat
Dezordinea poate fi ciudat de reconfortantă, dar, de asemenea, vă poate încetini. Puteți pierde cu ușurință 20 de minute în căutarea a ceva pierdut în mizerie și apoi uitați de ce l-ați dorit în primul rând.
Așadar, pentru toate neplăcerile pe care le provoacă, de ce suntem – cel puțin unii dintre noi – atât de dependenți de dezordine? Expertul și autoarea organizațională, Julie Morgenstern, susține că acest lucru se datorează faptului că aceste lucruri ne conectează cu trecutul nostru și joacă un rol în definirea identității noastre.
Marcus Geduld, un profesor și regizor de scenă cu sediul în New York City, sugerează că acest lucru se datorează faptului că dezordinea este de preferat unui mediu „steril” și aseamănă haosul dezordinei cu o afirmare a libertății și creativității.
Cu toate acestea, nu există nicio îndoială că reducerea dezordinei vă va ajuta să evitați distracția și dezorganizarea. Ca atare, este un obiectiv demn de îndeplinit.
Cu toate acestea, păstrează câteva obiecte sacre în jur care te fac să te simți mai bine și mai puțin stresat, dar nu exagera. Dezordinea este unul dintre cele mai dificile lucruri de făcut pentru majoritatea oamenilor și nu doar desktopurile noastre fizice au nevoie de dezordine, ci și desktopurile computerelor noastre.
Dacă te lupți cu adevărat cu asta, ai putea încerca să folosești un DTE minimalist, cum ar fi Fluxbox, care nu îți permite cu adevărat să ai dezordine.
Dar, în mijlocul tuturor acestor îngrijiri, nu treceți peste bord. Există o mulțime de științe bune care sugerează că un pic de haos în mediu poate fi de fapt propice creativității. Unul dintre cele mai frecvent citate cercetări în acest sens este o intrare în revista Psychological Science de către Vohs, Redden și Rahinel pentru Universitatea din Minnesota, intitulată Ordinea fizică produce alegeri sănătoase, generozitate și convenționalitate, în timp ce tulburarea produce creativitate. Probabil motivul pentru care jurnaliștii se agață de acesta este faptul că concluzionează clar că: „... participanții la o cameră dezordonată au fost mai creativi decât participanții la o cameră ordonată”.
Mult mai puțin populare sunt opiniile divergente, cum ar fi Tulburarea mediului duce la eșecul de autoreglare (Chaye & Zhu, 2014), publicat în Journal of Consumer Research. Acest studiu a constatat că persoanele care lucrează în medii dezordonate au fost afectate de capacitatea lor de a îndeplini sarcini.
Deci, unde te lasă asta? Ar trebui să lucrezi în haos sau sterilitate? Răspunsul pare să fie să găsești un echilibru în care să fie suficient de haotic pentru a te ține inspirat, dar nu atât de mult încât să te distragi sau să ai probleme cu găsirea lucrurilor.
Lăsați spațiu în spatele vostru pentru a vă liniști gândurile
Este o idee bună să ai suficient spațiu pentru rătăcire atunci când deliberezi. Mulți dintre cei mai buni amirali și generali din istorie erau renumiți pentru timpul extins pe care l-au petrecut pășind pe punte în timp ce planificau strategii de luptă.
Nu doar bărbații care luptă urmează această practică. Mulți călugări budiști susțin, de asemenea, „meditația pe jos” și cred că ajută la promovarea clarității minții. Ori de câte ori aveți o problemă de programare deosebit de complicată de rezolvat, s-ar putea să vă fie de ajutor să vă întindeți puțin picioarele cu o plimbare meditativă în jurul punții. Evident, aici din nou, o lipsă de dezordine vă va ajuta să faceți acest lucru fără a ajunge la spital.
În calitate de șef, adoptați o abordare prudentă a criticilor eforturilor creative
Nu există nimic în neregulă cu critica constructivă, dar trebuie să alegeți momentul potrivit și să îl abordați în modul corect, sau se poate da înapoi, făcând personalul dvs. mai puțin productiv în viitor. În loc să îi inspirați și să le oferiți o perspectivă, le puteți face de fapt să se teamă să-și asume riscuri, ceea ce este o modalitate bună de a distruge creativitatea. Marieke Roskes, în Constrângeri care ajută sau împiedică performanța creativă: o abordare motivațională, oferă un cadru pentru a face față motivației lucrătorilor creativi și, în mod specific, și pentru a evita demotivarea neintenționată a acestora (Creativity & Innovation Management, Vol 24, Iss 2, 2015).
2. Stabiliți un SOP bun
Există o mulțime de tendințe captivante în gestionarea afacerii și în procedura de programare care sună mult mai sensibil în teorie decât se pare că sunt în practică. Dacă o anumită abordare funcționează sau nu depinde de obiectivul dvs. și de ceea ce considerați personal a fi un rezultat de succes.
Un exemplu de metodologie pe care a încercat-o o companie pentru care am lucrat – și la fel de repede a renunțat – este programarea în pereche (a nu se confunda cu programarea PEAR).
În timp ce unii oameni admiră cu adevărat această metodologie de lucru și îi laudă locul în paradigma dezvoltării agile, am constatat că a fost teribil de ineficientă.
Pentru început, a fost nevoie de doi programatori pentru fiecare stație de lucru, așa că plăteai de două ori mai mult pentru mai puțină activitate de dezvoltare reală. De asemenea, am constatat că a fost mult mai lent să lucrăm în acest fel din cauza fluxului frecvent de oprire/pornire și a tendinței de dialog inutil.
Avantajele programării în perechi au fost că a avut ca rezultat o documentare mai naturală și o documentare mai strictă. De asemenea, a permis identificarea erorilor mai ușor și să se facă sugestii despre strângerea unui algoritm. În același timp, însă, aceleași avantaje au creat și probleme, deoarece uneori modificările și ajustările nu erau cu adevărat necesare.
Un alt risc cu această abordare este că puteți obține efectul identificat de Roskes, unde programatorii ar putea ezita să încerce lucruri, deoarece nu vor să fie corectați. Este posibil să găsiți ciocniri de personalitate înflăcărate acolo unde un dezvoltator este foarte pedant și tradițional, dar celălalt este mai creativ și spontan.
Programatorii afirmă adesea că preferă programarea în perechi. Este posibil ca acest lucru să se întâmple pentru că se bucură de interacțiunea socială pe care o oferă, dar acest lucru nu contribuie la eficiența producției, cu excepția poate ca un stimul de moral.
Deci, ceea ce trebuie să stabiliți este ceea ce funcționează de fapt pentru dezvoltatorii dvs. și ce nu. Pentru lucrurile care nu funcționează, este mai bine să le aruncați, chiar dacă sunt o practică extrem de populară. Orice ajută echipa să progreseze rapid este un lucru bun. Dar dacă sunt împovărați cu o metodologie care nu se potrivește stilului lor, în cele din urmă va duce la probleme.
3. Încurajați documentația detaliată
Deși poate părea că verbozitatea ar crește ineficiența, cantitatea mică de timp necesară pentru a oferi mai multe detalii și precizie în comentarii poate salva o mulțime de probleme pe măsură ce proiectul se derulează sau suferă revizuiri.
4. Descurajează documentația inutilă
Codul bine scris este adesea auto-documentat. Dacă este perfect evident ce face o funcție din numele pe care i-l dai (ceea ce ar trebui să fie aproape întotdeauna cazul), atunci adăugarea mai multor descrieri este de prisos. Același lucru este valabil pentru denumirea variabilelor și valorile returnate. Ar trebui să fie clar din nume ceea ce fac și, în cazurile în care nu este posibil să faceți acest lucru, ar trebui să includeți o descriere a acestora în comentarii.
5. Spațiul alb este prietenul tău
Utilizarea corespunzătoare a spațiului alb în codul dvs. este utilă pentru a facilita citirea, revizuirea și înțelegerea codului. Merge mână în mână cu o bună documentare și scriere a codului de auto-documentare. Ar trebui să fie posibil ca orice programator cu experiență - sau poate chiar și un non-programator - să preia o copie a codului sursă și să înțeleagă instantaneu care este scopul fiecărei funcții și cum funcționează. În mod ideal, cineva ar trebui să poată învăța să programeze din nimic mai mult decât studierea codului dvs. bine scris.
6. Preferă simplitatea decât complexitatea
Cu cât îți faci codul mai complex, cu atât poate fi mai dificil să-l descurci. În mod ironic, acest lucru se aplică comenzilor rapide de programare, cum ar fi utilizarea condiționatelor stenografice în loc să le scrieți integral. Economisește timp în scriere, dar un programator mai puțin experimentat care vine să vă revizuiască codul mai târziu poate să nu vă înțeleagă intențiile.
7. Testează exhaustiv
Codul trebuie testat în mod incremental și des. Înainte de a implementa ceva, ar trebui să efectuați cât mai multe teste interne, chiar dacă prima dvs. versiune va fi desemnată Alpha.
8. Utilizați controlul versiunii
Trebuie să fii nebun să nu folosești controlul versiunilor într-un proiect major. Fără el, nu sunteți protejat de propriile greșeli minore și, de asemenea, este foarte ușor pentru un alt membru al echipei să vă saboteze accidental (sau intenționat) codul, suprascriindu-l cu ceva care nu vă place.
Concluzie
Luând în considerare aceste opt sugestii cheie, veți putea să vă dezvoltați propria strategie pentru a obține cea mai mare eficiență pentru dvs. și pentru toți membrii echipei cu care lucrați.
Nu trebuie neapărat să le aplicați pe toate și, cu siguranță, unele nu pot fi nici măcar practice pentru dvs., dar orice combinație a acestora va duce probabil să vă finalizați munca cu mai puține bătăi de cap. Un flux de lucru mai productiv se va amortiza în timp, chiar dacă este doar în ceea ce privește reducerea stresului și oferindu-ți mai mult timp pentru tine. Acesta este un obiectiv pentru care merită să lucrezi.
Comentarii Răspunsuri 0