Folosiți debugger? (dacă nu, ar trebui)

@Work Tools of Trade
1

Știu că debugger-ul este ceva cât se poate de comun în limbajele compilate, deci discuția este mai mult pentru restul: PHP, JS, Python etc.

Unul dintre marile mele regrete profesionale este că am avut nevoie de aprox 10 ani până am început să folosesc cu adevărat debugger.

Și mi-am dat seama că asta din cauza editorului: știam despre xdebug, dar de fiecare dată când încercam să-l setez (în sublime) era hit & miss, de multe ori se întâmpla să nu mai meargă între două request-uri consecutive. În naivitatea mea, am crezut că debuggerul este chiar atât de unreliable, deci mai bine var_dump()…

Apoi am încercat prea-lăudatul VSC, unde la fel, uneori nu se activa xdebug, alteori mergea…

Apoi am fost forțat să folosesc prea-lăudatul PHP Storm. Proiect legacy mare, era imposibil să citesc codul. Și am zis: hei, dacă tot încerc Storm, hai să setez și debugger. Și… șoc: mergea. De. Fiecare. Dată.

Din păcate, doar în PHP, în JS (în browser) este prea frustrant, pentru că face step in biblioteci. Când am scris[1] Node, tot cu debugger am scris. Când am scris Python, primul lucru pe care l-am făcut, înainte să fac orice altceva, a fost să setez debugger-ul :sweat_smile:

Mi se pare un tool MULT prea important și prea des trecut cu vederea. Zic asta pentru că majoritatea celor pe care i-am întrebat au ridicat din umeri, că ei se descurcă cu var_dump() sau print_r().

Faptul că poți prinde tot felul de edge-case-uri sau că poți vedea un trace al metodei curente este incredibil de util.

Așadar: folosiți? Dacă nu, de ce nu?

  1. „Scris” e un mod de a spune; de fapt era mai mult citit cod, mici bug fix-uri etc. ↩︎

4 Likes
2

Da folosesc.

Este ceva ce ar trebui invatat inca de la facultate. Debugger ca si tool plus skill-ul de a face debug.

O sa ma opresc aici pt ca nu te intereseaza de alte lumi (java, C#). Eu l-am folosit si in js (node + vs code si browser) si nu am avut probleme cu el. Asta ca sa nu mai zic, ca ai si optiuni cum ar fi, evaluarea unei bucati de cod, breakpoint-uri conditionale etc.

In firefox. de exemplu se pune usor

image
image2559×1164 217 KB

2 Likes
3

Am lucrat intr-o firma care avea si departament de .NET si PHP. Fiind in .NET i-am intrebat daca folosesc debugger, au zis ca nu, si ma minunam cum pot lucra astfel, am incercat sa ii conving dar nu puteam sa ii indrum, fiindca era mult mai complicat ca in Visual Studio.

Mai tarziu am setat ca si hobby, debugger PHP, Visual Studio Code cu xdebug si mi-a mers din prima cu un tutorial de pe net.

Mi se pare ciudat ca in liceu, timp de patru ani, habar nu aveam de debug si nu vazusem la nimeni desi Turbo Pascal avea.

La facultate am vazut la un coleg in Java si m-am molipsit.

4
5

eu nu folosesc (desi in liceu foloseam pentru turbo pascal :slight_smile: ).
nu folosesc pentru ca asa m-am obisnuit si pentru ca nu am avut situatie pe care sa nu o pot descurca (intr-un fel sau in altul).
pentru drupal foloseam modulul dev care ajuta destul de bine, wordpress probabil ca nu am scris suficient de complex, pentru cod custom php folosesc destul de intens loggingul in db (in faza dev) si depistez repede ce nu merge “as expected”, iar pt js… ma enervez cu console.log :slight_smile:

daca tot ai ridicat problema… poate ne spui si despre situatii concrete in care a facut diferenta semnificativa (altfel, obisnuinta mea cantareste greu).

6

La liceu foloseam depanatorul de la Pascal tot timpul. De fapt profesoara știa mai bine partea de depanare decât restul lecțiilor. E foarte bizar în liceu să nu lucrezi pas cu pas.

1 Like
7

Dacă trebuie folosesc. Pe vremea cînd am început un job în care se folosea Perl/mod-perl ca să înțeleg cum funcționează lucrurile rulam Apache în mod debug și mergeam pas cu pas în mod text/linie de comanda. F util să înțelegi un cod nou.

1 Like
8

Chiar zilele trecute am descoperit că hook-ul woocommerce_new_order_item face trigger de două ori: prima dataă cu WC_Order_Item_Product a doua oară cu WC_Order_Item_Coupon. Să zicem că asta o aflam ușor cu un var_dump(), dar pentru asta ar fi trebuit să refac comenzi de câteva ori până să prind problema.

Cazuri de care mă lovesc frecvent:

  • hook-uri chemate aiurea;
  • câte vreun loop razna în care ceva crapă la a N-a iterație;
  • inspect pentru parametri înainte să apelez ceva, apoi resume la execuție
  • etc

Cel mai util este însă atunci când vrei să descoperi/urmărești execuția unui cod nou.

Evident, poți rezista foarte bine și fără debugger, doar cu var_dump, după cum bine ai zis:

dar descoperi că ajungi să scrii logică doar pentru a ajunge la un edge case, pe care altfel l-ai prinde cu un click :slight_smile:

4 Likes
9

Profesoara cu care faceam orele teoretice in liceu era ok, cea cu care faceam laborator era praf, dadea doar date de intrare, iesire pentru program, nici la facultate nu a stat un prof sa faca debug cu tine, dar am facut debug cat am lucrat de mi-a iesit pe ochii, oricum un skill foarte important.

Un feature util in Visual Studio pentru debug, poate si in alte medii, este sa se opreasca la linia de cod unde apare o exceptie.

10

Obligatoriu parerea lui Torvalds asupra subiectului cu care tind sa fiu de acord pana la un punct:

I don’t like debuggers - Linus Torvalds

Problema mare pe care o vad eu este ca folosirea prea mult a debugger-ului cauzeaza chestia numita la noi cu drag “ochelari de cal”. Da, faci codul acela sa mearga, dar daca ai avut nevoie de un debugger ca sa-l intelegi si sa-ti rezolvi problema poate ar trebui sa-ti refactoruiesti codul. Practic te obisnuiesti sa rezolvi local problema, dar nu vezi imaginea de ansamblu.

Unde mi se pare relativ util este atunci cand nu prea stii codebase-ul si folosesti debuggerul ca sa te familiarizezi cu proiectul. Dar si acolo, parca e mai rapid sa citesti codul.

Unde mi se pare cel mai util este la probleme legate de memorie. Acolo straluceste un debugger cu adevarat. Sa vezi in hex memoria, sa vezi ca intre X si Y memoria aia a fost afectata de alt thread, etc.

1 Like
11

In JS poti seta debug in doua. feluri:

  1. Din browser la sources
  2. Din IDE/VSCode…

Problema cea mai mare e ca intra in cod care nu e relevant, dar se poate rezolva cu putina chinuiala:
Cand intra intr-un fisier care nu te intereseaza, dai add script to ignore list pe fisier. Cand ai o linie dupa breakpoint in care intra si nu vrei (preferabil ceva functie), ii dai Never pause here.

image
image805×318 47.4 KB

12

N-am reușit vreodatăsă rulez așa :frowning:

Exact, ăsta e și motivul pentru care în JS prefer console.log în 90% din cazuri.

13

Da, e complicat de setat sa faci debug din IDE intr-o aplicatie mai complexa. (trebuie configurat webpack sau ce folosesti corect cu stopOnEntry, host si port corect, path la src si sourcemaps…)

1 Like
14

Pt. JS/TS land devtools mi se pare must daca te consideri “senior developer”.

Setup pt. built-in VSCode debugger e do-able, e nevoie sa configurezi .vscode/launch.json, si in unele cazuri sa adaugi si un task.json, depinde de structura proiectului:

Useful tips for devtools:

3 Likes
15

Eu iti garantez ca nu o sa setezi cu tutorialele alea nici un proiect cu TypeScript/ceva putin mai avansat sau e total inutil fiindca ai zeci de librarii prin care trece codul tau.

Inca n-am vazut pe nimeni in 5 ani sa foloseasca direct IDE-ul pentru debug, doar sources din browser. (pe care il folosesc si eu)

Am incercat sa setez IDE-ul dar ceva problema mereu era cu webpack, in schimb functioneaza ok pentru teste/node.

16

Daca poti face debugging din “sources din browser”, poti face debugging si din vscode. Daca ai nevoie de vre-un setup pt. ceva mai dificil posteaza pe forum, da-mi @ si te ajut.

1 Like
17

Poti daca ai JS, daca ai TypeScript si mai multe proiecte se complica mult lucrurile. De obicei e atat de complicat incat nimeni nu se complica sa il seteze.

18

pentru php, am descoperit xdebug acu cca 6-7 ani si de atunci nu mai pot fara el.
pentru js, urasc debuggerul din browser. storm-ul stie sa faca debug direct din ide, dar din pacate pt vue nu exista nici o solutie sa faci debuggind din ide. doar din browser.
cica mai nou se poate si pt vue.

19

Un thread related:

20

Folosesc ocazional pentru debugging și-mi face viața mai ușoară.

Am început cu debuggerul din Turbo Pascal în liceu, apoi m-am mutat pe web (PHP și JS) și n-am mai folosit multă vreme. În mare parte că nu era suportat de editor (PN2) sau n-am reușit niciodată să-l configurez (Komodo Edit). Când mi-am schimbat jobul în 2012 am început să folosesc PhpStorm și brusc xdebug-ul mergea aproape out-of-the-box. De atunci îl am tot timpul setat aproape, dar îl folosesc destul de rar când nu reușesc să-i dau de cap altfel. Când lucrez în Java e un must, mai ales când lucrez pe codul altora, mă ajută să mă prind mai repede de ce se întâmplă pe acolo.

PS: Derick Rethans, cel care menține xdebug se plânge că îi este greu să se mai ocupe de proiect dat fiind că nivelul de sponsorizări e la 34% din ce și-ar dori. Dacă folosiți xdebug, luați în considerare să-l sponsorizați. Eu fac asta deși abia mă mai ating de PHP în ziua de azi. Mi-ar părea rău să dispară. Derick este foarte activ în comunitatea PHP. Ocazional face podcasturi și este contributor activ la proiectul PHP (este code owner pe modul de date)

4 Likes