6 sfaturi simple despre cum să începeți scrierea unui cod curat
Aflați tot ce trebuie să știți despre programare și cod, în special JavaScript, TypeScript și React și design.
Cuprins
Scrierea unui cod curat nu este o sarcină ușoară. Necesită experimentarea cu diferite sfaturi și practici. Problema este că există atât de multe practici și sfaturi despre acest subiect încât poate fi copleșitoare. Prin urmare, poate fi greu pentru un dezvoltator să aleagă acele sfaturi și practici demne de urmat. Să simplificăm această sarcină. În acest articol, vom discuta mai întâi câteva avantaje ale scrierii unui cod curat. Apoi, vom analiza șase sfaturi sau practici pentru scrierea codurilor curate pe care dezvoltatorii le folosesc cel mai des.
Avantajele scrierii unui cod curat
Să începem prin a arunca o privire asupra câtorva avantaje pe care le are scrierea unui cod curat. Unul dintre principalele avantaje este că codul curat ne ajută să minimizăm timpul pe care trebuie să-l petrecem citind și încercând să înțelegem codul. Codul dezordonat are abilitatea ciudată de a încetini orice dezvoltator și de a-și face munca mult mai grea. Cu cât este mai dezordonat codul, cu atât mai mult timp dezvoltatorul are nevoie să-l înțeleagă suficient pentru a putea lucra. Și, dacă codul este prea dezordonat, dezvoltatorul poate decide să se oprească și să înceapă de la zero.
1. Mai ușor de început sau de continuat
Permiteți-mi să demonstrez acest lucru pe un exemplu simplu. Să spunem că ne întoarcem la unul dintre proiectele noastre după foarte mult timp. Poate că unul dintre clienții noștri anteriori a luat legătura cu noi și ne-a angajat pentru o altă lucrare. Acum, să ne închipuim că, pe atunci, nu scrieam cel mai curat cod sub soare, ci dimpotrivă. Imediat după prima privire, vedem cât de rău și dezordonat este codul. Și, de asemenea, putem vedea deja cât de greu va fi să începem de unde am rămas.
Drept urmare, acum trebuie să petrecem mult mai mult timp pentru proiect decât ar trebui, pentru că trebuie să înțelegem codul pe care l-am scris înainte. Acest lucru nu este cu siguranță necesar. L-am putea evita complet scriind cod curat chiar de la început. Acum, trebuie să plătim pentru asta. Și există, de asemenea, o mică șansă ca vechiul nostru cod să fie atât de dezordonat sau rău încât putem decide să începem de la zero. Clientul nostru probabil că nu va fi fericit după ce va auzi aceste știri.
Pe de altă parte, codul curat nu are de obicei această problemă. Imaginați-vă exemplul anterior cu condiții opuse. Acum, codul nostru anterior este curat și elegant. Cât va dura să o înțelegeți? Poate că va trebui să citim codul timp de câteva minute pentru a înțelege cum funcționează totul. În cele din urmă, a trecut ceva timp de când nu am scris-o. Cu toate acestea, de această dată investiția va fi semnificativ mai mică decât în primul caz. Clientul nostru nici măcar nu va observa acest lucru.
Acesta este primul beneficiu al unui cod scris într-un mod care este în armonie cu sfaturile pe care le vom discuta. Și acest lucru nu este valabil doar pentru propriile noastre proiecte, ci și pentru munca altor dezvoltatori. Codul curat ne permite să începem mult mai repede. Noi, sau oricine altcineva, nu trebuie să petrecem ore întregi studiind-o. În schimb, putem intra direct în muncă.
2. Mai bine pentru integrarea în echipă
Un alt avantaj al scrierii unui cod curat este strâns legat de primul. Permite adoptarea mai ușoară și mai rapidă. Ce vreau să spun este asta. Să ne imaginăm că trebuie să angajăm un alt dezvoltator. Cât timp îi va lua să înțeleagă codul și să învețe cum să lucreze cu acesta? Depinde. Dacă codul nostru este dezordonat și slab scris, va avea nevoie de mai mult timp pentru a trece prin el. Pe de altă parte, dacă codul nostru este curat, lizibil, ușor de înțeles și va putea începe mai repede.
Unii oameni ar putea dori să susțină că nu este o astfel de problemă, deoarece suntem acolo și o putem ajuta. Și acest lucru este adevărat. Cu toate acestea, ajutorul nostru ar trebui să fie necesar doar pentru o perioadă scurtă de timp, o zi sau două, poate trei. Cu toate acestea, nu ar trebui să fie o săptămână sau două sau trei. În cele din urmă, am decis să angajăm un alt dezvoltator pentru a ne accelera munca, nu pentru a o încetini și mai mult. Scopul nostru nu era să ardem mai mult timp ajutând-o să învețe să lucreze cu codul nostru.
Când depunem efortul și scriem un cod curat, va fi mai ușor pentru alți oameni să îl urmeze și să lucreze cu el. Sigur, va trebui totuși să rezervăm ceva timp pentru a ajuta fiecare nou dezvoltator să învețe și să înțeleagă codul nostru. Cu toate acestea, vorbim despre câteva zile, nu despre săptămâni. De asemenea, codul curat ne va ajuta să aducem mai mulți dezvoltatori în echipă și îi vom ajuta pe toți să înțeleagă codul nostru simultan. Pur și simplu, cu cât codul este mai curat, cu atât este mai ușor să-l explici și mai puțin sunt neînțelegerile.
3. Mai ușor de urmărit
Trebuie să ne amintim un lucru. Înțelegerea și învățarea despre cum să lucrați cu codul este un lucru. Cu toate acestea, acesta este doar începutul. De asemenea, trebuie să ne asigurăm că un dezvoltator este capabil și dispus să urmeze practicile noastre de codificare. Din nou, acest lucru va fi mai ușor de realizat cu un cod curat, mai degrabă decât dezordonat. Acest lucru este important, deoarece nu vrem doar să scriem cod curat, ci să îl păstrăm așa, indiferent de cât de mulți oameni lucrează cu el. Trebuie să ne gândim pe termen lung.
Un ultim lucru legat de asta. Ce se întâmplă dacă unul dintre dezvoltatorii noștri decide să nu urmeze practicile actuale de codare? Această problemă se rezolvă de obicei. Să presupunem că avem un grup de oameni care lucrează pe aceeași bază de cod și unul începe să se abată de la stilul standard. Apoi, unul dintre aceste trei lucruri se va întâmpla. În primul rând, restul grupului îl va împinge pe acel dezvoltator să respecte standardele. O va accepta pentru că nu vrea să plece.
A doua opțiune este ca dezvoltatorul să convingă de fapt restul echipei să adopte și să urmeze practicile sale de codificare. Acest lucru poate fi un lucru bun dacă practicile de codare propuse de dezvoltator sunt mai curate și aduc rezultate mai bune. Scrierea și păstrarea codului nostru curat nu înseamnă că ar trebui să ignorăm orice posibilități de îmbunătățire a acestuia. Mai degrabă opusul. Cred că ar trebui întotdeauna să ne punem la îndoială practicile actuale și să căutăm aceste oportunități de îmbunătățire.
Deci, dacă un dezvoltator se abate de la practicile noastre, iar practicile ei sunt mai bune, poate fi mai bine dacă facem schimbarea, nu ea. Cred că nu ar trebui să ignorăm niciodată practicile cuiva înainte să le examinăm și să le încercăm. Există întotdeauna un loc de îmbunătățire și ar trebui să îl căutăm în continuare. În cele din urmă, există a treia opțiune. Dezvoltatorul nu va decide nici să adopte practicile noastre și nici nu ne va convinge să le adoptăm. În schimb, ea va decide să părăsească echipa.