Saturs
- Atkļūdošanas kods: kā tas izdarīts
- Cīņas cīņas
- Kāpēc bugs izvairās no sagūstīšanas?
- Bez kļūdām, bez stresa - jūsu soli pa solim, kā izveidot programmatūru, kas maina dzīvi, neiznīcinot savu dzīvi
- Atkļūdošanas filozofija
Avots: Abscent84 / iStockphoto
Izņemšana:
Pārdomāti vadītāji ir sapņojuši par mainīgāku programmatūras izlaišanas struktūru, lai savienotu attīstības un ražošanas vidi, taču datorprogrammēšanai tas joprojām ir burvju elements.
Ikviens, kurš ir strādājis pie pat visvienkāršāko projektu kodēšanas, zina, ka process prasa mazliet pacietības. Daudzas nepilnības, mēģinot rakstīt kodu no nulles, ir dziesma un deja no visiem daudzajiem veidiem, kā cilvēku programmētājs vai izstrādātājs to var nepareizi izmantot. Tas ir garš saraksts, un tajā ir viss, sākot no sintakses kļūdām, kuras parasti pieķer kompilators, līdz dziļākām "redzes līmeņa" kļūdām, kurām nepieciešama saprātīgāka pārskatīšana. Šajā nolūkā skolas un mācību centri māca datorzinātņu studentiem, kā "atkļūdot" programmu. Interesanti, ka katrs indivīds izstrādā savu unikālo reakciju uz šo izaicinājumu. Faktiski šī var būt joma, kurā ir vajadzīgs vairāk nekā neliels personīgais ieskats. (Izlasiet par dažiem programmēšanas svarīgākajiem skaitļiem sadaļā Datorprogrammēšanas pionieri.)
Atkļūdošanas kods: kā tas izdarīts
Dažos gadījumos datorzinātnes profesionāļi var izmantot izstrādātāju studiju vai programmēšanas vides resursus, lai programmā atdalītu kļūdas. Tomēr, ja šāda veida kļūdu apstrāde vai sistēma nav pieejama vai noderīga, atkļūdošanai ir nepieciešams iet caur kodu pa rindām. Daudzām programmēšanas vidēm, piemēram, Microsoft Visual Basic Studio, ir funkcijas, kas ļauj skaidru, vizuālu rindkopas “pastiprināšanu” ar kodu.
Kodēšanas veikšana palīdz divos galvenajos veidos: pirmkārt, programmētāji var redzēt, kas notiek, kad dators nolasa kodu, un kur galvenā uzmanība tiek pievērsta rekursīvo funkciju un citas koda mijiedarbības ziņā. Tomēr, otrkārt, programmētājs bieži var redzēt dažādu mainīgo lielumus, izmantojot peles kursoru vai citas interfeisa daļas. Zinot, kādas vērtības ir mainīgajos, ir galvenais veids, kā saprast, ko dators dara ar kodu, kas tam tiek piešķirts.
Cīņas cīņas
Iepriekš aprakstītais process var izklausīties vienkāršs, taču faktiskā atkļūdošanas problēma var būt daudz sarežģītāka. Lielisks šī procesa piemērs ir atrodams tehniskajā trillerī, kuru trāpīgi sauc par “The Bug” un kuru izstrādājusi Ellen Ullman, bijusī izstrādātāja un IT profesionāle, kuras proza spīd literāri. Lai arī grāmata ir daiļliteratūra, tā daudz ko atklāj par to, kas notiek, kad programmētāji un datori mijiedarbojas.
Neņemot vērā daudz tumši personisko detaļu grāmatā, Ulmana divu cilvēku, kas ir testeris un programmētājs, attēlojums parāda dažus no galvenajiem izaicinājumiem, ar kuriem šīs karjeras tehnikas pārstāvji saskārās agrākajā programmatūras izstrādes laikmetā. Būtībā viņas kļūda, ko viņa dēvē par “The Jester”, izvairījās no visiem 80. gadu programmatūras uzņēmumā, saspringstot darbinieku attiecības, sagraujot investoru uzticību un kopumā izraisot graudu rašanos. Tikmēr autore diezgan maz atspoguļo to, kā datori ietekmē mūs, un kāpēc, ja mēs vēlamies triumfēt pār viņu īpatnībām, mums “jādomā kā mašīnai”. (Lai uzzinātu par programmēšanas vēsturi, iepazīstieties ar datorprogrammēšanu: no mašīnu valodas līdz mākslīgajam intelektam.)
Kāpēc bugs izvairās no sagūstīšanas?
Viens no iemesliem, kāpēc kļūda Ulmana grāmatā bija tik grūti risināma, ir tas, ka tā parādījās tikai nepāra laikos. Šis izaicinājums patiesi der daudzām citām šādām aizrautībām (atcerieties tikai par Toyota plašajiem izmēģinājumiem pēc lietotāju baumām par aizbēgušo Prius). Pieņemsim, ka kāds saka, ka jums ir kļūda. Ja vien jūs nevarat likt datoram pamanīt problēmu, kur jūs pat sākat to labot?
Šīs glitchness iemesls, kā atklājās grāmatas beigās, ir vēl viens lielisks piemērs personālā datora koda rakstīšanas sarežģītībai tajā laikmetā - un, iespējams, tas joprojām ir mūsdienās. Būtībā kļūda tika paslēpta nelielā, ligzdotā funkcijā, kas vienkārši nodrošināja pamata orientāciju citiem koda gabaliem. Tā kā to bija uzrakstījis trešās puses programmētājs, un tā kā nebija saziņas starp programmētājiem, patiesais problēmas avots vairākus mēnešus bija slēpts - patiess problēmu apliecinājums var rasties no nepareizi dokumentēta komandas darba.
Runājot par datora kļūdu, viltīga detaļa var iemest haosā citādi sakārtotu sistēmu. Labas kodēšanas prasmes, tāpēc dažreiz var būt vairāk māksla nekā zinātne (Ullman to sauc par "neprātu"), padarot kodēšanu pēc būtības netīru biznesu.
Bez kļūdām, bez stresa - jūsu soli pa solim, kā izveidot programmatūru, kas maina dzīvi, neiznīcinot savu dzīvi
Jūs nevarat uzlabot savas programmēšanas prasmes, kad nevienam nerūp programmatūras kvalitāte.
Atkļūdošanas filozofija
Lai sasniegtu rezultātus, programmētājiem bieži ir jāstrādā ar datoriem, nevis cilvēkiem. Ullmans norāda, ka kodētāji un testētāji bieži ir visefektīvākie, ja viņi spēj nolikt visas cilvēka domāšanas nianses un izslēgt spriešanu līdz datoru izmantoto loģiku pamatnei. Tas nozīmē daudz ko atcelt tam, ar ko mēs visi strādājam katru dienu, lai iegūtu skaidrību par fokusu. Šī kvalitāte ļauj attīstīties daudziem labākajiem datorzinātņu speciālistiem pat laikmetā, kad lielākajai daļai projektu ir izveidots daudz vairāk ietvaru.
Pārdomāti vadītāji ir sapņojuši par mainīgāku programmatūras izlaišanas struktūru, lai savienotu attīstības un ražošanas vidi, taču datorprogrammēšanai tas joprojām ir burvju elements. Tāpēc labākie programmētāji nav tikai strukturālie kodētāji; viņiem ir instinkts izskaust un novērst kļūdas, kas apdraud to mašīnu funkcionalitāti, uz kurām mēs arvien vairāk paļaujamies.