Transcriere
Legat de comentarii și de reguli de Clean Code în comentarii: ce cele mai multe ori comentariile nu își au locul deloc. Dacă codul nostru e destul de bine scris și conform principiilor pe care le-am enunțat până acum, el este auto-explicativ. Nu am nevoie să mai scriu încă o dată ce face linia respectivă de cod. Scriu int numarZile = 7, n-am nevoie să pun comentariu deasupra – numărul de zile a fost inițializat cu 7. Se prinde toată lumea de asta.
Apoi, nu e indicat să folosim comentarii pentru a ne cere scuze. Cred că nu e nevoie să vă spun eu chestia asta. Toți am întâlnit poate comentarii de genul ăsta – „când am scris asta doar Dumnezeu și eu știam ce am scris aici, acum doar Dumnezeu știe”. E specifică pentru unii programatori. Sau comentarii de genul „p-aici crapă ceva, investighează și tu”. Nu e datoria altcuiva să facă depanare pe codul nostru pentru că nici nouă la rândul nostru nu ne place să facem depanare pe codul altuia.
Sunt permise comentarii doar în două situații și vi le amintesc imediat. Până atunci, e o practică proastă să comentăm cod sursă că poate va fi folosit dup-aia. Nu o să avem nevoie de el – You Ain’t Gonna Need It. De ce? Pentru că există soluții de versionare și aici dau câteva exemple: Turtoise SVN, Git, TFS și dacă mai știți voi altele puteți să le scrieți în comentarii. Soluția de versionare e de fapt un program instalat pe un server pe care stă tot codul și apoi pe fiecare client, pe fiecare mașină pe care codează programatorii, și care îmi permite să fac două chestii: 1. Să pun modificările mele pe server și 2. Să iau toate noile modificări de pe server. În acest fel poate să lucreze o echipă pe același cod. Eu modific într-un fișier, pun modificarea pe server, când fac Get Latest Version îmi aduce toate modificările de pe server, ale celorlalți. Pot să lucrez pe cod în continuare și așa mai departe. Eu când trimit pe server modificările mele, trimit toate detaliile legate cine sunt eu, la oră am dat commit, etc. Adică nu e nevoie să pun detalii și în al doilea rând pot să fac oricând restore la codul vechi. Să restaurez un cod pe care l-am scris deja. Deci dacă mă trezesc că am șters o metodă, pot oricând să mă întorc la versiunea veche în care scrisesem codul. Adică oricând am acces asupra istoricului modificărilor.
Dacă folosiți sau simțiți nevoia de a folosi comentarii pentru a face o metodă mai lizibilă pentru că poate nu se înțelege, atunci cred că e cazul ca acea metodă să devină mai multe metode. Și anume acolo unde simțiți nevoia să introduceți un comentariu ca să separați cumva partea de sus de partea de jos, poate ar fi mai ok să faceți de fapt un apel al unei alte metode Asta se întâmplă de obicei pentru metode ce au mai mult de 20 de linii de cod, care deja încalcă cealaltă regulă pe care am enumerat-o și anume numărul maxim de linii de cod.
Trebuie să evităm blocurile de comentarii introductive. Le-ați mai văzut în unele limbaje. Alea cu autor nu știu care, modificat ultima dată la. Toate acestea sunt în soluția de versionare. Și mai aminteam și slide-ul trecut că există două excepții de la a nu scrie comentarii și anume: am voie să scriu comentariu de tip doc comment (în Java și în C# atunci când creezi biblioteci). Adică trebuie să informez oarecum pe cei ce vor folosi biblioteca puțin mai mult decât în cazul unei funcții scrise pentru oricine. Adică vreau să spun exact ce face funcția respectivă și atunci pot să scriu un paragraf ca și doc comment despre utilitatea exactă a funcției respective.
O altă aplicabilitate a comentariilor și un alt caz în care sunt permise sunt TO DO comments. Adică. scriu comentarii de tip TODO cu ce mai e de implementat în funcția respectivă. Să zicem că trebuie să arăt clientului exact ce am făcut eu. Am acum demo, o demonstrație a ce face aplicația. Trebuie să fac neapărat într-o oră, nu am timp să valideze toate chestiile. Validez 3 dintre ele și îmi trec acolo TODO – de validat celelalte două sau câte au mai rămas. După ce fac prezentare revin și le validez. Sau e vineri și fac un comentariu TODO despre ce o să fac luni. Acestea nu trebuie să persiste în soluția de versionare și în niciun caz nu trebuie ajungă în varianta finală, aceea care va fi scoasă pe piață (released).
Mai avem un scurt dicționar și cu asta cam încheiem. Și anume legat de anumiți termeni pe care poate i-ați auzit la serviciu și nu i-ați înțeles sau poate i-ați citit prin diverse tutoriale și nu i-ați înțeles sau pe care poate îi auziți prima dată.
În primul rând vorbim de Test Driven Development sau TDD. E exact schema asta din dreapta și anume fac dezvoltare bazându-mă pe cazuri de utilizare. Clientul vine la mine cu specificația de program și eu scriu cazuri în care programul respectiv nu va merge. Scriu un caz, apoi scriu cod care trece acel caz, adică cod care clarifică și pune toate condițiile astfel încât acele failing tests sau teste de fail a programului vor fi satisfăcute. Fac refactor. Asta înseamnă rescrierea codului sursă într-o manieră ce se pretează mai bine noilor specificații. Adică rescriu codul astfel încât să trec testul respectiv. Dacă trece testul, atunci trec la un nou test, conform schemei de aici. Scriu un nou failing test, scriu cod care să îl treacă, dacă nu rescriu codul, dacă da scriu încă un failing test și tot așa până când nu mai există teste de trecut. Când codul meu trece toate testele atunci vorbim de un cod ce poate fi scos pe piață sau trecut în varianta de release. Și nu vă gândiți că testele astea se fac neapărat manual. Când vorbim aici de „write a failing test” nu vorbim de o descriere neapărat scrisă a cazului în care codul respectiv crapă ci de automatic testing sau Unit Testing, și anume un cod ce permite testarea automată a altui cod. Deci e un cod scris ca să testeze alt cod.
Și e foarte util și în refactoring. Să spunem că nu neapărat am scris un nou caz de utilizare și vreau să fac acel cod al meu mai bun. Nu, vine clientul și vrea o nouă specificație. Vrea să introducă altceva în programul lui. Eu ca să introduc altceva dacă am respectat regulile de Clean Code, pot să adaug chestii în plus în clasă. Spuneam că nu e ok să modific, dar să zicem că n-am fost inspirat în acea zi și trebuie să fac și modificări. Mă pot trezi că la refactoring introduc regression, adică regresie. Codul meu convine noilor standarde, noilor specificații, noilor cazuri de utilizare, dar nu le mai respectă pe cele vechi. Și atunci aș vrea să știu chestia asta și pentru asta rulez din nou testele scrise pentru codul vechi și văd dacă le satisface pe acelea și le satisface și pe cele noi atunci totul e ok.
Mai avem ca și element în scurtul nostru dicționar Code Review. Ce înseamnă Code Review sau validarea codului să îi spunem în română? E o tehnică întânită în special în programarea AGILE. AGILE e o tehnică de programare. Mă rog, e de fapt un manifesto, un manifest prin care sunt definite niște reguli, și pornind de la aceste reguli sunt definite niște reguli mai specifice ce dau denumirea unor tehnici de programare. Și avem aici Extreme Programming dat ca exemplu și Scrum.
Extreme Programming (XP) conține și Pair Programming la fel și Scrumul, care spre deosebire de XP este o tehnică incrementală. Se lucrează în perioade de timp numite sprinturi și de fiecare dată adaug funcționalități în plus codului meu pe baza cerințelor clientului. Adică mai întâi voi începe cu funcționalitățile elementare și cele mai importante și apoi scriu funcționalități din ce în ce mai puțin importante. Pentru mai multe detalii legate de Scrum și Agile vă rog să căutați resurse suplimentare, nefiind scopul acestui tutorial.
Code Review înseamnă ca orice bucată de cod scrisă de mine să fie revizuită și de un alt coleg programator. Să fie revizuită nu neapărat ca și testată, ci acel coleg să citească totul și să spună că acel cod e lizibil, e curat și corespunde principiilor echipei sau principiilor Scrum.
Tot în Agile este întărită și tehnica numită Pair Programming sau programarea pe perechi. Asta înseamnă că programatorii lucrează în perechi de câte 2. De ce? Am un task complex, foarte dificil. Nu e niciun programator din echipă capabil să îl facă singur atunci poate e mai ok ca doi programatori din echipă să se uite pe task-ul respectiv și să încerce să îl facă împreună. Unde nu știe unul, poate știe celălalt, unde știe celălalt poate nu știe primul. Atunci când vorbim de task-uri complexe sau de pair programming de dragul de a evita code review, de obicei e vorba de doi programatori seniori sau cel puțin middle level și de obicei fac cu rândul. Adică întâi scrie primul cod și celălalt observă, apoi schimbă.
Mai există tehnică de Pair Programming folosită și pentru a educa sau învăța, a deprinde tehnici pentru programatorii juniori sau nou integrați în echipă. Aici într-adevăr problema e cu codul scris de ei pentru că ei nu vor fi încă pregătiți să scrie cod singuri, așa că de obicei îl vor asista doar pe programatorul senior în timp ce scrie cod, iar timpii vor fi oarecum disproporționați, nu neapărat egali.
Spuneam că vă dau și niște exemple de instrumente pe care le putem folosi pentru a ne asigura că acel cod sursă scris de noi e curat. Vreau să vă amintesc de IntelliJIDEA. IDE-ul sau mediul de dezvoltare de la cei care au produs și ReSharper-ul. Este pentru Java și conține foarte multe chestii de Clean Code și de validare automată a modului în care denumesc variabile, a modului în care scriu codul ș.a.m.d. La fel face și ReSharper-ul, care e un plugin pentru Visual Studio, scris de aceeași oameni. Din păcate e paid la fel ca și IntelliJ. Cred că există o variantă Community Edition care e free pentru ambele, dar varianta Premium e paid. Mai am apoi PMD, plugin pentru Eclipse, CheckStyle și FindBugs, la fel plugin pentru IDE-uri.
Spuneam că avem un bonus la sfârșit. Și anume, vreau să vă spun despre două reguli preluate din alte părți și aplicabile în programare. Una se numește „The Broken Window Principle” adică principiul ferestrei sparte. S-a dovedit practic că mașinile sau clădirile care au o fereastră spartă sunt mai vulnerabile la vandalism. Și o fereastră spartă duce de obicei la mai multe ferestre sparte care pe măsură ce timpul trece duc la o ruină. Același lucru este valabil și pentru codul nostru sursă. Azi fac abstracție de la o regulă de clean code, mâine fac abstracție de la alta și mă trezesc cu un cod scris cu picioarele căruia nu am ce să-i fac decât să îl scriu cap-coadă din nou.
Apoi mai este o regulă de bun simț numită Boy Scout Rule sau regula cercetașilor. Să lăsăm codul puțin mai curat decât l-am găsit. Adică, dacă văd că ceva nu e în regulă, poate e ok să mai corectez și din codul altuia, nu neapărat să scriu cod 100% corect.
Dacă doriți resurse suplimentare, vă recomand cartea „Clean Code: A Handbook of Agile Software Craftsmanship” a lui Robert C. Martin, cunoscut în comunitate drept Uncle Bob. O să găsiți și o serie de tutoriale de Clean Code în care el joacă rolul de Uncle Bob și îi explică nepoatei sale cum să scrie cod curat. Și tutorialul de pe Pluralsight, în care o să găsiți o parte dintre ideile prezentate astăzi, numit „Clean Code: Writing Code for Humans”.
O să închei cu singura metodă prin care poate fi măsurată calitatea codului și anume numărul de „What The Hell” / minute auzit la code review și cu citatul lui Martin Golding ”Să scrieți cod întotdeauna ca și cum colegul care se va ocupa de mentenanța lui e un psihopat violent care știe unde locuiți” 🙂
Cam asta am avut de spus. Dacă aveți întrebări sau comentarii vă rog să folosiți formularul de contact de pe site sau să comentați aici. Vă mulțumesc că ați avut răbdare să mă ascultați până la final și vă salut!
0 comentarii