Programmører bruker en høy prosentandel av tiden på feilsøking i stedet for å skrive kode. Du hadde sannsynligvis litt trening i å lære et språk eller rammeverk - men hvordan lærte du å fikse feilene i programvaren din?
Da du ble forelsket i programmering (eller i det minste bestemte at det var en lønnende karriere), tenkte du sannsynligvis på det som en kreativ innsats. Du vil designe flott programvare, skrive koden og poff!—Det fungerte perfekt første gang.
Ja. Ikke sant.
I den virkelige verden brukte du en del av tiden din på å feilsøke koden i stedet for å skrive nye ting. Jeg er sikker på at jeg kunne grave opp en uklar prosentandel av utviklertiden som er viet til å fikse feil i stedet for å skape ny funksjonalitet, men jeg tviler på at du trenger å høre et nummer. Du kan for enkelt forestille deg dagene du brukte på jakt etter Bug From Hell, og dens innvirkning på prosjektplanen.
Nå er det mange måter som programmerere kan og lærer nye programvareferdigheter, enten det er å lese en bok, delta på en teknologikonferanse eller besøke nettsteder som JavaWorld.com. (Jeg er ganske glad for at du gjør det siste.) Disse fokuserer imidlertid vanligvis på verktøy, for eksempel språk eller rammer, og ikke på metateknikker, for eksempel "Hvordan finner du den feilen på to timer i stedet for to dager." Språk kan komme og gå, og det vil også IDE-feilsøkere, men evnen til å skjelne under hvilken stein feilen din gjemmer seg, er en som vil være hos deg for alltid.
En stor del av ferdighetene med å lære å feilsøke er selvfølgelig erfaring. Det kan være din egen erfaring, eller muligheten til å være en gresshoppe ved føttene til en masterprogrammerer. Jeg mistenker også at noen mennesker har et medfødt talent for feilsøking (like relevant for å fikse en ødelagt bil som en dårlig oppførsel), og de av oss uten den kan bare plyndre i misunnelse.
Derimot, noen av dette kan læres. For eksempel hadde en hovedprogrammerer av min bekjente et aksiom: Hvis du har sett etter en feil i (relativt) lang tid og ikke finner den, sa han: "Du ser på feil sted." Åpenbart høres ut, men absolutt sant ... og hvor ofte har du kastet bort tid på å se i XYZ-modulen når problemet var et annet sted helt?
Jeg spurte flere utviklere om hvordan de lærte eller forbedret feilsøkingsevnen. Overraskende mange av dem snakket om deres mestring av IDEs feilsøkingsprogram eller annen verktøykompetanse, men det meste jeg ønsket å vite er deres råd om å forbedre ens evne til å fikse feil. Her er en kort oppsummering av svarene deres.
- Vær disiplinert. Feilsøking er en prosess, sa en utvikler, ikke en serie tilfeldige hendelser. Ikke juster knotter tilfeldig; følg kodens kjøringsprosess. Akkurat som å fikse en gressklipper, sa han. Får del A de innspillene den trenger? Hva med produksjonen? Hvis det er OK, fortsett.
- For å forbedre ferdighetene dine, feilsøk andres kode i stedet for din egen. Det vil være lettere å se feilene i den andres forutsetninger enn å se dine egne. Du kan gjøre dette som en del av en gjennomgang av kodene og feilsøking. Du vil utvikle evnen til å gjenkjenne de vanlige årsakene til feil raskere, lovet en utvikler, og lære deg å gjenkjenne (og forlate) din egen dårlige utviklingspraksis.
- Lat som om du er kompilatoren. Finn og korriger så mange feil du kan før du trykker på kompileringsknappen. Mens de fleste moderne IDEer inkluderer integrerte feilsøkingsprogrammer (som Visual Studios Intellisense), lærer du mindre av automatiseringen enn du vil fra bevisst å undersøke prosessen. (På samme måte lærer du aldri å stave riktig ved å stole på en stavekontroll for å gjøre alt arbeidet.)
- Lær å fikse feil så tidlig som mulig i utviklingsprosessen. Det kan bety noe formalisert, for eksempel testdrevet utvikling. Det betyr også å bruke tid på å feilsøke designet ditt i stedet for å tøffe koding.
- Feilsøking er enklest når du kan holde hele systemet i hodet. Ikke gjør feilen ved å fokusere på bare en del av en applikasjon. Vær oppmerksom på innbyrdes forhold mellom moduler. Les koden på flere nivåer av abstraksjon, rådet en programmerer. "Å finne feilen er den vanskeligste delen, og det krever en klar forståelse av hva flere koder gjør," sa hun.
- En del av samme råd, tror jeg, er andres forslag: få en god forståelse av systemet ett nivå ned fra det du jobber med. "Hvis du feilsøker et systemnivå C-program, hjelper det å vite litt montering og noe om operativsystemet," forklarte en lederprogramvare for systemprogramvaren. "Hvis du feilsøker en J2EE-app, hjelper det å vite noe om Java-tråder, RMI og GC." I mange tilfeller, påpekte han, kommer feilmeldinger fra den ett-nivå-ned. "Hvis du kan forstå hva det betyr, vil det hjelpe deg å finne ut hva som går galt på ditt abstraksjonsnivå," forklarte han.
Noen få utviklere anbefalte også ekstra ressurser. Blant dem er David Agans bok, Debugging, som lover ni uunnværlige regler, og Why Programs Fail: A Guide to Systematic Debugging, som snart skal utgis i en andre utgave. Utvikleren som anbefalte sistnevnte sier at den lærer en systematisk tilnærming til feilsøking med mange praktiske eksempler. En annen foreslo et online essay, Ten skills of high effektive software testers.
Jeg liker alle svarene, men jeg mistenker at det er mer visdom å dele. Hvordan fikk du dine feilsøkingsferdigheter? Hvordan har du hjulpet andre med å forbedre deres?
Denne historien, "Learning and Improving Your Debugging Skills" ble opprinnelig utgitt av JavaWorld.
