Întrebări și răspunsuri
Cum verifici calitatea codului primit, fără să fii programator
Nu trebuie să citești codul ca să-ți dai seama dacă e îngrijit — trebuie doar să știi ce dovezi să ceri.
Codul nu se citește de către client, dar se verifică. Chiar dacă n-ai scris niciodată o linie de program, poți afla destul de precis dacă software-ul pentru care plătești e construit îngrijit sau ținut în picioare cu scotch, folosind dovezi pe care o echipă serioasă le arată în zece minute. Prima categorie ține de istoric: cine a scris, când, în ce ordine, cu ce explicații lăsate în urmă. A doua ține de reproductibilitate: aplicația trebuie să pornească de la zero pe un calculator nou, urmând instrucțiuni scrise, fără intervenția eroică a unui singur om. A treia ține de plasa de siguranță: există verificări automate care se execută înainte de fiecare livrare, măcar pe fluxurile care aduc bani. A patra ține de igienă: biblioteci actualizate, parole care nu stau ascunse în fișiere de program, un stil unitar impus de unelte, nu de bunăvoință. Răspunsul onest e că nu orice proiect are nevoie de toate patru la nivel maxim — un prototip de trei săptămâni și o platformă care ține evidența a douăzeci de magazine se judecă diferit. Diferența dintre compromis asumat și neglijență se vede însă exact în felul în care furnizorul îți răspunde la aceste întrebări: calm și cu exemple, sau defensiv și cu generalități.
Hai să vorbim despre proiectul tău
Scrie-ne pe WhatsApp sau trimite un email — vorbești direct cu un programator.
office@northdan.com · +40 752 070 247
Pe scurt
Istoricul de versiuni, citit ca un jurnal
Cere acces de vizualizare la depozitul de cod. Modificări mici și dese, cu explicații scrise, arată o echipă disciplinată; trei încărcări uriașe făcute în ultima săptămână arată altceva.
Testul pornirii de la zero
Un dezvoltator nou trebuie să poată instala aplicația pe calculatorul lui urmând documentația, în câteva ore. Dacă reușește doar un anumit om din echipă, ai deja o problemă de continuitate.
Verificări automate pe fluxurile cu bani
Nu ai nevoie de acoperire totală, ci de teste automate pe comandă, plată și facturare. Întreabă câte există și când rulează; răspunsul „testăm manual” e un cost amânat, nu o economie.
Igiena dependențelor și a secretelor
Bibliotecile folosite trebuie să fie întreținute și aduse la zi, iar parolele și cheile de acces nu au ce căuta în codul sursă. Ambele se verifică rapid, cu unelte gratuite și publice.
Cinci întrebări la care un furnizor corect răspunde pe loc
Întâi: unde stă codul și pot primi acces de vizualizare acum, în timpul discuției? Al doilea: îmi arătați lista ultimelor cincizeci de modificări, cu explicațiile lor? Al treilea: câte verificări automate rulează la fiecare livrare și ce acoperă ele? Al patrulea: dacă mâine aduc alt dezvoltator, în cât timp intră în proiect și pe ce documentație? Al cincilea: ce părți din cod ați scrie altfel dacă ați lua-o de la capăt și de ce s-au făcut așa? Ultima întrebare e cea mai utilă dintre toate, pentru că un profesionist are întotdeauna un răspuns concret la ea.
Contează la fel de mult ce se întâmplă când răspunsurile lipsesc. Refuzul accesului la cod invocând motive de securitate e un semnal, nu o explicație — accesul de vizualizare pentru proprietarul proiectului e o setare de un minut. Fraza „e prea tehnic ca să vă explicăm” înseamnă, în majoritatea cazurilor, că nu există nimic de arătat. Un furnizor care lucrează curat nu are de ce să evite conversația: îngrijirea codului e chiar argumentul lui de vânzare pentru următorul proiect.
Când merită plătit un audit extern
Evaluarea plătită a codului are sens în patru momente: înainte să preiei un proiect construit de altcineva, înainte să decizi între reparare și rescriere, înainte să cumperi o firmă cu tot cu software-ul ei și atunci când costurile de întreținere cresc fără explicație. În rest, banii sunt mai bine investiți în munca propriu-zisă. Ca reper orientativ de piață, o evaluare pe un site sau o aplicație mică pornește de la câteva sute de euro, iar pe platforme mari cu integrări ajunge la câteva mii; cere întotdeauna ca livrabilul să fie un raport cu probleme ordonate după risc și cu efort estimat, nu o listă de nemulțumiri.
O precauție necesară: evaluarea făcută gratuit de firma care vrea contractul următor nu e un audit, e o ofertă. Nu înseamnă că e falsă, dar are un interes încorporat, iar concluzia ei tinde suspect de des spre rescrierea completă. Dacă vrei o părere independentă, plătește-o și cere-i explicit autorului să spună și ce e bine făcut în proiectul actual. Un raport care nu conține nimic pozitiv despre o aplicație care funcționează în producție de doi ani spune ceva despre cine l-a scris.
Întrebări frecvente
Nu am cum să înțeleg codul. Ce verific de fapt?
Verifici urmele lăsate de felul în care s-a lucrat, nu programul în sine: istoricul modificărilor, documentația de instalare, existența verificărilor automate, actualizarea bibliotecilor. Toate patru sunt vizibile fără cunoștințe de programare și spun despre disciplina echipei mai mult decât orice demonstrație frumoasă a aplicației.
Furnizorul refuză să-mi dea acces la depozitul de cod. E normal?
În timpul dezvoltării, un acces limitat la vizualizare e rezonabil și se acordă în câteva minute; refuzul total nu e o practică de securitate, ci o pârghie comercială. Dacă în contract există clauză de predare a codului, cere-o în scris și stabilește un termen. Dacă nu există, ai aflat ce clauză îți lipsește la următoarea semnătură.
Codul neîngrijit înseamnă automat că firma e slabă?
Nu automat. Un prototip făcut repede, cu scurtături asumate și notate ca datorie tehnică, e o decizie legitimă de business. Problema apare când scurtăturile nu sunt nici notate, nici recunoscute, iar echipa le prezintă drept arhitectură. Întrebarea care separă cele două situații: îmi arătați lista lucrurilor pe care le-ați lăsat de reparat mai târziu?
Ce se întâmplă dacă evaluarea iese prost?
Rareori urmează rescrierea totală. De regulă rezultă un plan pe trei-șase luni: se rezolvă întâi riscurile de securitate și punctele care opresc afacerea, apoi se adaugă verificări automate pe fluxurile critice, apoi se curăță treptat restul, în paralel cu dezvoltarea normală. Rescrierea rămâne ultima opțiune, nu prima reacție.
Pagini similare
Resurse conexe
Hai să vorbim despre proiectul tău
Scrie-ne pe WhatsApp sau trimite un email — vorbești direct cu un programator.
office@northdan.com · +40 752 070 247