Cel mai trist lucru din viața unui programator: bugurile. Culmea este faptul că acestea sunt create tot de el. Fiecare programator, ar vrea să dezvolte numai feature-uri. Nimănui nu îi place să investigheze un bug sau să ofere mentenanță unei aplicații. Toate lumea vrea să dezvolte ceva de la zero!
Într-adevăr, cu cât ai un test coverage mai mare, cu atât vei sta mai bine și vei avea mai puține buguri. Dar chiar dacă test coverage-ul este de 99%, tot există riscul de avea un bug. Test coverage-ul de 100% este aproape imposibil în viața reală. În plus, ca să investești atât de mult timp în dezvoltarea testelor, multe firme preferă să renunțe la acestea și să testeze parțial și manual. Un lucru care nu ar trebui să ne mai întâmple, dar din rațiuni de cost reduction, se mai întâmplă în zilele noastre.
Să revenim la subiectul acestui articol. Ce ne facem cu bugurile? Păi, ca și programatori, trebuie să le fixăm. Până la urmă noi suntem cei care le-am creat, noi suntem cei care ar trebui să le identificăm și să le fixăm. Așa că, în articolul de față, mi-am propus să evidențiez care sunt principalii pași pe care trebuie să îi urmărim pentru a putea realiza acest lucru.
Pasul 1: În ziua de astăzi, datorită unui chain masiv de microservicii, nu se poate ști de la bun început ce componentă din acest lanț generează problema. Așă că primul pas este să înțelegem bugul și să încercăm să îl localizăm. Să încercăm să observăm ce microserviciu generează problema respectivă.
În ajutorul tău, vor sări jurnalele aplicațiilor pe care le-ai scris sau nu. Cu cât ai mai multe informații, cu atât vei descoperi mai repede ce componentă din lanț raportează defectul tău. Așa că, ai grijă să ai toate logurile necesare raportate în componenta ta!
Pasul 2: În momentul localizării, următorul pas este reproducerea lui într-un mediu de non-prod. În acest sens, va trebui să simulezi acțiunea care a generat acest issue. O dată ce ai reușit reproducerea problemei, poți trece la următorul pas. Dar, de multe lucruri problema nu se reproduce ușor în non-prod. Cu alte cuvinte, dacă este un issue de sincronizare, generat de un environment multithreading, va trebui să te chinui puțin să înțelegi de unde vine problema, pentru a o reproduce. Un articol interesant despre acest tip de debugging îl găsiți aici.
Pasul 3: Să spunem că ai reușit să reproduci problema pe non-prod, dar încă nu știi de ce apare. Cel mai simplu acum este să faci un remote debugging. În acest fel poți folosi noțiunea de breakpoints pentru a opri execuția flow-ului tău în orice punct dorești. În acest moment, vei analiza codul și pașii de execuție. Vei înțelege foarte clar comportamentului codului scris de tine sau de colegul de echipă.
Pasul 4: Ai identificat problema, acum o cunoști, deci o poți fixa cu precizie. Nu uita să scrii și un test pentru fixul făcut de tine. 😀
Happy debugging!
