Debugging: Găsirea soluției singur

Majoritatea începătorilor tratează un bug ca pe un zid. Se lovesc de el, se opresc și cer cuiva altcuiva să-l escaladeze pentru ei. Obiceiul care chiar construiește abilitate este diferit: înveți să tratezi un bug ca pe o întrebare cu un răspuns găsibil, și tu mergi să-l găsești înainte să mergi să ceri.

Citește mesajul de eroare ca și cum ar fi dovezi, nu zgomot

Stack trace-urile se sar peste constant pentru că arată terifiant. Dar ele de obicei îți spun exact unde și de ce s-a rupt ceva. Dacă obții TypeError: 'NoneType' object is not subscriptable în Python, asta nu-i o minciună aleatorie — înseamnă că o variabilă pe care te-ai așteptat să conțină o listă sau dict este de fapt None. Numărul liniei îți spune unde. Sarcina ta este să trasezi înapoi de la linia aia și să găsești unde valoarea ar fi trebuit să fie setată dar nu a fost.

Fă asta înainte de a cauta ceva online: citește ultima linie a trace-ului mai întâi, apoi mergi în sus. Ultima linie de obicei numește excepția actuală. Liniile de deasupra arată lanțul de apeluri care te-a dus acolo.

Reproduc-o intenționat

Dacă un bug apare doar uneori, tu nu-l înțelegi încă. Înainte de a atinge codul, încearcă să-l faci să se întâmple în mod fiabil. Schimbă o intrare o dată. Se blochează cu o listă goală dar nu cu una plină? Se blochează doar la al doilea apel al unei funcții, nu la primul? Un bug pe care-l poți reproduce la comandă este un bug care-i 80% rezolvat, pentru că acum poți testa dacă o reparație de fapt a funcționat în loc să ghicești.

Taie problema în jumătate, după aia din nou în jumătate

Binary search nu e doar pentru tablouri sortate — e cel mai rapid mod de a găsi cod stricat într-o funcție lungă sau pipeline. Comentează sau ocoleșteopțiunea a doua jumătate din logica ta și verifică dacă prima jumătate produce încă bug-ul. Dacă da, problema e în prima jumătate. Dacă nu, e în a doua. Repetă. Asta funcționează pentru un script de 200 de linii la fel cum funcționează pentru un pipeline de date cu mai multe etape unde verifici ieșiri la fiecare etapă cu print() sau df.head().

Asta e mai bun decât schimbarea liniilor la întâmplare și relansarea, ceea ce fac cele mai multe persoane sub presiune și risipește mult mai mult timp decât economisește.

Folosește debugger-ul în loc de print() când print() încetează să funcționeze

Declarațiile print() sunt bune pentru cazuri simple, dar o dată ce urmărești starea pe mai multe apeluri de funcție, un debugger real economisește timp real. În Python, aruncă import pdb; pdb.set_trace() chiar înainte de linia suspectă, rulează scriptul și obții un prompt în direct unde poți inspecta variabile, treci pe linie cu n și treci în apeluri de funcție cu s. Debugger-ul încorporat din VS Code face același lucru cu breakpoint-uri pe care le clichezi în loc să le tastezi. Oricum, scopul e același: observă starea actuală a programului tău în loc să ghicești ce probabil că e.

Izolează-o de restul proiectului tău

Dacă un bug se întâmplă în interior unei baze de cod mari, nu-l debuga în interiorul bazei de cod mari. Copiază funcția relevantă într-un fișier nou cu intrare falsă, minimală care declanșează aceeași defecțiune. Dacă bug-ul dispare, ceva despre contextul înconjurător — o variabilă globală, un import, stare veche — e adevărata cauză, și tocmai ai învățat ceva important. Dacă bug-ul persistă în izolare, tu acum ai un caz mic, partajabil, testabil, și ești mult mai aproape de reparația reală.

Verifică-ți presupunerile față de realitate, nu memorie

O proporție imensă din timp de debugging merge la presupuneri neîntrebate: