Cu mult timp în urmă, am folosit acest rezumat al unor puncte cheie pe care le-am subliniat pentru a studia cartea Clean Code. Sper că îi ajută pe ceilalți.

Alăturați-vă comunității DZone și obțineți experiența completă a membrilor.

punctele

Cu mult timp în urmă, am folosit acest rezumat al unor puncte cheie pe care le-am subliniat pentru a studia cartea Clean Code. Sper că îi ajută pe ceilalți. (Notă: acest rezumat nu exclude necesitatea de a citi cartea.)

Ce este codul curat?

Codul poate fi măsurat fie cu „bine”, fie cu „rău” în revizuirea codului sau cu câte minute îți ia să vorbești despre el.

Un cod curat trebuie să fie elegant, eficient, lizibil, simplu, fără duplicări și bine scris.

Ar trebui să adăugați valoare companiei cu codul dvs.

Codul curat oferă calitate și înțelegere atunci când deschidem o clasă.

Este necesar ca codul dvs. să fie curat și lizibil pentru ca oricine să îl găsească și să îl înțeleagă cu ușurință. Evitați să pierdeți timpul altora.

Nume semnificative

Numele claselor, variabilelor și metodelor trebuie să fie semnificative și să indice clar ce face o metodă sau ce este un atribut.

Creați nume pronunțabile pentru a facilita comunicarea.

Evitați acronimele și evitați denumirile confuze, ceea ce poate duce la concluzii greșite pe oricine citește codul.

Utilizați nume care reflectă domeniul sistemului, contextul și problemele care trebuie rezolvate.

Funcții

Metoda ar trebui să fie ușor de citit și de înțeles.

Metoda ar trebui să-și transmită intenția.

Metodele ar trebui să fie mici. O altă regulă pentru metodele mici este că acestea ar trebui să fie și mai mici.

Trebuie să aibă până la 20 de linii. (Cred că ar trebui să aibă până la 10 rânduri.)

Metodele ar trebui să facă un singur lucru: ar trebui să o facă în modul corect și să o facă.

Ar trebui să folosiți nume cu cuvinte care să spună ce face cu adevărat.

Numărul optim de parametri ai unei metode este zero, după unul și doi.

Trebuie evitate trei, dar dacă credeți că ar trebui să fie utilizate, aveți o bună justificare.

Parametrii de tip boolean ca parametru afirmă deja în mod clar că face mai multe lucruri.

Metodele trebuie să facă ceva și să returneze ceva.

Comentarii

Unul dintre cele mai frecvente motive pentru comentarii este că codul este rău.

Dacă vă gândiți să scrieți un comentariu, atunci codul ar trebui refactorizat.

Comentariile nu salvează un cod greșit.

Încercați să explicați ce face codul să se întâmple.

Comentariile pot fi utile atunci când sunt plasate în anumite locuri.

Creați nume de metode și variabile informative în loc să explicați codul cu comentarii.

Comentariile pot fi folosite pentru a exprima importanța anumitor puncte din cod.

Cel mai bun comentariu este unul care trebuie scris deoarece codul dvs. a fost deja explicat.

Nu scrieți comentarii cu informații redundante, inutile sau false.

Acestea nu ar trebui folosite pentru a indica cine s-a schimbat sau de ce, pentru că există deja în versiune.

Nu comentați codul care nu va fi utilizat, eliminați-l, ci doar poluează codul și nu lasă nicio îndoială în oricine citește.

Formatare

Formatarea ar trebui să indice lucruri importante, deoarece este un dezvoltator de forme de comunicare.

Un cod dezordonat este greu de citit.

Citibilitatea codului va intra în vigoare la toate modificările care vor fi făcute.

Încercați să scrieți o clasă cu maximum 500 de linii. Clasele mai mici sunt mai ușor de înțeles.

Setați o limită de caractere pentru fiecare linie de cod.

O limită bună de caractere pe o linie este 120.

Încercați să păstrați mai multe concepte legate în continuare pe verticală pentru a crea un flux de cod.

Folosiți spații între operatori, parametri și virgule.

Obiecte și structura datelor

Urmați Legea lui Demeter, care spune că o metodă M a unui obiect O poate consuma doar servicii din următoarele tipuri de obiecte:

  • Obiectul în sine, Oh.
  • M parametrii.
  • Orice obiect creat sau instanțiat de M.
  • Componente directe ale O.

Faceți o bună abstractizare și încapsulare.

Nu creați obiecte stupide.

Obiectele ascund abstractizarea datelor și expun metode care operează datele.

Structurile de date vă expun datele și nu au metode semnificative.

Eroare de manipulare

Tratarea erorilor trebuie planificată cu atenție de către toți programatorii.

Când se întâmplă lucruri greșite, trebuie să-l facem să facă lucrurile corecte.

Ar trebui să preferăm lansarea unei excepții decât tratarea ei doar pentru a ascunde.

Creați mesaje cu informații despre eroare.

Menționează că a eșuat. Unde a fost acest eșec? Dacă este posibil, menționați de ce a eșuat.

Consultați reguli comerciale separate pentru erori și gestionarea erorilor.

Evitați să returnați un NULL în metode, de preferință pentru a returna un obiect gol.

Evitați să treceți NULL la metode; acest lucru poate genera NullPointerExceptions.

Limite

În codul terților, pentru a evita trecerea obiectelor, API-urile așteaptă cu nerăbdare pentru a menține lucrurile în aceeași clasă.

Efectuează teste pe terțul API.

Studiați documentația și testați al treilea API înainte de a începe să îl utilizați.

Verificați bine caracteristicile pe care le veți folosi.

Acești pași pot ajuta la creșterea randamentului atunci când există noi actualizări la API și puteți rula testele numai pentru a verifica această actualizare.

Creați testează funcționalitatea API-ului.

Teste de unitate

Asigurați-vă că fiecare bucată de cod face ceea ce vă așteptați să facă.

Urmați legea TDD-urilor:

  • Nu creați cod înainte de a efectua un test nereușit.
  • Nu creați mai multe teste decât este necesar pentru a eșua.
  • Nu puteți scrie mai mult cod decât suficient pentru a trece testul care eșuează.

Păstrați testul curat.

Testele trebuie să sufere modificări în același mod în care codul.

Cu cât codul este mai murdar, cu atât testul mai dificil va fi menținut.

Utilizați regula F.I.R.S.T pentru testare:

  • Testul este rapid-alergare.
  • Testele sunt independent al altuia.
  • Testul este repetabil în diverse medii.
  • Testul este auto-validare.
  • Testul este tvasc.

Testul este la fel de important ca și codul de producție.

Clase

În mod implicit, clasele Java ar trebui să înceapă cu variabilele:

  • Static și public în mod constant.
  • Privat static și variabil.
  • Instanțe și variabile private.
  • Curând după aceea vin funcțiile.

Numele clasei ar trebui să reprezinte responsabilitatea dumneavoastră.

Clasa trebuie să aibă o singură responsabilitate.

Pentru a cunoaște dimensiunea clasei este ideal sau nu ar trebui să măsurăm responsabilitatea ei.

Ar trebui să încercați să faceți o scurtă descriere a clasei.

Metodele ar trebui să fie:

  • Mic.
  • . și chiar mai jos.
  • Trebuie să aibă o singură responsabilitate.

Sisteme

Este important să recunoaștem și să separăm responsabilitățile unui sistem.

Ar trebui să fie separat și să modularizeze execuția logică, permițând o strategie independentă pentru rezolvarea dependenței aplicației.

Este important să aveți grijă de injecțiile de dependență și să permiteți numai obiectelor să se ocupe de afacerea logicii.

Este foarte dificil să creați mai întâi un sistem corespunzător. Trebuie pus la dispoziția poveștii, apoi refactorizat și apoi extins pentru a continua implementarea unor povești noi.

Pentru a ajunge la punctul în care TDD este necesar, aveți nevoie de refactorizare și cod curat.

Trebuie să construim logică bazată pe POJO prin testare și să evoluăm de la simplu la interconectarea diferitelor aspecte necesare.

Apariția

Iată regulile date de Kent Beck pentru a crea modele bune:

  • Rulați toate testele. Aceștia verifică dacă sistemul se comportă conform așteptărilor.
  • Eliminați duplicarea deoarece codul duplicat aduce lucrări suplimentare.
  • Pentru a exprima intenția programatorului, folosiți un cod mai expresiv pentru a facilita întreținerea. Alegeți nume bune pentru funcții, clase și teste nu trebuie să fie mici și bine scrise.
  • Minimizați numărul de clase și metode. Urmarea acestui model o poate ignora dacă clasele sunt foarte mici.
  • Aplicați toate cunoștințele pentru a îmbunătăți designul în timpul refactorizării. Creșteți coeziunea, reduceți cuplarea, separați responsabilitățile, reduceți clasele și metodele, alegeți cele mai bune nume.

Chiar și aplicându-l o singură dată, nu veți putea avea software bun. Trebuie să faceți acest lucru din nou și din nou pentru a obține îmbunătățiri continue.

Concurență

Concurența este un aspect care poate fi prezent în coduri.

Decuplarea permite îmbunătățirea randamentului și structurii unei aplicații.

Concurența poate îmbunătăți timpul de răspuns și eficiența aplicației.

Ar trebui să luați în considerare următoarele idei despre competiție:

  • Injectează o anumită supraîncărcare.
  • Poate fi complex de operat.
  • Erorile cauzate de aceasta pot fi dificil de reprodus.
  • De obicei necesită modificări de proiectare.

Problema concurenței constă în faptul că diferite segmente ale unei aplicații pot urma mai multe thread-uri încurcate, ceea ce poate provoca probleme neașteptate în situații normale.

Din motive de concurență, este important ca fiecare clasă să aibă o responsabilitate unică.

Creați secțiuni care sunt sincronizate și reduse la minimum. Rularea testelor este adesea cel mai bun mod de a găsi erori în cod. Cu toate acestea, este dificil de făcut atunci când există probe de concurs.

O modalitate bună de a testa este să introduceți coduri pentru testare în mijlocul codului implementat.

Rafinare succesivă

Lucrul numai cu cod nu este suficient pentru a avea un cod bun.

Profesioniștii cărora le pasă doar de codul care funcționează nu pot fi considerați profesioniști.

Ar trebui să ignorăm că nu avem timp să refacem un singur cod. Codul care nu a fost îngrijit astăzi poate deveni o problemă după ce a devenit o problemă pentru echipă, deoarece nimeni nu va dori să se încurce cu el.

Încercați să nu lăsați codul să putrezească. Este mult mai ieftin să creați un cod curat decât să curățați un cod putred, deoarece o mișcare într-o încurcătură poate fi o sarcină dificilă.

Soluția se reduce atunci la păstrarea celui mai curat cod posibil și cât mai simplu posibil, fără a-l lăsa vreodată să înceapă să putrezească.

JUnit

Căutați să acoperiți fiecare test (nu fiecare metodă, ci fiecare linie de cod).

Niciun cod nu este imun la îmbunătățire și fiecare dintre noi are responsabilitatea de a face codul puțin mai bun decât l-am găsit.

Refactorizarea este un proces iterativ plin de încercări și erori, convergând inevitabil către ceva care considerăm că este demn de un profesionist.

Refactorizare

Înainte de a face orice fel de refactorizare, este important să aveți teste de acoperire bune.

După creșterea sau crearea acoperirii testului, puteți începe să lăsați cel mai clar cod și să remediați unele erori.

Acum, după ce lăsați codul mai clar, altcineva îl poate curăța și mai mult.

Java

  • Evitați listele lungi de import folosind *.
  • Nu moșteniți constantele. În schimb, utilizați constante enumere.

Numele

  • Alegeți nume descriptive.
  • Alegeți nume la nivelul adecvat de abstractizare.
  • Utilizați nomenclatura standard acolo unde este posibil.
  • Utilizați nume lungi pentru domenii lungi.
  • Evitați codificările.
  • Numele ar trebui să descrie efectele secundare.

Concluzie

Codul curat nu este scris urmând un set de reguli. Nu devii un profesionist în domeniul software-ului doar învățând o listă a ceea ce faci și ce ai făcut.

Profesionalismul și măiestria provin din valori și disciplină din listele a ceea ce ar trebui și ce nu ar trebui să faci atunci când creezi un cod.