Programmører bruger en høj procentdel af tiden på fejlretning i stedet for at skrive kode. Du havde sandsynligvis lidt træning i at lære et sprog eller en ramme - men hvordan lærte du at rette fejlene i din software?
Da du blev forelsket i programmering (eller i det mindste besluttede, at det var en lønnsom karriere), tænkte du sandsynligvis på det som en kreativ indsats. Du ville designe god software, skrive koden og poof!—Det fungerede perfekt første gang.
Ja. Ret.
I den virkelige verden brugte du en masse af din tid på fejlretningskode i stedet for at skrive nye ting. Jeg er sikker på, at jeg kunne grave op en uklar procentdel af udviklertiden, der er afsat til at rette fejl i stedet for at skabe ny funktionalitet, men jeg tvivler på, at du har brug for at høre et nummer. Du kan alt for let forestille dig de dage, du brugte på udkig efter Bug From Hell, og dens indvirkning på din projektplan.
Nu er der mange måder, som programmører kan og lærer nye softwarefærdigheder på, uanset om det er at læse en bog, deltage i en teknisk konference eller besøge websteder som JavaWorld.com. (Jeg er ret glad for, at du gør sidstnævnte.) Disse fokuserer dog normalt på værktøjer, såsom sprog eller rammer, og ikke på metateknikker, såsom "Sådan finder du den fejl på to timer i stedet for to dage." Sprog kan komme og gå, og det samme vil IDE-debuggere, men evnen til at skelne under hvilken sten din bug gemmer sig, er en, der forbliver hos dig for evigt.
En stor del af færdighederne i at lære at debugge er selvfølgelig erfaring. Det kan være din egen oplevelse eller muligheden for at være en græshoppe ved fødderne af en masterprogrammerer. Jeg har også mistanke om, at nogle mennesker har et medfødt talent til fejlfinding (lige så relevant for at rette en ødelagt bil som en dårlig opførsel), og de af os uden den kan kun triste af misundelse.
Imidlertid, nogle af dette kan man lære. For eksempel havde en masterprogrammerer af min bekendte et aksiom: Hvis du har ledt efter en fejl i (relativt) lang tid og ikke kan finde den, sagde han: "Du leder efter det forkerte sted." Tydeligt lydende, men bestemt sandt ... og hvor ofte har du spildt tid på at kigge i XYZ-modulet, da problemet var et helt andet sted?
Jeg bad flere udviklere om, hvordan de lærte eller forbedrede deres fejlretningsfærdigheder. Et overraskende antal af dem talte om deres beherskelse af IDE's debugger eller anden værktøjsexpertise, men det meste af det, jeg ville vide, er deres råd til at forbedre ens evne til at rette fejl. Her er en kort oversigt over deres svar.
- Vær disciplineret. Fejlfinding er en proces, sagde en udvikler, ikke en række tilfældige begivenheder. Tilpas ikke tilfældigt drejeknapper; følg kodens udførelsesproces. Ligesom at lave en plæneklipper, sagde han. Får del A det input, den har brug for? Hvad med output? Hvis det er OK, skal du gå videre.
- For at forbedre dine færdigheder skal du fejle andres kode i stedet for din egen. Det vil være lettere at se fejlene i den anden persons antagelser, end det er at se dine egne. Du kan muligvis gøre dette som en del af en gennemgang af krydsningskoder og fejlretning af krydsfæller. Du vil udvikle evnen til at genkende de almindelige årsager til defekter hurtigere, lovede en udvikler og lære dig at genkende (og opgive) din egen dårlige udviklingspraksis.
- Lad som om du er kompilatoren. Find og ret så mange fejl som muligt, inden du trykker på kompileringsknappen. Mens de fleste moderne IDE'er inkluderer integrerede debuggere (som Visual Studios Intellisense), lærer du mindre af deres automatisering, end du vil ved bevidst at undersøge processen. (På samme måde lærer du aldrig at stave korrekt ved at stole på en stavekontrol for at udføre alt arbejdet.)
- Lær at rette fejl så tidligt i udviklingsprocessen, som du kan. Det kan betyde noget formaliseret, såsom testdrevet udvikling. Det betyder også, at du bruger tid på at fejle dit design i stedet for at tøve med kodning.
- Fejlretning er nemmest, når du kan holde hele systemet i hovedet. Foretag ikke fejlen ved kun at fokusere på en del af en applikation. Vær opmærksom på sammenhængen mellem moduler. Læs koden på flere niveauer af abstraktion, rådede en programmør. ”At finde fejlen er den sværeste del, og det kræver en klar forståelse af, hvad flere stykker af koden laver,” sagde hun.
- En del af det samme rådgivning tror jeg, er en andens forslag: få en god forståelse af systemet et niveau ned fra det, du arbejder på. "Hvis du fejler et systemniveau C-program, hjælper det at kende en samling og noget om operativsystemet," forklarede en systemsoftwareleder. "Hvis du debugger en J2EE-app, hjælper det at vide noget om Java-tråde, RMI og GC." I mange tilfælde påpegede han, at fejlmeddelelser kommer fra den et-niveau-ned. "Hvis du kan forstå, hvad det betyder, vil det hjælpe dig med at finde ud af, hvad der går galt på dit abstraktionsniveau," forklarede han.
Et par udviklere anbefalede også ekstra ressourcer. Blandt dem er David Agans bog, Debugging, der lover ni uundværlige regler, og Why Programs Fail: A Guide to Systematic Debugging, som er ved at blive frigivet i en anden udgave. Udvikleren, der anbefalede sidstnævnte, siger, at den lærer en systematisk tilgang til fejlfinding med masser af praktiske eksempler. En anden foreslog et online essay, Ti færdigheder af meget effektive softwaretestere.
Jeg kan godt lide alle disse svar, men jeg formoder, at der er mere visdom at dele. Hvordan fik du dine fejlretningsfærdigheder? Hvordan har du hjulpet andre med at forbedre deres?
Denne historie, "Learning and Improving Your Debugging Skills" blev oprindeligt udgivet af JavaWorld.
