{"id":36115,"date":"2019-10-31T22:09:42","date_gmt":"2019-10-31T19:09:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete\/"},"modified":"2019-10-31T22:09:42","modified_gmt":"2019-10-31T19:09:42","slug":"ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/news\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","title":{"rendered":"Nu accepta\u021bi s\u0103 dezvolta\u021bi ceea ce nu \u00een\u021belege\u021bi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Nu
\n
\nDin \u00eenceputul anului 2018, ocup func\u021bia de lead\/\u0219ef\/dezvoltator principal \u00een echip\u0103 \u2014 numi\u021bi-o cum dori\u021bi, dar esen\u021ba este c\u0103 sunt complet responsabil pentru unul dintre module \u0219i pentru to\u021bi dezvoltatorii care lucreaz\u0103 la el. Aceast\u0103 pozi\u021bie \u00eemi ofer\u0103 o nou\u0103 perspectiv\u0103 asupra procesului de dezvoltare, deoarece sunt implicat \u00een mai multe proiecte \u0219i particip mai activ la luarea deciziilor. Recent, datorit\u0103 acestor dou\u0103 circumstan\u021be, am realizat brusc c\u00e2t de mult m\u0103sura \u00een\u021belegerii influen\u021beaz\u0103 codul \u0219i aplica\u021bia.<\/p>\n

G\u00e2ndul pe care vreau s\u0103-l exprim se reduce la faptul c\u0103 calitatea codului (\u0219i a produsului final) este str\u00e2ns legat\u0103 de c\u00e2t de con\u0219tien\u021bi sunt cei care proiecteaz\u0103 \u0219i scriu codul de ceea ce fac.<\/p>\n

Poate v\u0103 g\u00e2ndi\u021bi acum: \u201eMul\u021bumesc, c\u0103pitan. Desigur, ar fi bine s\u0103 \u00een\u021belegem ce scriem. Altfel, la fel de bine am putea angaja un grup de maimu\u021be ca s\u0103 loveasc\u0103 la \u00eent\u00e2mplare tastele \u0219i s\u0103 ne lini\u0219tim.\u201d \u0218i ave\u021bi perfect\u0103 dreptate. A\u0219adar, accept ca dat fiind c\u0103 \u00een\u021belege\u021bi c\u0103 a avea o viziune general\u0103 despre ceea ce face\u021bi este esen\u021bial. Acesta poate fi numit nivelul zero de \u00een\u021belegere, iar acesta nu \u00eel vom analiza \u00een detaliu. \u00cen detaliu ne vom ocupa de ceea ce trebuie s\u0103 \u00een\u021belegem \u0219i cum aceasta influen\u021beaz\u0103 deciziile pe care le lua\u021bi \u00een fiecare zi. Dac\u0103 a\u0219 fi \u0219tiut aceste lucruri dinainte, m-ar fi salvat de o mul\u021bime de timp pierdut \u0219i cod \u00eendoielnic.
\n<\/a><\/noindex>
\nDe\u0219i nu ve\u021bi vedea niciun r\u00e2nd de cod mai jos, consider totu\u0219i c\u0103 tot ceea ce s-a spus aici are o mare importan\u021b\u0103 pentru scrierea unui cod de calitate, expresiv. <\/p>\n

Primul nivel de \u00een\u021belegere: De ce nu func\u021bioneaz\u0103?<\/h4>\n

\nDe obicei, la acest nivel dezvoltatorii ajung \u00een cele mai timpurii etape ale carierei lor, uneori chiar f\u0103r\u0103 nicio ajutor din partea celor din jur \u2014 cel pu\u021bin, dup\u0103 observa\u021biile mele. Imagineaz\u0103-\u021bi c\u0103 ai primit un raport de bug: o func\u021bie din aplica\u021bie nu func\u021bioneaz\u0103, trebuie s\u0103 o repari. Ce vei face?<\/p>\n

Schema standard arat\u0103 astfel:<\/p>\n

    \n
  1. G\u0103se\u0219te fragmentul de cod care provoac\u0103 problema (cum se face acest lucru este un subiect separat, pe care \u00eel discut \u00een cartea mea despre codul \u00eenvechit)<\/li>\n
  2. F\u0103 modific\u0103ri \u00een acest fragment<\/li>\n
  3. Asigura\u021bi-v\u0103 c\u0103 bug-ul a fost corectat \u0219i c\u0103 nu au ap\u0103rut erori de regresie<\/li>\n<\/ol>\n

    \nAcum s\u0103 ne concentr\u0103m asupra celui de-al doilea punct \u2013 modificarea codului. Exist\u0103 dou\u0103 abord\u0103ri pentru acest proces. Prima: a \u00een\u021belege exact ce se \u00eent\u00e2mpl\u0103 \u00een codul curent, a identifica bug-ul \u0219i a-l corecta. A doua: a merge pe \u00eentuneric \u2013 s\u0103 adaugi, de exemplu, +1 \u00eentr-un operator condi\u021bional sau \u00eentr-un ciclu, s\u0103 vezi dac\u0103 func\u021bia a \u00eenceput s\u0103 func\u021bioneze \u00een scenariul dorit, apoi s\u0103 \u00eencerci \u0219i altceva, \u0219i tot a\u0219a la nesf\u00e2r\u0219it.<\/p>\n

    Corect este prima abordare. A\u0219a cum explic\u0103 \u00een cartea sa Code Complete Steve McConnell (pe care, de altfel, o recomand cu c\u0103ldur\u0103), de fiecare dat\u0103 c\u00e2nd facem o modificare \u00een cod, trebui s\u0103 fim capabili s\u0103 prezicem cu \u00eencredere cum va afecta aceast\u0103 modificare aplica\u021bia. \u00cemi amintesc o citat, dar dac\u0103 bug fix-ul nu func\u021bioneaz\u0103 a\u0219a cum te a\u0219tep\u021bi, ar trebui s\u0103 te \u00eengrijoreze foarte mult, trebuie s\u0103 pui la \u00eendoial\u0103 \u00eentregul t\u0103u plan de ac\u021biune.<\/p>\n

    Rezum\u00e2nd, pentru a realiza un bug fix de calitate, care s\u0103 nu afecteze negativ calitatea codului, este necesar s\u0103 \u00een\u021belegi at\u00e2t \u00eentreaga structur\u0103 a codului, c\u00e2t \u0219i sursa problemei specifice.<\/p>\n

    Al doilea nivel de \u00een\u021belegere: De ce func\u021bioneaz\u0103?<\/h4>\n

    \nAcest nivel este \u00een\u021beles mult mai pu\u021bin intuitiv dec\u00e2t precedentul. Eu, fiind un dezvoltator \u00eencep\u0103tor, l-am \u00eenv\u0103\u021bat de la \u0219eful meu \u0219i ulterior am explicat esen\u021ba acestui concept de nenum\u0103rate ori \u00eencep\u0103torilor.<\/p>\n

    De data aceasta, s\u0103 ne imagin\u0103m c\u0103 ai primit dou\u0103 rapoarte de bug-uri: primul se refer\u0103 la scenariul A, iar al doilea - la scenariul B. \u00cen ambele scenarii se \u00eent\u00e2mpl\u0103 ceva \u00een neregul\u0103. A\u0219adar, \u00eencepi mai \u00eent\u00e2i cu primul bug. Conduc\u00e2ndu-te dup\u0103 principiile pe care le-am derivat pentru primul nivel de \u00een\u021belegere, te aprofundezi \u00een codul relevant problemei, descoperi de ce acesta determin\u0103 aplica\u021bia s\u0103 se comporte astfel \u00een scenariul A \u0219i faci modific\u0103rile ra\u021bionale necesare, care ofer\u0103 exact rezultatul pe care l-ai a\u0219teptat. Totul decurge excelent.<\/p>\n

    Apoi treci la scenariul B. Repe\u021bi scenariul \u00een \u00eencercarea de a provoca eroarea, dar - surpriz\u0103! - acum totul func\u021bioneaz\u0103 a\u0219a cum trebuie. Pentru a-\u021bi confirma intui\u021bia, anulezi modific\u0103rile f\u0103cute \u00een timpul lucrului la eroarea A, iar bug-ul B revine din nou. Fixul t\u0103u a rezolvat ambele probleme. Ai avut noroc!<\/p>\n

    Nu v-a\u021bi a\u0219teptat deloc la asta. A\u021bi g\u0103sit o modalitate de a corecta eroarea din scenariul A \u0219i nu ave\u021bi idee de ce a func\u021bionat \u0219i pentru scenariul B. \u00cen aceast\u0103 etap\u0103, tenta\u021bia de a concluziona c\u0103 ambele sarcini au fost \u00eendeplinite cu succes este foarte mare. Este logic: p\u00e2n\u0103 la urm\u0103, scopul a fost s\u0103 elimina\u021bi erorile, nu-i a\u0219a? Dar munca nu este \u00eenc\u0103 terminat\u0103: trebuie s\u0103 \u00een\u021belege\u021bi de ce ac\u021biunile dumneavoastr\u0103 au corectat eroarea din scenariul B. De ce? Pentru c\u0103 exist\u0103 posibilitatea ca acesta s\u0103 func\u021bioneze pe principii gre\u0219ite, iar atunci va trebui s\u0103 c\u0103uta\u021bi o alt\u0103 solu\u021bie. Iat\u0103 c\u00e2teva exemple de astfel de cazuri:<\/p>\n