Programmētāji lielu daļu laika pavada atkļūdošanai, nevis raksta kodu. Jums, iespējams, bija kāda apmācība valodas vai ietvara apguvē, bet kā jūs iemācījāties novērst programmatūras defektus?
Kad jūs iemīlējāt programmēšanu (vai vismaz nolēmāt, ka tā ir atalgojoša karjera), jūs, iespējams, domājāt par to kā par radošu darbu. Jūs izstrādājat lielisku programmatūru, uzrakstiet kodu un pufs!- tas pirmo reizi darbotos nevainojami.
Jā. Pa labi.
Reālajā pasaulē jūs pavadījāt virkni sava laika, atkļūdojot kodu, nevis rakstot jaunu saturu. Es esmu pārliecināts, ka es varētu uzrādīt neskaidru procentuālo daļu izstrādātāja laika, kas veltīts defektu novēršanai, nevis jaunas funkcionalitātes radīšanai, taču es šaubos, vai jums ir jādzird skaitlis. Jūs varat pārāk viegli attēlot dienas, kuras pavadījāt, meklējot Bug From Hell, un tās ietekmi uz jūsu projekta grafiku.
Tagad ir daudz veidu, kā programmētāji var un var apgūt jaunas programmatūras prasmes, neatkarīgi no tā, vai tas ir grāmatas lasīšana, tehnisko konferenču apmeklēšana vai tādu vietņu kā JavaWorld.com apmeklēšana. (Es drīzāk priecājos, ka jūs darāt pēdējo.) Tomēr tie parasti koncentrējas uz rīkiem, piemēram, valodām vai ietvariem, nevis uz metatehniku, piemēram, "Kā atrast šo kļūdu divu stundu laikā divu dienu vietā." Valodas var nākt un iet, tāpat arī IDE atkļūdotāji, taču spēja noteikt, zem kura klints slēpjas jūsu kļūda, ir tā, kas paliks pie jums uz visiem laikiem.
Liela daļa prasmju iemācīties atkļūdot, protams, ir pieredze. Tā varētu būt jūsu pašu pieredze vai iespēja būt sienāzim pie maģistra programmētāja pēdām. Man ir arī aizdomas, ka dažiem cilvēkiem piemīt iedzimts talants novērst traucējumus (tikpat svarīgi, lai salabotu salauztu automašīnu kā nepareizi rīkojošos lietojumprogrammu), un tie, kas mūs bez tā var tikai apskaust.
Tomēr daži to var iemācīties. Piemēram, vienam manas paziņas maģistrantam bija aksioma: ja jūs (salīdzinoši) ilgu laiku meklējāt kļūdu un to nevarat atrast, viņš teica: "Jūs meklējat nepareizā vietā." Skaidrs, bet noteikti taisnība ... un cik bieži jūs esat tērējis laiku, skatoties XYZ modulī, kad problēma bija pilnīgi citur?
Es jautāju vairākiem izstrādātājiem veidus, kā viņi iemācījās vai uzlaboja atkļūdošanas prasmes. Pārsteidzoši daudzi no viņiem runāja par IDE atkļūdotāja meistarību vai kādu citu rīku lietpratību, taču lielākā daļa no tiem, ko es vēlējos uzzināt, ir viņu padomi, kā uzlabot spēju novērst kļūdas. Šeit ir īss viņu atbilžu kopsavilkums.
- Esiet disciplinēts. Atkļūdošana ir process, sacīja viens izstrādātājs, nevis nejaušu notikumu virkne. Nejauši nejauciet pogas; sekojiet koda izpildes procesam. Tāpat kā viņš laboja zāles pļāvēju, viņš teica. Vai A daļa iegūst nepieciešamo ieguldījumu? Kā ar rezultātu? Ja tas ir labi, dodieties tālāk.
- Lai uzlabotu savas prasmes, atkļūdojiet citu, nevis savu kodu. Būs vieglāk saskatīt kļūdas otra cilvēka pieņēmumos nekā pašam. Jūs to varat izdarīt kā daļu no savstarpējas salīdzināšanas koda pārskatīšanas un savstarpējas atkļūdošanas. Jūs attīstīsit spēju ātrāk atpazīt kopējos defektu cēloņus, apsolījāt vienam izstrādātājam un iemācīsit atpazīt (un atteikties) no savas sliktās attīstības prakses.
- Izlikieties, ka esat sastādītājs. Pirms nospiežat pogu Kompilēt, atrodiet un izlabojiet pēc iespējas vairāk kļūdu. Lai gan lielākā daļa mūsdienu IDE ietver integrētus atkļūdotājus (piemēram, Visual Studio Intellisense), jūs no viņu automatizācijas mācīsities mazāk nekā apzināti pārbaudot procesu. (Tādā pašā veidā jūs nekad nemācīsities pareizi uzrakstīt pareizrakstību, paļaujoties uz pareizrakstības pārbaudītāju, lai veiktu visu darbu.)
- Uzziniet, kā novērst kļūdas pēc iespējas ātrāk izstrādes procesā. Tas varētu nozīmēt kaut ko formālu, piemēram, testu vadītu attīstību. Tas nozīmē arī laika veltīšanu dizaina atkļūdošanai, nevis kodēšanai.
- Atkļūdošana ir visvieglāk, ja jūs varat turēt galvā visu sistēmu. Nekļūdieties, koncentrējoties tikai uz vienu lietojumprogrammas daļu. Pievērsiet uzmanību moduļu savstarpējām attiecībām. Lasiet kodu vairākos abstrakcijas līmeņos, ieteica viens programmētājs. "Atrast kļūdu ir visgrūtāk, un ir nepieciešama skaidra izpratne par to, ko dara vairāki koda gabali," viņa teica.
- Daļa šī paša padoma, manuprāt, ir kāda cita ierosinājums: iegūt labu izpratni par sistēmu vienā līmenī zemāk par to, pie kā jūs strādājat. "Ja jūs atkļūdojat C līmeņa sistēmas programmu, tas palīdz uzzināt dažus montāžas elementus un kaut ko par OS," paskaidroja sistēmas programmatūras vadošais inženieris. "Ja atkļūdojat J2EE lietotni, tas palīdz kaut ko uzzināt par Java pavedieniem, RMI un GC." Daudzos gadījumos viņš norādīja, ka kļūdu ziņojumi nāk no šī viena līmeņa uz leju. "Ja jūs varat saprast, ko tas nozīmē, tas palīdzēs jums saprast, kas notiek nepareizi jūsu abstrakcijas līmenī," viņš paskaidroja.
Daži izstrādātāji ieteica arī papildu resursus. Starp tiem ir Deivida Agana grāmata Atkļūdošana, kas sola deviņus neaizstājamus noteikumus, un Kāpēc programmas neizdodas: rokasgrāmata sistemātiskai atkļūdošanai, kas drīzumā tiks izlaista otrajā izdevumā. Izstrādātājs, kurš ieteica pēdējo, saka, ka tas māca sistemātisku pieeju atkļūdošanai, izmantojot daudz praktisku piemēru. Cits ieteica tiešsaistes eseju “Ļoti efektīvu programmatūras testētāju desmit prasmes.
Man patīk visas šīs atbildes, taču man ir aizdomas, ka ir vairāk gudrības, ar ko dalīties. Kā jūs ieguvāt savas atkļūdošanas prasmes? Kā jūs esat palīdzējis citiem uzlabot savu?
Šo stāstu "Atkļūdošanas prasmju mācīšanās un uzlabošana" sākotnēji publicēja JavaWorld.
