marți, septembrie 14, 2010

Clean Code

Clean Code este o carte scrisa de Robert C. Martin - care incearca sa surprinda experienta lui in scrierea de cod, experienta care se intinde pe cateva decenii (in carte se remarca cum regulile s-au schimbat de-a lungul timpului odata cu evolutia limbajelor de programare). Am incercat sa citesc cartea (versiunea fizica) dar nu am avut timp decat pentru primele 5 capitole si sa le rasfoiesc pe celelate in una din saptamanile de vacanta din acest an - am remarcat cu ocazia asta cat de putin timp avem sa citim in mod clasic.

In aceasta carte totul este de bun simt si ne poate salva de cosmarul debugingului continuu - cateodata ma gandesc ca printre programatori sunt unuii (cei care fac mentenanta) care nu fac altceva decat sa caute in gunoaie (codul vechi). Din cate imi dau seama a aplica regulile din Clean Code impreuna cu TDD (Test Driven Development) reprezinta cea mai buna metoda de a creste calitetea interna a produselor software - a le face valoroase pe termen lung din perspectiva dezvoltarii ulterioare/mentenantei.

Clean code pleaca de la urmatoarea premiza: cu siguranta codul pe care il scriem astazi va fi citit de catre cineva (toti speram ca nu noi) in viitor. De acea claritatea lui este foarte importanta. A fi usor de citit implica si a fi usor de modificat. Daca dezvoltarea unui proiect dureaza pana intr-un an, metinera lui (mentenance) va dura mai multi ani. Aceasta implica fixare de bug-uri, adaugare de mici feature-uri etc, care implica interactiuni cu codul respectiv. Desigur se poate face orice in debugger unde se poate vedea absolut orice. Dar este mult mai complicat decat a lucra cu un cod clar care exprima de la sine pentru ce a fost scris - intr-un fel exprima businessul implementat.

Primul accent pus in carte este pe numele pe care le vom da claselor, metodelor, campurilor care compun aplicatiile noastre. Ele trebuie sa exprime de la sine scopul si contextul in care sunt folosite. Nu trebuie sa ne zgarcim cu lungimea pe care o va avea numele lor - cel mai important este ca ele sa fie cat se poate de expresive si clare. Codul trebuie schimbat si modificat pana indeplineste criteriile de calitate stabilite de noi - nu trebuie sa ne fie frica sa intervenim de oricate ori este nevoie (este o practica in metodologiile de agile de a partaja codul intre toti membrii echipei si a permite tuturor sa il modifice cu incredere)

Surprinzator sau nu in capitolul dedicat comentariilor suntem sfatuiti sa nu le folosim deloc - doar in anumite situatii. Idea de a pune un comentariu care sa dubleze codul comentat nu este o idee buna - la o urmatoare interventie asupra codului comentariul poate deveni desincronizat fata de cod. Acest lucru nu poate introduce decat confuzie - codul trebuie sa exprime de la sine ceea ce implementeaza. Pentru aceasta trebuie sa exprime intentia noastra in asa maniera incat comentariile sa fie de prisos.

Un aspet foarte important este modul in care scriem metodele (care dau functionalitatea claselor). Autorul ne propune metafora unui ziar (newspaper) in care stirile nu sunt prezentate toate in intregime pe prima pagina. Pe prima pagina ni se prezinta titlul si un rezumat urmand o trimitere la urmatoarea pagina unde este intreg continutul. Trebuie sa distingem astfel intre nivelurile de abstractizare dintr-o metoda si sa nu le amestecam. Asa vom avea pentru fiecare functonalitate implementata un arbore de metode care abstractizeaza pe niveluri diferite functionalitatea. Metodele care se refera la un acelari aspect de domeniu vor fi pastrate impreuna - intr-o aceasi unitate de compilare. Int-o metoda trebuie sa faca un singur lucru - daca vrem sa facem si altceva o putem face intr-o alta metoda pe care o vom apele.

Testele unitare/integrare trebuie sa ghideze dezvoltarea - in fapt codul pe care il scriem o sa fie mai ingrijit daca o sa facem teste pentru el pentru ca este dificil sa testam un cod complicat (e greu de exemplu sa introducem multe mock objects daca avem prea multe dependinte in metoda noastra, e greu sa facem prea multe assert-uri daca metoda noastra face mai multe lucruri). Testele trebuie sa fie punctul de executie pentru orice functionalitate nou pa care o introducem in aplicatie (nu trebuie sa rulam toata aplicatia pentru asta si sa folosim logging pentru a vedea ca ce am scris merge). Teoretic deployerea aplicatiei ar trebui sa o facem foarte rar, la final - dupa ce am dezvoltat local ghidati de teste unitare/integrare. De asemenea sugereaza sa folosim teste (unitare/integrare) si pentru a ne acomoda cu noile librarii pe care vrem sa le introducem in proiect.

Clean code este un coplement la idea de stil de codare sau cea de conventii de nume:

  • stil de codare - reprezinta un set consistent de reguli de sintaxa care trebuie respectate de intreaga echipa pentru coerenta codului. Se cunosc o serie de astfel de codari - Eclipse, Sun(Oracle), Apache; ele pot fi setate la nivel de IDE pentru a oferi coerenta in cod
  • conventii de nume - un set de cosistent de reguli pentru denumirile care se folosesc intr-o aplicatie pentru clase, metode, campuri - spre exemplu sufixarea anumitor categorii de clase (XyzService, XyzAction, XyzDAO)
In carte sunt enumerate si unele principii stiute de programare carora treuie sa le acordam atentia cuvenita: Open Closed Principle, Single Responsibility Principle si Law of Demeter.