Aflați tot ce trebuie să știți despre programare și cod, în special JavaScript, TypeScript și React și design.

despre

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.

Sfaturi despre scrierea unui cod curat

Acum, când discutăm unele dintre avantajele scrierii unui cod curat, este timpul să învățăm câteva sfaturi care ne vor ajuta să o facem. După cum vom vedea în rândurile următoare, codul curat îmbrățișează și urmează anumite practici. Aceste practici fac ceea ce face codul nostru mai curat, mai ușor de citit, mai ușor de înțeles și mai simplu. Nu este necesară implementarea tuturor acestor practici. Implementarea și urmărirea doar a unuia sau a două pot fi suficiente pentru a aduce rezultate pozitive.

1. Faceți codul lizibil pentru oameni

Este adevărat că codul pe care îl scriem va fi interpretat de mașini. Cu toate acestea, asta nu înseamnă că ar trebui să neglijăm lizibilitatea și comprehensibilitatea acestuia. Există întotdeauna șansa ca un alt om să ajungă la codul nostru sau să fie nevoit să lucreze cu el. Chiar dacă facem codul nostru inaccesibil pentru alții, este posibil să dorim să revenim la el în viitor. Din acest motiv, este în interesul nostru să scriem codul nostru într-un mod care să faciliteze înțelegerea citirii. Cum?

Cel mai simplu mod este de a folosi spațiul alb. Este în regulă să ne minimizăm codul înainte de al expedia. Cu toate acestea, nu este necesar să scrieți cod care să pară minificat. În schimb, putem folosi indentarea, întreruperile de linie și liniile goale pentru a face structura codului nostru mai lizibilă. Când decidem să adoptăm această practică, lizibilitatea și înțelegerea codului nostru se pot îmbunătăți semnificativ. Apoi, o singură privire asupra codului nostru poate fi suficientă pentru a o înțelege. Să aruncăm o privire la două exemple simple.

2. Folosiți nume semnificative pentru variabile, funcții și metode

Să aruncăm o privire la cel de-al doilea sfat care ne va ajuta să scriem un cod inteligibil și curat. Acest sfat este despre utilizarea de nume semnificative pentru variabile, funcții și metodă. Ce înseamnă semnificativ? Numele semnificative sunt nume suficient de descriptive încât alte persoane, și nu doar noi, vor putea înțelege scopul variabilei, funcției sau metodei. Cu alte cuvinte, numele însuși ar trebui să sugereze pentru ce este utilizată variabila, funcția sau metoda sau ce conține.
Cod:

Cu toate acestea, trebuie să ținem cont de ceva. Utilizarea denumirilor descriptive nu înseamnă că suntem liberi să folosim câte caractere dorim. O regulă bună este de a limita numele la trei sau patru cuvinte. Dacă trebuie să folosim mai mult de patru cuvinte, poate că încercăm să facem prea multe lucruri simultan și ar trebui să ne simplificăm codul. Deci, să folosim doar câte caractere este necesar.

3. Lasă o funcție sau o metodă să efectueze o singură sarcină

Când am început cu codificarea, obișnuiam să scriu funcții și metode care semănau aproape cu un cuțit elvețian. Puteau să facă față și să facă aproape orice. Una dintre consecințe a fost că a fost adesea greu să găsești un nume bun. În al doilea rând, aproape nimeni, cu excepția mea, nu știa ce face această funcție și cum să o folosească. Ei bine, uneori chiar eu am avut probleme. Așadar, a trebuit să scriu instrucțiuni. În al treilea rând, aceste funcții erau uneori destul de imprevizibile. Am creat o mizerie.

Apoi, cineva a dat acest mare sfat. Lăsați fiecare funcție sau metodă să efectueze o singură sarcină. Acest sfat simplu a schimbat totul și m-a ajutat să scriu un cod curat, cel puțin mai curat decât înainte. Din acel moment, alți oameni au reușit în sfârșit să înțeleagă codul meu. Sau nu au avut nevoie de atât de mult timp cât au avut nevoie înainte. Funcțiile și metodele mele devin, de asemenea, previzibile. Au produs întotdeauna aceeași ieșire având aceleași intrări. Și denumirea a devenit mult mai ușoară.

Dacă vă este greu să găsiți nume descriptive pentru funcțiile și metodele dvs. sau trebuie să scrieți instrucțiuni îndelungate, astfel încât alte persoane să le poată folosi, luați în considerare implementarea acestei practici. Lăsați fiecare funcție sau metodă să efectueze o singură sarcină. Implementați această practică și dacă funcțiile și metodele dvs. arată și funcționează ca un cuțit elvețian. Crede-mă, această versatilitate nu este un avantaj. Este mai degrabă un dezavantaj care poate începe să se declanșeze în orice moment.

Notă laterală: această practică de a lăsa fiecare funcție sau metodă să efectueze o singură sarcină se numește principiul responsabilității unice. Această practică de codificare a fost introdusă de Robert C. Martin ca unul dintre cele cinci principii de proiectare orientate pe obiecte, cunoscute și sub numele de SOLID. Dacă doriți să aflați mai multe despre aceasta, vă recomand să citiți acest articol.
Cod:

4. Folosiți comentarii pentru clarificare

Nu contează cât de mult încercăm să venim cu nume semnificative pentru variabilele, funcțiile și metodele noastre. Codul nostru de la sine nu este încă atât de curat și de înțeles pe cât ar putea fi. Există încă câteva linii care necesită explicații suplimentare. Este posibil ca problema să nu fie că sunt greu de înțeles sau de utilizat. În schimb, este posibil să nu aibă sens de ce implementăm această funcție sau altă metodă sau de ce am creat-o în acel mod specific. Adică, istoria este încă neclară.

Uneori este posibil să trebuiască să folosim o abordare destul de neconvențională pentru a rezolva o problemă, deoarece nimic altceva nu funcționează sau nu avem suficient timp pentru a veni cu o soluție mai bună. Acest lucru poate fi dificil de explicat cu codul. Utilizarea comentariilor prin intermediul codului nostru ne poate ajuta să remediem această problemă. Comentariile ne pot ajuta să explicăm altor persoane de ce am scris ceea ce am scris și de ce am scris-o în acel mod specific. Ca urmare, alte persoane nu vor trebui să ghicească.

Mai mult, atunci când explicăm motivele noastre, alte persoane pot găsi o modalitate mai bună de a rezolva problema și de a îmbunătăți codul. Acest lucru va fi posibil doar pentru că știu care este problema și care este rezultatul dorit. Ar fi mult mai greu pentru alții să creeze o soluție mai bună fără să cunoască aceste informații. Sau, este posibil să nu încerce nici măcar pentru că nu ar crede că este necesar. Puteau crede că a fost intenția noastră.

Deci, ori de câte ori ne aflăm într-o situație în care decidem să folosim o abordare de tip hack, fix rapid sau neconvențional, să folosim comentarii pentru a explica de ce am făcut ceea ce am făcut. Este mai bine să folosiți una sau două rânduri pentru un comentariu cu explicații decât să forțați oamenii să ghicească.

Acestea fiind spuse, ar trebui să folosim comentariile numai atunci când este necesar, nu pentru a explica codul rău. Scrierea unor linii nesfârșite de comentarii nu ne va ajuta să transformăm codul slab scris într-un cod curat. Dacă codul este rău, ar trebui să remediem problema îmbunătățind codul, nu adăugând un set de instrucțiuni despre cum să-l folosim. Codul curat are prioritate față de utilizarea comenzilor rapide.

5. Fii consecvent

Când găsim practici sau stiluri specifice de codare care ne plac, ar trebui să ne ținem de ea și să le folosim peste tot. Utilizarea diferitelor practici sau stiluri de codificare în diferite proiecte nu este o idee bună. Este aproape la fel de util și util ca să nu folosești deloc nicio practică sau stil de codare. Revenirea la vechiul nostru cod nu va fi la fel de lină și naturală pe cât ar putea fi. Vom avea încă nevoie de ceva timp pentru a înțelege practica de codare pe care am folosit-o în acel proiect înainte ca noi să putem lucra cu el.

Cel mai bun lucru de făcut este să alegeți un set de practici de codare și apoi să rămâneți la aceste practici în toate proiectele noastre. Apoi, va fi mult mai ușor să ne întoarcem la codul nostru mai vechi și să continuăm de unde am rămas sau să-l îmbunătățim. Dar experimentarea? Încercarea unor noi practici de codare este un lucru bun. Ne poate ajuta să găsim modalități mai bune de a ne face treaba. Cu toate acestea, este mai bine să experimentăm diferite practici pe proiecte sau exerciții experimentale separate, nu pe proiectele noastre principale.

De asemenea, atunci când decidem să facem un experiment, ar trebui să încercăm această practică de mai multe ori și pe mai multe exemple. Ar trebui să ne luăm timpul pentru a face acest experiment în detaliu. Doar atunci când suntem cu adevărat convinși că ne place acea practică și ne simțim confortabili cu ea, ar trebui să o implementăm. Și, atunci când decidem să facem acest lucru, este mai bine să implementăm noua noastră practică la nivel global, în toate proiectele noastre. Da, acest lucru va dura timp, dar ne va obliga să ne gândim corect la schimbare.

6. Examinați regulat codul

Acesta este ultimul meu sfat despre scrierea unui cod curat. Pur și simplu scrierea unui cod curat nu este totul. Treaba noastră nu se termină cu punctul și virgula finală. Următorul pas este păstrarea codului nostru curat. Codul curat necesită întreținere. Când scriem ceva, ar trebui să analizăm periodic, să-l curățăm și să încercăm să-l îmbunătățim. În caz contrar, dacă nu examinăm și actualizăm vechiul nostru cod, acesta va deveni în curând învechit. La fel ca în cazul dispozitivelor noastre. Dacă vrem să le menținem în cea mai bună formă, trebuie să le actualizăm regulat.

Același lucru este valabil mai ales pentru codul cu care lucrăm zilnic. Codul are tendința de a deveni mai complex și aglomerat cu timpul, nu mai simplu și mai curat. Depinde de noi să prevenim acest lucru și să ne păstrăm codul curat. Singura modalitate de a realiza acest lucru este prin revizuirea periodică a codului nostru. Cu alte cuvinte, trebuie să o menținem. Acest lucru poate să nu fie necesar pentru proiectele care nu ne mai interesează sau care nu au viitor. Pentru restul, întreținerea face parte din treaba noastră.

Gânduri de închidere cu privire la scrierea unui cod curat

Și suntem la sfârșitul acestui articol. Aceste șase practici, pe care le-am discutat astăzi, s-ar putea să nu fie cele cu cel mai mare impact sau cele mai semnificative rezultate. Cu toate acestea, acestea sunt printre cele menționate cel mai frecvent de dezvoltatorii experimentați. De aceea i-am ales. Sper că aceste practici sau sfaturi vor fi suficiente pentru a vă ajuta să începeți să scrieți cod curat. Acum, la fel ca în toate, cel mai important lucru este să începeți. Deci, alegeți cel puțin o practică și încercați-o.

Dacă ți-a plăcut acest articol, te rog să te abonezi pentru a nu pierde nicio postare viitoare.

Dacă vrei să mă sprijini pe mine și pe acest blog, poți deveni patron sau îmi poți cumpăra o cafea 🙂