Închis . Această întrebare trebuie să fie mai oncentrată
. În prezent, nu acceptă răspunsuri.
Comentarii
Răspuns
Mentalitatea și atitudinea față de depanare este probabil cea mai importantă parte, deoarece determină cât de eficient veți remedia eroarea și ce veți învăța din ea – dacă este ceva.
Clasice despre dezvoltarea de software, cum ar fi Programatorul pragmatic și Codul complet susțin practic aceeași abordare: fiecare eroare este o oportunitate de a învăța, aproape întotdeauna despre tine (deoarece numai începătorii dau vina pe compilator / computer mai întâi).
Deci, tratați-l ca pe un mister care va fi interesant de spart. Și spargerea acestui mister ar trebui făcută în mod sistematic, prin exprimarea ipotezelor noastre (pentru noi înșine sau pentru ceilalți) și apoi testarea ipotezelor noastre, unul câte unul, dacă este necesar – folosind fiecare instrument la dispoziția noastră, în special depanatori și cadre de testare automate. Apoi, după ce misterul este rezolvat, vă puteți descurca și mai bine, căutând prin tot codul dvs. erori similare pe care le-ați fi putut face; și scrieți un test automat pentru a vă asigura că eroarea nu se va mai întâmpla fără să știți din nou.
O ultimă notă – prefer să numesc erori „erori” și nu „erori” – Dijkstra și-a reproșat colegii că folosesc ultimul termen, deoarece este necinstit, susținând ideea că zânele periculoase și nestatornice au plantat bug-uri în programele noastre în timp ce noi nu căutam, în loc să fim acolo din cauza propriei noastre gânduri (neglijent): http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html
Am putea, de exemplu, să începem cu curățarea limbii noastre prin nu mai numiți un bug un bug, ci numindu-l eroare. Este mult mai onest, deoarece pune în mod clar vina acolo unde îi aparține, și anume. cu programatorul care a comis eroarea. Metafora animistă a bug-ului care s-a strecurat în mod rău intenționat în timp ce programatorul nu se uita este necinstită din punct de vedere intelectual, deoarece maschează că eroarea este creația proprie a programatorului. Lucrul frumos al acestei schimbări simple de vocabular este că are un efect atât de profund. : în timp ce, înainte, un program cu o singură eroare obișnuia să fie „aproape corect”, ulterior un program cu o eroare este doar „greșit” (deoarece din eroare).
Comentarii
Răspuns
-
Scrieți teste. Testarea nu numai că este excelentă în prevenirea erorilor (din experiența mea, TDD-ul făcut corect elimină aproape toate erorile banale și stupide), dar ajută și foarte mult la depanare. Testarea forțează proiectarea dvs. să fie destul de modulară, ceea ce face mult mai ușoară izolarea și replicarea problemei. De asemenea, controlați mediul, așa că vor exista mult mai puține surprize. Mai mult, odată ce obțineți un caz de testare nereușit, puteți fi destul de sigur că ați „prins motivul real al comportamentului care vă deranjează.
-
Aflați cum să folosiți un depanator. Instrucțiunile print pot funcționa destul de bine la un anumit nivel, dar un depanator de cele mai multe ori este foarte util (și o dată știi cum să-l folosești, este mult mai confortabil decât declarațiile print).
-
Vorbește despre cineva despre problema ta, chiar dacă este doar un papuc de cauciuc . Forțându-vă să exprimați problema cu care lucrați în cuvinte face cu adevărat minuni.
-
Acordați-vă o limită de timp. Dacă, de exemplu, după 45 de minute simțiți că nu mergeți nicăieri, treceți la alte sarcini pentru o perioadă de timp. Când veți reveni la eroarea dvs., veți putea, sperăm, să vedeți alte soluții posibile pe care nu le-ați fi luat în considerare înainte.
Comentarii
Răspuns
Îmi plac majoritatea celorlalte răspunsuri, dar iată câteva sfaturi despre ce să fac ÎNAINTE să faceți orice. Vă va economisi mult timp.
-
Determinați dacă există cu adevărat o eroare. O eroare este întotdeauna o diferență între comportamentul sistemului și cerințe; testerul ar trebui să poată articula comportamentul așteptat și real. Dacă nu este în măsură să ofere suport pentru comportamentul așteptat, nu există nicio cerință și nu există nicio eroare – doar opinia cuiva. Trimite-o înapoi.
-
Luați în considerare posibilitatea că comportamentul așteptat este greșit. Acest lucru s-ar putea datora unei interpretări greșite a cerinței. S-ar putea datora și unui defect al cerinței în sine (o deltă între o cerință detaliată și o cerință de afaceri). Puteți să le trimiteți și înapoi.
-
Izolați problema. Numai experiența vă va învăța cel mai rapid mod de a face acest lucru – unii oameni aproape o pot face cu intestinul lor. O abordare de bază este de a varia un singur lucru în timp ce păstrarea constantă a tuturor celorlalte lucruri (apare problema în alte medii? cu alte browsere? într-o regiune de testare diferită? în momente diferite ale zilei?) O altă abordare este de a analiza depozitele de stive sau mesajele de eroare – uneori puteți spune doar prin modul în care este formatat ce componentă a sistemului a aruncat eroarea inițială (de exemplu, dacă este în germană, puteți bloca eu acel terț cu care lucrați la Berlin).
-
Dacă l-ați redus la două sisteme care colaborează, inspectați mesajele dintre cele două sisteme prin monitorizarea traficului sau fișiere jurnal , și determinați care sistem se comportă în funcție de specificații și care nu. Dacă există mai mult de două sisteme în scenariu, puteți efectua verificări în perechi și puteți merge în jos în stiva de aplicații.
-
Motivul pentru care izolarea problemei este atât de critic este că problema s-ar putea să nu se datoreze unui defect al codului asupra căruia dețineți controlul (de exemplu, sistemele terțe sau mediul) și doriți să faceți ca acea parte să preia controlul cât mai repede posibil. Acest lucru este atât pentru a vă salva munca, cât și pentru a le pune imediat la punct, astfel încât rezoluția să poată fi atinsă într-un interval de timp cât mai scurt posibil. Nu doriți să lucrați la o problemă timp de zece zile doar pentru a găsi că este o problemă cu serviciul web al altcuiva.
-
Dacă ați stabilit că există într-adevăr un defect și că este într-adevăr în cod pe care îl controlați, puteți izola în continuare problema căutând ultima versiune „bună cunoscută” și inspectarea jurnalelor de control sursă pentru modificări care ar fi putut cauza problema. Acest lucru poate economisi mult timp.
-
Dacă nu puteți afla din controlul sursă, acum este momentul să atașați depanatorul și să parcurgeți codul pentru a-l calcula Șansele sunt că acum aveți o idee destul de bună despre problemă.
Odată ce știți unde este eroarea și vă puteți gândi la o soluție, aici este bine procedura de remediere a acestuia:
-
Scrieți un test de unitate care reproduce problema și eșuează.
-
Fără a modifica testul de unitate, faceți trece (modificând codul aplicației).
-
Păstrați testul de unitate în suita de testare pentru a preveni / detecta regresia.
Răspuns
Cred că este importantă și reproducerea unui bug. Toate cazurile care reproduc eroarea pot fi listate și apoi vă puteți asigura că remedierea erorii acoperă toate aceste cazuri.
Răspuns
Există o carte excelentă pe care am citit-o pe acest subiect, numită De ce nu reușesc programele , care prezintă diferite strategii pentru găsirea erorilor, de la aplicarea metodei științifice la izolarea și rezolvarea unui bug, până la depanarea delta. Cealaltă parte interesantă a acestei cărți este că elimină termenul „bug”. Abordarea lui Zeller este:
(1) Un programator creează un defect în cod. (2) Defectul provoacă o infecție (3) Infecția se propagă (4) Infecția provoacă un eșec.
Dacă doriți să vă îmbunătățiți abilitățile de depanare, vă recomand cu tărie această carte.
În propria mea experiență personală, am găsit o mulțime de erori în aplicația noastră, dar managementul pur și simplu ne presează mai departe pentru a scoate noi funcții. „Am auzit frecvent” Am găsit noi înșine această eroare și clientul încă nu a observat-o, așa că lăsați-o până când o fac ”. Cred că a fi reactiv, opus proactivului în remedierea erorilor, este o idee foarte proastă, deoarece atunci când vine momentul să puneți efectiv o remediere, aveți alte probleme care trebuie rezolvate și mai multe funcții de management vor să iasă pe ușă cât mai repede, astfel încât să fiți prins într-un ciclu vicios care poate duce la o mare cantitate de stres și ars și, în cele din urmă, un sistem defect.
Comunicarea este, de asemenea, un alt factor atunci când sunt găsite erori. Trimiterea unui e-mail sau documentarea acestuia pe urmăritorul de erori este în regulă, dar, din propria mea experiență, alți dezvoltatori găsesc o eroare similară și, mai degrabă decât să refolosească soluția pe care ați pus-o pentru a remedia codul (deoarece au „uitat totul), își adaugă propriile versiuni, aveți 5 soluții diferite în cod și, ca urmare, pare mai umflat și confuz. Prin urmare, atunci când remediați o eroare, asigurați-vă că câteva persoane examinează remedierea și vă oferă feedback în cazul în care au remediat ceva similar și a găsit o strategie bună pentru a o rezolva.
limist a menționat cartea,
Programatorul pragmatic , care are câteva materiale interesante despre remedierea erorilor. Folosind exemplul pe care l-am dat în paragraful anterior, m-aș uita la acest lucru: Software Entrophy , unde se folosește analogia unei văduve sparte. Dacă sunt două multe sparte ferestrele apar, echipa dvs. poate deveni apatică față de remedierea acesteia, cu excepția cazului în care luați o poziție proactivă.
Comentarii
Bug, eroare, problemă, defect – oricum doriți să-l numiți, nu are prea multe diferențe. Voi rămâne la problemă de atunci „s ceea ce obișnuiam”.
- Aflați care este percepția problemei: traduceți din „clientul” Bob încă nu se află în sistem „în„ Când încerc să creați o înregistrare de utilizator pentru Bob, eșuează cu o excepție de cheie duplicat, deși Bob nu este deja acolo.
- Aflați dacă este într-adevăr o problemă sau doar o neînțelegere (într-adevăr, Bob nu este ” T acolo, nu există nimeni numit bob și inserția ar trebui să funcționeze).
- Încercați să obțineți pași minimi de încredere pe care îi puteți urma pentru a reproduce problema – ceva de genul „Având în vedere un sistem cu o înregistrare de utilizator„ Bruce ”, când se introduce o înregistrare de utilizator„ Bob ”, atunci apare o excepție„
- Acesta este testul dvs. – dacă este posibil, puneți-l într-un automat testați hamul pe care îl puteți rula din nou și din nou, acest lucru va fi de neprețuit la depanare. De asemenea, puteți face parte din suita de testare pentru a vă asigura că problema respectivă nu mai reapare mai târziu.
- Scoateți-vă debuggerul și începeți să puneți puncte de întrerupere – aflați calea codului când rulați testul, și identifică ce nu este în regulă. În timp ce faceți acest lucru, puteți, de asemenea, să vă rafinați testul, făcându-l cât mai restrâns posibil – în mod ideal, un test unitar.
- Remediați-l – verificați dacă testul a trecut.
- Verificați problema inițială așa cum este descris de client este, de asemenea, remediat (foarte important – este posibil să fi remediat doar un subset al problemei). Verificați dacă nu ați introdus regresii în alte aspecte ale programului.
Dacă sunteți foarte familiarizat cu codul sau dacă problema sau remedierea este evidentă, puteți săriți unele dintre acestea pași.
Cum ar trebui să ne apropiem de el pentru a utiliza cât mai eficient timpul nostru valoros și pentru a ne permite să petrecem mai puțin timp încercând să-l găsim și să codificăm mai mult timp? ?
Am probleme cu asta, deoarece implică faptul că scrierea unui cod nou este valoroasă decât să ai un program de lucru de înaltă calitate. Nu este nimic în neregulă să fii cât mai eficient la rezolvarea problemelor, dar un program nu se îmbunătățește neapărat prin simpla adăugare a mai multor coduri.
Comentarii