ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 150
Numărul 149 Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 65
Abonament PDF

Suntem ceea ce scriem

Iulia Sălăgean
Software Engineer @ Flow Traders



PROGRAMARE


Perioada în care un proiect era rezultatul muncii unui singur om a trecut. Trebuie să colaborăm, să lucrăm în echipe formate din oameni cu diverse aptitudini nu întotdeauna tehnice și să învățăm să împărtășim idei și soluții, pentru a putea avea succes ca programatori.

Conform spuselor lui Tudor Gîrba, ca programatori, petrecem jumătate din timpul nostru la birou citind cod. De ce citim codul? Deoarece dimensiunea proiectelor e în creștere în fiecare zi, și cu fiecare sarcină pe care trebuie să o executăm, vom citi cod mai mult decât vom scrie.

Acest articol este un lobby pentru îmbunătățirea codului, cu scopul de a ne face viața mai ușoară mai târziu și pentru a ne asigura că rezultatul muncii noastre este unul cât mai bun.

Una din definiții este: "Calitatea este un termen subiectiv pentru că fiecare persoană sau sector are propria sa definiție. Exemple ale acestor definiții pot fi: "Satisfacerea cerințelor și așteptărilor asupra cărora s-a căzut de-acord" și "Urmărirea soluțiilor optime care să contribuie la succese confirmate, asumarea responsabilităților". În utilizarea sa din tehnică, calitatea poate avea două semnificații:

  1. caracteristicile unui produs sau serviciu care se referă la abilitatea acestuia de a satisface necesități exprimate sau implicite;

  2. un produs sau un serviciu fără deficiențe

https://i2.wp.com/thepissedoffcustomer.com/wp-content/uploads/2016/02/THE-DEFINITION-OF-ABOVE-AND-BEYOND-CUSTOMER-SERVICE.jpg

Intenția acestui articol este de a convinge că este mai bine să alegem abordarea optimă în muncă noastră, mai degrabă decât să urmărim doar îndeplinirea cerințelor. În acest caz, vorbesc despre codul pe care îl scriem și despre îmbunătățirea continuă în acest domeniu, deoarece nu numai că ne va ajuta să creștem profesional, dar vom adăuga și mai multă valoare muncii pe care o producem.

Cum măsurăm

Ce face o bucată de cod de bună calitate?

Mă voi concentra doar asupra unora dintre măsurătorile care definesc calitatea codului, deoarece lista este lungă și în multe proiecte suntem interesați doar de îmbunătățirea câtorva dintre ele. De exemplu, într-o aplicație pe care o dorim cât mai rapidă posibil, s-ar putea să nu ne pese de readability. Totuși, acest aspect ne va interesa atunci când vom avea o aplicație foarte mare, cu o mulțime de funcționalități.

http://4.bp.blogspot.com/-y_lWkRMgj14/TbFh9Z-QVvI/AAAAAAAAA20/XX9gGa74ZQ8/s640/wtf.png

Mai jos, vă expunem câteva din mecanismele care își aduc contribuția la realizarea unui cod de calitate:

Respectarea cerințelor

Un software este acolo pentru a rezolva unele probleme, pentru a nu provoca mai multe probleme. Deci, asigurați-vă că înțelegeți cerințele atunci când începeți să lucrați. Atât funcționale, cât și nefuncționale.

Verificați frecvent pentru a vedea că mergeți în direcția cea bună. În funcție de stilul de lucru adoptat în proiectul pe care lucrați, demo-urile dese ale produsului și solicitarea de feedback vă pot menține pe drumul cel bun și pot reduce costurile de a face schimbări majore mai târziu.

Readability

Codul trebuie să fie lizibil. Acest lucru devine tot mai important, deoarece bucățile de cod pe care le scriem sau cantitatea de linii de cod la care suntem expuși ca programatori crește în fiecare zi. Dacă acest aspect este asigurat, codul de lectură va fi mai ușor și va face că fiecăruia să îi meargă mai bine.

Teoria fundamentală în acest domeniu desemnează: "Codul ar trebui scris pentru a minimaliza timpul necesar pentru ca altcineva să îl înțeleagă." Țineți minte că acel "altcineva" poate vei fi chiar tu.

Gândiți-vă doar de câte ori a trebuit să remediați o eroare la două luni, după ce ați scris codul și a trebuit să navigați prin cod pentru a găsi locația exactă care se ocupă de logica pe care doriți să o schimbați acum. Vă ajută să vă documentați bine munca, să numiți corect variabilele cu care lucrați și faceți o separare clară a logicii în proiect.

Maintainability

Când vorbim despre mentenabilitate, trebuie să ținem cont de durata de viață a produsului. În timp ce unele aplicații sunt rescrise la fiecare trei sau patru ani pentru a face față progresului tehnologic, altele vor fi acolo timp de 20 de ani sau mai mult. Este adevărat că nimeni nu vrea să atingă acești monștri, dar uneori trebuie să ne murdărim mai întâi pentru a putea străluci.

Așadar, trebuie să codăm responsabil, ținând cont și de acțiunile care vor fi necesare mai târziu pentru a face orice fel de schimbări.

Refactorizarea este procesul de rescriere a unor părți ale codului, pentru a o aduce la curent cu cea mai recentă arhitectură sau cu cele mai recente tehnologii sau pur și simplu pentru a reîmprospăta codul vechi. Este o modalitate de actualizare a codului. Faceți-vă timp pentru a re-factoriza codul, deoarece poate aduce beneficii multiple atât pentru proiectul care este revigorat, cât și pentru programatorii implicați, care pot învăța multe în acest proces.

Și amintiți-vă:

https://i.stack.imgur.com/TZrwp.jpg

Există, desigur, alte aspecte care contează în scrierea codului, dar scopul acestui articol este de a vă convinge că trebuie să avem grijă de ceea ce scriem, și nu să prezinte exhaustiv practicile bune și rele în scrierea codului. Acestea fiind spuse, această listă se va opri aici.

Cum putem să ne îmbunătățim calitatea codului?

http://www.akaita.com/media/xkcd-code-quality-2x.png

Există pași mici pe care îi putem face în fiecare zi pentru a ne îmbunătăți performanțele în ceea ce privește codul scris.

Unele pot fi luate în mod individual, însă e mai eficient să cerem ajutor, deoarece feedbackul de la alții poate oferi sugestii mai bune asupra aspectelor pe care trebuie să vă concentrați pentru îmbunătățire. De asemenea, alții pot vedea și citi codul în mod obiectiv. Mai jos vă voi sugera câteva, pe care le-am încercat în compania în care lucrez și au dat rezultate pozitive.

Coding standards

Toate limbile de programare au standarde de scriere a codului. Ele acoperă o mulțime de aspecte, de la denumirea metodelor și a variabilelor la utilizarea bibliotecilor externe și la aranjarea codului în pagină. Scopul lor este de a unifica modul în care scriem cod, ceea ce ajută la colaborarea dintre colegi și facilitează ajustarea la un nou proiect. Dar standardele sunt valoroase doar dacă sunt urmate.

Standardele nu trebuie neapărat să fie valabile pentru toți programatorii care utilizează aceeași limbaj, nu trebuie să fie valabile nici pentru toți programatorii din companie, dar este foarte util să existe aceleași standarde pe tot parcursul unui proiect anume. Acestea vă vor face viața mai ușoară, căci dacă întregul proiect este scris în același stil, citirea și înțelegerea lui vor fi facilitate.

Puteți adopta standarde de la o companie mare sau puteți decide singuri, în interiorul grupului ce standarde să folosiți, dar luarea deciziei și, mai important, urmarea standardelor, este un prim pas în ajustarea la nouă paradigmă socială în care trebuie să programăm în zilele noastre.

Code reviews

Code review-ul poate fi un proces formal, când unul sau mai mulți programatori trebuie să verifice modificările implementate de un coleg pentru un anumit ticket, înainte ca aceste modificări să ajungă în branchul principal, dar poate fi făcut și într-un mod informal.

În multe echipe acest proces este unul standardizat, în altele nu există code review-uri.

Oricare este cazul, poate fi o bună ocazie de a învăța și de a îmbunătăți codul produs. Pentru a fi de folos, atitudinea față de code review-uri trebuie să se transforme de la "obligatoriu și enervant" la "util și interactiv". Chiar dacă nu există un proces formal de revizuire a codului, putem cere întotdeauna colegilor noștri să arunce o privire și să ne dea sugestie despre ce am putea îmbunătăți la stilul nostru.

În cazul în care programatorul și reviewerul nu sunt foarte atașați de munca lor, aceasta va duce la o experiență de învățare pentru ambele părți, deoarece observarea mai multor alternative și raționamentul din spatele diferitelor soluții poate mări experiența atât a reviewerului, cât și a programatorului care scrie codul .

Este un proces de care fiecare poate beneficia și din care putem învăța, atâta timp cât suntem deschiși la feedback.

Instrumente statice de analiză

Aceste aplicații vă ajută să observați eventualele probleme pe care le-ați putea omite, puteți monitoriza codul pentru a vedea dacă acesta respectă standardele, dacă este prea complex sau câte cod duplicat există.

Unelte precum Sonar, Coverity, Checkstyle și altele ajută la păstrarea codului ușor de citit și de întreținut. Unele aplicații sunt plătite, dar există și altele care sunt gratuite și pot fi utilizate de oricine pentru a-și analiza propriul cod și pentru a-l îmbunătăți.

Nu vă speriați în timp ce are loc prima analiză, ați putea avea multe probleme în codul vostru, chiar dacă ați crezut că acesta este la cele mai înalte standarde de calitate. Încercați să verificați și validați fiecare dintre potențialele probleme și întrebați-vă cum puteți să o faceți mai bine.

Rezultatul unei astfel de analize poate fi începutul unui proces de refactorizare, deoarece prezintă deficiențe în implementarea actuală.

Teste

De ce testarea codului ajută la îmbunătățirea acestuia? Cred că este clar. Cu toate acestea, există mai multe modalități de testare.

Acest paragraf se referă la întregul set de teste efectuate pe un anumit proiect.

Cu cât testele sunt mai extinse și mai variate, cu atât rezultatul este mai bun. Unit testele sunt doar o mică bucată în puzzle. Pe lângă unit teste trebuie să adăugați și alte teste funcționale și nefuncționale. Încercați să vă testați muncă cât mai bine, atât cu unit teste, cât și cu teste automate, precum și în situația reală, dacă este posibil, încercând diverse scenarii. Încercați să vă puneți în locul utilizatorilor și să priviți din această perspectivă.

Cu excepția faptului că puteți găsi buguri noi înainte de oricine altcineva, acest lucru va crește încrederea în cod.

Concluzie

Imaginați-vă cum ar fi să intrați într-o bancă sau o instituție publică și să vedeți funcționarul îmbrăcat într-un costum murdar sau cu părul nearanjat? Sau ce ai spune unui bancher care tocmai ți-a spus că ți-a pierdut unele documente și acum nu mai găsește?

Într-un fel codul pe care îl scriem este o parte importantă a proiecției pe care o avem către exterior. Ar trebui să avem grijă de cod, deoarece este cartea noastră de vizită, unul dintre lucrurile care ne reprezintă și uneori este exact ceea ce va crea prima impresie.

Este la latitudinea fiecăruia dintre noi să hotărâm ceea ce dorim să arătăm. Un cod care funcționează sau este numai suficient de bun ar putea să nu fie ceea ce dorim ca alții să gândească despre noi.

Suntem ceea ce scriem, deci este timpul să îmbunătățim și codul.

Referințe

  1. Tudor Gîrba - un avocat al transformării mediului de lucru în domeniul IT

  2. Conform American Society for Quality

  3. 'The Art of Readable Code - Simple and Practical Techniques for Writing Better Code' - Dustin Boswell si Trevor Foucher

  4. https://google.github.io/styleguide/javaguide.html

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects