Hobiceiurile proaste sunt greu de eliminat și chiar mai greu dacă nu îți dai seama că ceea ce faci îți subminează munca. Dacă știi, dar nu-ți pasă – asta ar fi cel mai rău. Dar ești aici, nu-i așa?
Ca programator, am văzut o mulțime de practici proaste, nu doar în ceea ce privește codul, ci și în ceea ce privește abilitățile de lucru în echipă. Eu însumi am fost vinovat de practicarea multora dintre aceste obiceiuri proaste. Iată primele mele 35 de obiceiuri proaste de programare, organizate în patru categorii: organizarea codului, munca în echipă, scrierea codului și testarea și mentenanța.
Organizarea codului
1. Spunând: „O voi repara mai târziu”
Hobiceiul de a amâna reparațiile de cod nu este doar o problemă de priorități. Organizarea trackerului de probleme ar putea genera unele progrese, dar trebuie să aveți, de asemenea, o modalitate de a urmări problemele mai mici care apar. Adăugarea comentariilor „TODO” este o modalitate rapidă de a vă asigura că nu ratați nimic.
2. Insistați pe o soluție de o singură linie
A fi obsedat de scrierea unor bucăți de cod eficiente și elegante este o trăsătură comună a programatorilor. Este ca și cum ai rezolva un puzzle – găsești o combinație de funcții și expresii regulate care transformă 20 de linii de cod în 2 sau 3. Din păcate, nu întotdeauna rezultă un cod lizibil, iar acesta este, în general, rezultatul mult mai important. Faceți codul dvs. mai întâi accesibil, apoi inteligent.
3. Efectuarea de optimizări inutile
Un alt loc în care deseori ne rătăcim eforturile sunt optimizările. Sună grozav să reduci dimensiunea site-ului tău cu câțiva octeți, dar nu cumva gzip-ul va compensa oricum? Și nu sunt cererile mai importante? Abordați optimizările la sfârșitul unui proiect, pentru că, de cele mai multe ori, cerințele se vor schimba, iar timpul dvs. va fi fost irosit.
„Optimizarea prematură este rădăcina tuturor relelor.”
-Donald Knuth
4. Convingerea că problemele de stil nu sunt atât de importante
Dacă am învățat ceva de-a lungul anilor în care m-am uitat la codul altora, este că rezolvarea problemelor de stil de codare este lucrul pe care dezvoltatorii sunt cel mai probabil să îl amâne. Poate că este greu pentru programatorii neexperimentați să vadă ce bine va ieși din abordarea problemelor de stil, dar în timp va deveni evident că, odată ce calitatea codului deraiază, un efect de bulgăre de zăpadă va transforma orice proiect într-o mizerie completă. Fiți stricți în privința celor mai bune practici, chiar dacă acestea par neglijabile. Configurați instrumente de verificare a codului și de linting pentru a vă oferi spațiu pentru a vă preocupa de lucrurile mai importante.
5. Măturând lucrurile sub preș
Fie prin capturarea și ignorarea excepțiilor, fie prin utilizarea unor biblioteci care nu raportează erorile (cum ar fi jQuery), există multe modalități de a mătura lucrurile sub preș. Dar atunci când una dintre aceste erori devine o prioritate, provocarea de a o repara va fi de multe ori mai mare, având în vedere că nu veți avea nici cea mai mică idee de unde să începeți. O modalitate ușoară de a evita acest lucru este consemnarea acelor erori ignorate, astfel încât să le puteți studia mai târziu.
6. Utilizarea numelor care nu adaugă informații
Numirea este dificilă, dar există o modalitate ușoară de a vă asigura că numele variabilelor și funcțiilor dvs. sunt cel puțin de o calitate decentă. Atâta timp cât numele adaugă un fel de informație pe care restul codului nu o transmite, altor dezvoltatori le va fi mai ușor să vă citească codul. Motivul pentru care denumirea este atât de importantă este că numele pot oferi o idee generală despre ceea ce face codul. Este nevoie de mai mult timp dacă trebuie să sapi în calcule pentru a-ți da seama ce face o bucată de cod, dar un nume bun te poate ajuta să înțelegi ce face codul în câteva secunde.
7. Ignorarea celor mai bune practici dovedite
Revizuirile de cod, dezvoltarea bazată pe teste, asigurarea calității, automatizarea implementării – aceste practici, și multe altele, și-au dovedit valoarea în nenumărate proiecte, motiv pentru care dezvoltatorii scriu constant pe blog despre ele. O referință excelentă pentru aceste bune practici este cartea Making Software: What Really Works, and Why We Believe It. Alocați-vă timpul necesar pentru a învăța cum să le faceți în mod corespunzător, iar procesul de dezvoltare se va îmbunătăți în toate proiectele dvs. în moduri care vă vor surprinde.
Lucrul în echipă
8. Abandonarea prea devreme a planurilor
O modalitate sigură de a vă face sistemul insesizabil este să nu vă angajați la un plan. Puteți spune oricând, ori de câte ori codul dumneavoastră este criticat, că planul nu este complet. Cu toate acestea, a avea module pe jumătate terminate va duce la un cod strâns cuplat imediat ce veți încerca să faceți ca acele module neterminate să funcționeze unele cu altele. Acest tip de complicație apare, de asemenea, atunci când se schimbă rolurile de conducere ale unui proiect, iar noii conducători decid că a face cum vor ei este mai important decât coerența arhitecturală.
9. Insistarea pe un plan care are puține șanse de a funcționa
La fel cum abandonarea planurilor poate cauza probleme, la fel se poate întâmpla și cu menținerea unui plan care nu funcționează. De aceea, ar trebui să vă împărtășiți ideile cu echipa dvs. pentru a obține feedback și sfaturi atunci când lucrurile devin dificile. Uneori, o perspectivă diferită poate face toată diferența.
10. Lucrul pe cont propriu tot timpul
Ar trebui să vă străduiți să vă împărtășiți progresul și ideile cu echipa. Uneori crezi că construiești ceva în mod corect, dar nu este așa, așa că o comunicare constantă este foarte valoroasă. De asemenea, este benefic pentru ceilalți oameni atunci când lucrezi cu ei. Munca lor se îmbunătățește adesea atunci când discutați idei cu ei și îi îndrumați pe membrii mai puțin experimentați ai echipei dumneavoastră, care sunt mai predispuși să se blocheze.
11. Refuzul de a scrie cod prost
Vine un moment în viața fiecărui dezvoltator când termenele limită vă vor forța să scrieți un cod teribil, iar acest lucru este în regulă. Ați încercat să vă avertizați clientul sau managerul în legătură cu consecințele, dar ei insistă să respecte termenul limită, așa că acum este timpul să codificați. Sau poate că există un bug urgent care nu poate aștepta să veniți cu o soluție curată. De aceea, este important să fii versatil ca programator și să fii capabil să scrii foarte repede atât cod prost, cât și cod bun. Să sperăm că puteți revedea codul și să plătiți datoria tehnică.
12. Învinovățirea celorlalți
Nu este un secret faptul că aroganța este o trăsătură mult prea comună printre programatori și alți profesioniști din domeniul tehnic. Asumarea responsabilității pentru greșelile tale este o virtute care te va face să strălucești printre colegii tăi. Nu vă fie teamă să recunoașteți că ați făcut o greșeală. Odată ce sunteți de acord cu acest lucru, veți fi liber să vă concentrați pe a învăța de ce ați făcut acea greșeală și cum să o evitați. Dacă nu vă recunoașteți greșeala, învățarea devine imposibilă.
13. Nu împărtășiți cu echipa dvs. ceea ce ați învățat
Valoarea dvs. ca dezvoltator nu este pusă doar pe codul pe care îl scrieți, ci și pe ceea ce învățați atunci când îl scrieți. Împărtășiți-vă experiențele, scrieți comentarii despre acestea, lăsați-i pe ceilalți să știe de ce lucrurile sunt așa cum sunt și ajutați-i să învețe lucruri noi despre proiect și subtilitățile sale.
14. A fi prea lent în a oferi feedback managerilor/clienților
Una dintre cele mai valoroase trăsături de caracter ale oricărui meseriaș constă în a se asigura că toată lumea este pe aceeași lungime de undă în ceea ce privește munca, pe cât posibil. Motivul pentru acest lucru nu este pentru ca managerul tău să poată umple foi de calcul. Este și pentru propriul dvs. câștig: Veți avea mai puține nesiguranțe și veți reduce incertitudinea cu privire la durata de viață și la viitorul proiectului.
15. Nu folosiți suficient Google
Cel mai bun mod de a rezolva rapid o problemă complexă este să nu trebuiască să o rezolvați deloc. Atunci când aveți îndoieli, căutați pe Google. Desigur, îl poți deranja în schimb pe inginerul de lângă tine, dar rareori acesta va fi capabil să dea un răspuns la fel de detaliat ca Stack Overflow, ca să nu mai vorbim că îi vei întrerupe și munca.
16. Supraevaluarea stilului personal
Întotdeauna urmăriți să vă coordonați stilul de lucru și configurația mediului cu echipa dumneavoastră. În mod ideal, toți cei din echipa dvs. ar trebui să lucreze în condiții similare și să urmeze același stil de codare. Să faci lucrurile în felul tău poate fi mai amuzant, dar colegii de muncă s-ar putea să nu fie obișnuiți cu stilul tău de codare, iar dacă este neobișnuit, va fi mai greu pentru următorul dezvoltator să lucreze la ceea ce ai construit.
17. Având un atașament personal față de codul dumneavoastră
Când cineva comentează despre codul dumneavoastră, nu o luați personal. Codul dumneavoastră ar trebui să stea pe o bază solidă; adică, ar trebui să puteți explica de ce l-ați scris astfel. Dacă are nevoie de îmbunătățiri, aceasta este doar o reflectare a corectitudinii codului, nu a dumneavoastră.
Scrierea codului
18. Să nu știi cum să optimizezi
O bună strategie de optimizare necesită ceva experiență pentru a o face bine. Este nevoie de explorare, de analiză și de cunoașterea fiecărui sistem implicat într-un proces. Informați-vă despre aceste lucruri. Învățați despre complexitatea algoritmică, evaluarea interogării bazelor de date, protocoale și cum se măsoară performanța în general.
19. Utilizarea instrumentului greșit pentru treabă
Puteți ști doar atât de multe, dar motivul pentru care trebuie să continuați să învățați este că fiecare nouă problemă aduce un context diferit și necesită un instrument diferit – unul mai aplicabil sarcinii în cauză. Fiți deschis la noi biblioteci și limbaje. Nu luați decizii bazându-vă strict pe ceea ce știți.
20. Nu vă deranjați să vă stăpâniți instrumentele și IDE-ul
Care nouă tastă rapidă, scurtătură sau parametru pe care îl învățați în timp ce folosiți instrumentele cu care lucrați în fiecare zi va avea un efect mai pozitiv asupra vitezei de codare decât vă dați seama. Nu este vorba de a economisi câteva secunde prin utilizarea unei taste rapide; este vorba de reducerea comutării contextului. Cu cât petreceți mai mult timp pentru fiecare mică acțiune, cu atât mai puțin timp veți avea la dispoziție pentru a vă gândi la motivul pentru care o faceți și la ceea ce urmează. Stăpânirea scurtăturilor vă va elibera mintea.
21. Ignorarea mesajelor de eroare
Nu presupuneți că știți ce este în neregulă cu codul dumneavoastră fără să citiți măcar un mesaj de eroare, sau că vă veți da seama destul de repede. A avea mai multe informații despre o problemă este întotdeauna mai bine, iar dacă vă faceți timp pentru a aduna aceste informații veți economisi mai mult timp pe termen lung.
22. Romantizarea setului de instrumente pentru dezvoltatori
Câteodată editorul dumneavoastră preferat sau instrumentul preferat de linie de comandă nu este cel mai bun instrument pentru treaba respectivă. Visual Studio este grozav pentru a scrie IDE-uri, Sublime este grozav pentru limbaje dinamice, Eclipse este grozav pentru Java, și așa mai departe. S-ar putea să vă placă vim sau emacs, dar asta nu înseamnă că este instrumentul potrivit pentru fiecare sarcină.
23. Hardcoding values instead of making them configurable
Gândiți-vă întotdeauna la ce schimbări ar putea apărea și cum să le faceți față. Datoria tehnică va crește cu o rată monstruoasă dacă nu separați piesele în mișcare de restul muncii dumneavoastră. Utilizați constante și fișiere de configurare acolo unde este cazul.
24. Reinventarea roții tot timpul
Nu scrieți cod de care nu aveți nevoie. Poate că altcineva a petrecut deja mult timp cu problema dvs. și ar putea avea o soluție bine testată pe care o puteți refolosi. Economisiți-vă niște probleme.
25. Copierea/lipirea oarbă a codului
Înțelegeți codul înainte de a-l refolosi. Uneori nu observați imediat tot ceea ce face codul la prima vedere. De asemenea, veți afla mai multe despre o problemă atunci când vă faceți timp să citiți codul în detaliu.
26. Nu vă faceți timp să învățați cum funcționează cu adevărat lucrurile
Întotdeauna profitați de oportunitatea de a vă extinde cunoștințele gândindu-vă la modul în care funcționează lucrurile și citind despre problemele care stau la baza lor. S-ar putea să economisiți timp dacă nu vă deranjați acum, dar ceea ce învățați în cadrul unui proiect va fi mai important pe termen lung decât realizarea efectivă a acestuia.
27. Să ai încredere excesivă în propriul cod
Este periculos să presupui că doar pentru că ai scris ceva, trebuie să fie grozav. Înveți mai multe despre programare pe măsură ce lucrezi la lucruri noi și câștigi experiență, așa că aruncați din când în când o privire la vechiul vostru cod și reflectați asupra modului în care ați progresat.
28. Nu vă gândiți la compromisurile fiecărui design, soluție sau bibliotecă
Care produs are punctele sale fine pe care le veți afla doar folosindu-le și analizându-le. Faptul că vedeți câteva exemple de utilizare a unei biblioteci nu vă va face un maestru al acesteia și nici nu înseamnă că aceasta se potrivește perfect pentru fiecare situație care va apărea în proiectul dumneavoastră. Fiți în permanență critic față de tot ceea ce folosiți.
29. Nu primiți ajutor atunci când vă blocați
Menținerea unei bucle scurte de feedback va fi întotdeauna mai puțin dureroasă pentru dumneavoastră. Să ceri ajutor nu înseamnă că ești incompetent. Oamenii potriviți vor vedea în efortul dumneavoastră și în admiterea ignoranței ca pe o dorință de a învăța, iar aceasta este o mare virtute pe care trebuie să o ai.
Testarea și întreținerea
30. Scrierea de teste care să treacă
Scrierea de teste despre care știți că vor trece este necesară. Ele vor face ca refactorizarea și reorganizarea unui proiect să fie mult mai sigure. Pe de altă parte, trebuie să scrieți și teste despre care știți că nu vor trece. Acestea sunt necesare pentru a face proiectul să avanseze și pentru a ține evidența problemelor.
31. Ignorarea testelor de performanță pentru cazurile critice
Pregătiți o configurare automată a testelor de performanță aproximativ la mijlocul procesului de dezvoltare a unui proiect, astfel încât să vă puteți asigura că nu aveți probleme de performanță care escaladează.
32. Neverificarea faptului că structura dvs. funcționează
Este rar când o structură trece, dar nu funcționează cu adevărat, dar se poate întâmpla și ar putea fi supărător să remediați problema cu cât așteptați mai mult timp pentru a o examina. Testarea rapidă a fiecărui build este un obicei important de avut.
33. Împingerea schimbărilor mari cu întârziere sau plecarea după ce ați făcut un push mare
Acesta este locul unde încrederea excesivă vă va afecta și poate fi nevoie să vă ardeți de mai multe ori pentru a învăța de ce nu ar trebui să faceți acest lucru, așa că urmați-mi sfatul acum și asigurați-vă că sunteți întotdeauna acolo când construcția dvs. se strică în cele din urmă.
34. Respingerea codului pe care l-ați scris
Fiți dispus să susțineți codul pe care l-ați scris. Sunteți persoana cea mai potrivită pentru a-i ajuta pe alții să îl înțeleagă. Ar trebui să vă străduiți să faceți în așa fel încât codul dvs. să rămână lizibil pentru dvs. și pentru alții mulți ani de acum încolo.
35. Ignorarea cerințelor nefuncționale
Când încercați să livrați ceva, poate fi ușor să uitați de unele domenii importante, cum ar fi performanța și securitatea. Păstrați o listă de verificare pentru acestea. Nu vreți să vă strice petrecerea pentru că v-ați întocmit termenele fără să vă gândiți la aceste preocupări nefuncționale.
Care sunt cele mai proaste obiceiuri de programare ale dumneavoastră?
După cum se spune adesea, suntem creaturi ale obișnuinței. Îmbunătățirea modului în care lucrați prin intermediul obiceiurilor este o modalitate excelentă de a evita să trebuiască să vă gândiți prea mult la fiecare situație în parte. Odată ce ați asimilat un mod bun de a face ceva, acesta devine fără efort.