Ați realizat vreodată ca și programator că vă petreceți mai mult timp citind cod decât scriind? Dacă răspunsul este da, atunci ați nimerit unde trebuie. Salut! Numele meu e Bogdan Iancu și astăzi aș vrea să vorbim despre Clean Code sau varianta mai pe lung: de ce e mai important felul în care scriem cod, decât ceea ce scriem efectiv. Ca să trec repede în agenda despre ce vom discuta astăzi: Aș vrea la început să vorbim despre motivația acestui „cod curat”. De ce Clean Code? Despre niște principii sau prințipuri cum ar spune Caragiale, că nu e așa, o bucată de cod fără prințipuri care va să zică că nu le are. Niște convenții de nume, puțină practică legată de clean code, adică clean code aplicat în diverse elemente de limbaj de programare, la sfârșit un scurt dicționar, niște instrumente ce ne ajută să scriem cod curat și un bonus.
De ce Clean Code? Cum spuneam și la început, programatorii își petrec în medie mai mult timp citind cod decât scriind. La început nu v-am amintit procentele însă ele sunt destul de mari, sau destul de disproporționate. Programatorii, în medie, 90% din timp citesc cod și doar 10% din timp scriu cod. Și așadar putem spune că programarea nu constă în a spune computerului ce să facă și de fapt constă în a spune altui om ce vrem ca acel computer să facă. Din păcate, și sunt sigur că ați realizat și voi asta, acel om suntem câteodată chiar noi, o variantă din viitor a noastră, un „future us”. Și dacă stăm bine să ne gândim până la urmă suntem autori. La fel cum scriitorii folosesc cărți, paragrafe, capitole și texte, text efectiv, la fel și noi folosim programe, clase, metode, cod în metode, suntem plătiți pentru ceea ce scriem, așadar până la urmă suntem niște autori. Și dacă alegem să nu scriem cod (clean), vom realiza de fapt că am fost mai leneși decât dacă am fi scris codul corect de la început. De ce? Păi dacă suntem leneși de la început și nu scriem codul clean sau curat, vom sesiza că apoi, chiar dacă atunci ne ia foarte puțin timp să scriem, apoi va dura mult mai mult să scriem acel cod, să-l modificăm, decât dacă atunci când l-am scris prima dată am fi alocat puțin mai mult timp scriindu-l corect sau curat. Și nu în ultimul rând, să nu ajungem la serviciu un substantiv.
Nu știu dacă v-ați lovit de chestia asta, dar uite să spunem că eu aș fi colegul cunoscut pentru modul în care scrie cod, adică cu picioarele. Să spunem că ceilalți colegi vor să compare un cod scris de un alt coleg cu un cod scris de mine, adică tot cu picioarele, ar putea spune despre acel cod că e un „bogdănism”. Dacă eu mă numesc Bogdan, a scris cod la fel ca mine, am ajuns un substantiv. Nu am vrea să ajungem în situația asta, nu? Așa că aplicăm niște principii și acestea sună oarecum ciudat, adică au niște nume care nu duc cu nimic la, nu amintesc în nici un fel de principii legate de programare, dar o să vedem ce înseamnă fiecare. Sunt doar niște acronime ce ne permit să le reținem ușor. Acestea sunt DRY, KISS, YAGNI și SOLID.
Și până la a vedea ce înseamnă fiecare aș vrea să vă mai amintesc ceva. Când citim cod creierul nostru joacă rol de compilator. Adică trebuie să parcurg codul respectiv și să văd ce face el efectiv ca să îți poți da seama unde pun o linie în plus și ce scriu mai departe. Conform studiilor, oamenii pot reține, s-a dovedit, că oamenii pot reține simultan 7 elemente. Plus minus două, asta de la persoană la persoană, în memorie. Asta înseamnă că orice funcție care are mai mult de șapte parametri, mai mult de șapte variabile locale sau mai mult de șapte niveluri de indentare, o să vedem imediat ce înseamnă fiecare, e destul de greu de reținut sau destul de greu de parcurs de un om. Să spunem că principiul nostru e de a scrie cod pentru calculator pe care să îl înțeleagă ceilalți oameni, nu cod pe care să îl înțeleagă calculatorul. Deci aveți mare atenție asupra acestei cifre de 7 atunci când scrieți cod.
Apoi mai există conceptul de „rubber duck programming” de care nu știu dacă ați auzit. Dacă nu ați auzit, el e destul de simplu și funny (amuzant) în același timp. Presupune explicarea codului scris unei rățuște de cauciuc. Deci avem o rățușcă de cauciuc pe birou și îi explicăm rățuștei ce am scris pentru fiecare chestie. Pentru fiecare linie de cod. Și verbalizând acel cod, pe lângă faptul că putem face debugging în acest fel, adică depanarea codului, pentru că spunând cu voce tare, sau chiar și în gând, dar vorbind cu altcineva la persoana a treia, sau la persoana a doua, dacă ne adresăm în mod direct, și verbalizând acel cod, realizăm ce erori am făcut și ce putem modifica. La fel și după ce terminăm de scris codul, ar fi ok să i-l explicăm rățuștei, ca să ne dăm seama dacă ar putea fi cumva modificat astfel încât să fie mai ușor de înțeles atunci când va fi citit de un alt programator.
Ok. Și hai să trecem rapid peste aceste principii care sunau așa oarecum ciudat. DRY – nu se referă la un deșert sau la altceva uscat, ci este o prescurtare de la Don’t Repeat Yourself, adică atunci când scriem cod nu e loc de copy-paste. De fiecare dată când scriem cod și găsim în funcțiile noastre un lucru scris de mai multe ori sau simțim nevoia să luăm cu copy-paste un lucru și să îl punem în altă parte, de fiecare dată, e loc de o nouă funcție sau de o nouă metodă. Deci acel cod va trebui scris într-o metodă separată pe care să o apelăm de fiecare dată când ar trebui de fapt să dăm paste. Și de ce facem lucrul ăsta? Păi în primul rând din punct de vedere al mentenanței, dacă în acel cod pe care noi îl luam cu copy-paste va trebui să modificăm ceva, dacă noi am dat copy-paste și l-am pus de 7 ori de exemplu, va trebui să modificăm de 7 ori, chestia respectivă. Cu riscul de a nu găsi un loc în care am dat paste și să ne trezim cu un bug pe care nu avem cum să îl explicăm. Fiind într-un singur loc, e foarte ușor să fac apelul acelei metode sau să fac modificarea doar în acel loc. Și legat de apel, e mult ai ușor să apelez o metodă folosind și intellisense-ul din multe IDE-uri, adică medii de dezvoltare, decât să dau paste. Adică e ceva de genul: scriu primele litere, control+spațiu sau care e shortcut-ul (scurtătura) din mediul respectiv pentru autocompletarea codului sursă.
Ok, următorul principiu. KISS – provine de la Keep It Simple and Stupid, deci să menținem codul simplu și stupid, sau stupid de simplu, mai bine spus. Ăsta e aplicabil ori de câte ori vrem ca o metodă să facă de toate. Deci nu e ok ca o metodă să facă prelucrări complexe, gen: să verifice utilizatorul și să trimită mail. Nu, avem două metode separate, una verifică utilizatori, una trimite mail. E oarecum similar și cu Single Resposability, pe care o să îl vedem imediat, ce presupune ca o metodă sau o clasă să facă un singur lucru, e asemănător oarecum, se referă oarecum și la următorul, și anume la YAGNI.
YAGNI vine de la You Ain’t Gonna Need It (N-o să ai nevoie de el – sau de ea dacă e funcție) și anume, nu trebuie să scrii niciodată metode ce nu sunt necesare încă. Adică nu trebuie să gândim aprioric pentru cei ce ne vor citi metodele, să spunem „aaa, sigur o să aibă nevoie de asta, hai să o scriu aici”. Nu, dacă nu e cerută în specificații și eu nu am nevoie să apelez, nu apelez. E principiul „Ce poți face azi lasă pe mâine că poate mâine nu mai trebuie”. La fel se întâmplă și aici. Poate mâine nu vor fi necesare, poate nu vor fi necesare niciodată. De ce să depun efort acum ca să scriu niște funcții pe care poate cineva le va folosi. Dacă are nevoie să și le scrie, e destul de simplu. Și asta este valabil și pentru noi, avem nevoie de ceva, ne scriem, nu cerem altcuiva să ne scrie o funcție. Spuneam că e oarecum derivat din KISS, da. Sau sunt noțiuni care coincid pe alocuri. Și ajungem la cel mai complicat dintre ele și anume SOLID. Acesta are la rândul lui, SOLID e format din alte 5 principii: S-ul provine de la Single Responsability, O-ul de la Open-Closed, L-ul de Liskov Substituion, I-ul de la Interface Segregation și D-ul de la Dependency Inversion. Și hai să le luam pe fiecare în parte (în episodul următor).
0 comentarii