Practicile în domeniu, la corporații, nu îți permit să transporți cod în sistemul productiv fără să testezi.
Glumesc, plm ,normal că-ți permit, cum credeți că sunt așa de proaste softurile pe care le folosiți.
Dar nu îți permit să trimiți cod înspre productiv fără să-ți facă cineva review la code-ul ăla.
Și sunt niște criterii de performanță pe care trebuie să le îndeplinească codul ăla, printre alte criterii.
În lumea mea, unul din criteriile ălea sunt să nu ai ”select în loop”. Nu o să pierd prea mult să explic asta, pe scurt, într-o buclă de execuție în care procesezi, să zicem , toate înregistrărule dintr-o tabelă pe care ai le-ai selectat cumva anterior, nu ai voie să scrii cod care să facă altă selecție.
Adică la fiecare iterație în buclă să faci tu un select. Imaginează-ți că ai o tabelă cu 100,000 de clienți și vrei pentru fiecare CNP-ul dintr-o tabelă de CNP-uri. Nu e cea mai bună idee să buclezi prin toți clienții ăia și să execuți de fiecare dată ”selectează-mi CNP-ul pentru clientul de la linia asta din tabela de CNP-uri” că presupun că e intuitiv că nu-i cea mai strălucită idee să execuți 100,000 de query-uri, față de să zicem un query în care specifici toți clienții pentru care vrei CNP-urile.
Dar e mai comod să scrii logica așa, cu select în loop, așa că de ce nu.
Și de aia stă code reviewer-ul cu bâta, la vânat de juniori.
Problema e când ăla are doar lista de verificări și nu știe să te îndrume mai departe.
Am descoperit o dată o greșeală când pentru o tabelă se procesa doar prima intrare. Am observat că era înlocuit ”loop”-ul ( adică ciclarea prin toată tabela ) cu o citire a primei linii din tabelă.
Le-am deschis alora un defect și le-am spus ce să schimbe. A schimbat tipul care a scris codul inițial. Lux.
Apoi am scris eu o specificație, și pentru că era o situație similară m-am gândit să-i explic omului, vezi că aici avem nevoie de o buclare, nu de doar procesarea unei singure intrări, că na, să fie clar.
A zis că da, da – când am testat, se procesa o singură intrare. Bănuiam de ce. Și colegul care se ocupa de asta i-a zis , băi, dar înlocuiește, ”PROCESEAZĂ PRIMA INTRARE ” cu ”CICLEAZĂ ” ( nu vă scriu acuma codul exact).
Iar developericiul cică : ”Păi a fost așa , dar nu s-a aprobat la code review, că era un select în bucla aia. ”
Cristoaseee!
Și zice: Ce-ar fi dacă citesc înainte de ”loop” TOATE intrările din tabela cu pricina?
N-am mai zis nimic, s-a ocupat colegul meu că e mai tânăr și mai are răbdare, cred.
Dar mă gândesc că toată schema asta cu ”code review” e ca să nu scrii căcaturi, însă când omul nu înțelege nimic din nimic oricum numai căcaturi ajung. A cui e vina?
frumos. CR e bun, dar trebuie ambele parti sa inteleaga codu.
Ca daca ala de face review zice “nu e bine aici” tu ii raspunzi cu “ba e!”
Cu excepția faptului că nu e. Dar când ești developer mai juni, nu știi de ce nu e bine și n-au nici toți coaie să susțină prostii, cum aveam eu, de pildă când eram junior. Nu aia e problema. Sigur, ar trebui și nu știu, în cazul ăsta, nici măcar dacă reviewer-ul înțelege codul, dar aș putea presupune că da, că problema prevalentă e alta. Anume că reviewerului nu-i pasă de soluție, ci doar de activitatea lui de code review – să bifeze checurile acolo. Nu-i pasă nici de developer, în cazul ăsta cu atât mai mult, că reviewerul e… Read more »