Kā daudzi skatieni savalda sarežģītību

Viens ir novērot, kā tirgus stils paātrina atkļūdošanu un koda attīstību kopumā. Cits ir saprast, kā un kāpēc tas notiek mikrolīmenī — izstrādātāja un testētāja ikdienas uzvedībā. Šajā nodaļā (kas ir rakstīta trīs gadus pēc sākotnējā darba, izmantojot izstrādātāju novērojumus, kas šo darbu izlasīja un salīdzināja ar savu uzvedību) mēs pamatīgāk pievērsīsimies patiesajiem mehānismiem. Lasītāji ar noslieci uz netehniskām lietām var mierīgi pāriet uz nākošo nodaļu.

Galvenais kas jāsaprot, ir tas ka kļūdas ziņojums kodu nezinošam lietotājam ir nevērtīgs. Kodu nezinoši lietotāji sliecas uzskaitīt tikai ārējos simptomus, viņi izmanto gatavu apkārtni, līdz ar to viņi:

1. neievēro kritiskus fona datus,
2. reti iekļauj izmantojamu aprakstu kļūdas atkārtošanai.

Galvenā problēma šeit ir atšķirība starp mentālajiem modeļiem, kā testētājs un izstrādātājs redz programmu — testētājs raugās no ārpuses uz iekšu, bet izstrādātājs no iekšpuses uz āru. Slēgtā koda izstrādē viņi sliecas palikt šajās lomās, un runājot viens otru nesaprot, un tāpēc mēdz viens otrā pamatīgi vilties.

Atvērtais kods salauž šo kārtību, ļaujot testētājam un izstrādātājam veidot kopīgu uzskatu par programmu, kas balstīta uz redzamu kodu, un efektīvi par to sarunāties. Izstrādātājam ir milzīga praktiska atšķirība starp kļūdas aprakstu, kas tikai apraksta ārēji redzamu programmas uzvedību, vai tieši norāda uz izstrādātāja pirmkoda bāzētu mentālo programmas aprakstu.

Vairums kļūdu parasti ir viegli noķeramas, ja tiek dots uzvedinošs apraksts par to parādīšanos pirmkoda līmenī, pat ja tas ir nepilnīgs. Ja kāds no jūsu beta testētājiem var norādīt ka, "rindā nnn ir problēmas ar robežām", vai tikai "X, Y un Z gadījumā, šis mainīgais pārpildās", pietiek ar ātru skatu uz aizdomīgo kodu, lai noteiktu konkrēto kļūdas iemeslu un to izlabotu.

Tādējādi abu pušu pirmkoda zināšanas ievērojami uzlabo gan labu saziņu, gan beta testētāju ziņojumu un pamatizstrādātāja zināšanu sinerģiju. Līdz ar to pamatizstrādātāja laiks pamatīgi ietaupās, pat ja viņš sadarbojas ar daudziem līdzstrādniekiem.

Vēl viena atvērtā koda pasaules īpašība, kas ietaupa izstrādātāja laiku, ir saziņas veids. Augstāk es minēju vārdu "pamatizstrādātājs" — tas atspoguļo atšķirību starp projekta kodolu (kas parasti ir diezgan mazs — bieži ir viens pamatizstrādātājs, viens līdz trīs ir tipiski) un projekta beta testētāju un atbalstītāju vainagu (kas parasti ir vairāki tūkstoši).

Fundamentāla problēma programmu izstrādē ir Brūka likums:

Ja novēlotam projektam pievieno papildu programmētājus, tas tiek kavēts vēl vairāk.

Vispārīgā gadījumā Brūka likums nosaka to, ka sarežģītības un saziņas izmaksas pieaug kvadrātiski no izstrādātāju skaita, kamēr padarītais darbs tikai lineāri.

Brūka likums ir bāzēts uz pieredzi, ka kļūdas tiecas grupēties vietās, kuras raksta dažādi cilvēki, un ka projekta saziņas un koordinēšanas izmaksas sliecas pieaugt līdz ar cilvēku sadarbības variācijām. Tādējādi problēmu skaits pieaug līdz ar izstrādātāju saziņas ceļu skaitu, t.i. ar izstrādātāju skaita kvadrātu (precīzāk, saskaņā ar formulu N*(N – 1)/2, kur N ir izstrādātāju skaits).

Brūka likuma analīze (un rezultējošās bailes no lielām izstrādātāju grupām) balstās uz noklusētu pieņēmumu, ka projekta locekļu saziņas struktūra ir pilns grafs, kur katrs runā ar katru. Bet atvērtā koda projektos vainaga izstrādātāji patiesībā strādā paralēlos zaros un ļoti maz sazinās savā starpā, koda izmaiņas un kļūdu ziņojumi plūst caur kodola grupu, un tikai mazās kodola grupas iekšpusē mēs maksājam pilnās Brūka likuma izmaksas. (SU)

Tomēr ir vēl citi iemesli, kāpēc atvērtā koda kļūdu ziņojumi ir tik efektīvi. Tas saistās ar faktu, ka viena kļūda var izraisīt daudzus iespējamos simptomus, kas parādās dažādi atkarībā no tā, kāda ir testēšanas apkārtne un programmas pielietojums. Un tieši tādas sarežģītas kļūdas, kuras ir grūti noķert, atkārtot pēc vēlēšanās vai noteikt ar statistisku analīzi (piem., dinamiskās atmiņas pārvaldības kļūdas, nedeterminēti pārtraukumu ziņojumi), rada vislielākās ilgtermiņa grūtības programmas izstrādē.

Testētājs, kas nosūta orientējošu pirmkoda līmeņa aprakstu par kādu daudzu simptomu kļūdu kā ("Man šķiet, ka ap 1250 rindu ir pārrāvums signāla apstrādē " vai "Kur jūs notīrāt šo buferi?") var dot izstrādātājam kritisku risinājumu pusducim dažādu simptomu, kas dažkārt ir pārāk tuvu kodam, lai to redzētu. Šādos gadījumos var būt ļoti grūti vai pat neiespējami zināt, kura kļūda ir radījusi ārēji redzamu nepareizu uzvedību — bet ar biežiem laidieniem to zināt nav nepieciešams. Ļoti iespējams, citi līdzstrādnieki ātri noteiks, vai viņu kļūda ir izlabota, vai nav. Un ļoti bieži pirmkoda līmeņa kļūdu ziņojumi liks pazust nepareizai uzvedībai, pat nenosakot, kurā labojumā tas īsti tika izdarīts.

Sarežģītas daudzu simptomu kļūdas mēdz veidot daudzus ceļus no ārējiem simptomiem uz aktuālo kļūdu vai pretēji. Ceļš, kuru dotais izstrādātājs un testētājs var noķert, var būt atkarīgs no konkrētās testēšanas vides un var pamatīgi un neredzami mainīties laika gaitā. Lai noteiktu šo simptomu cēloni, izstrādātājs un testētājs atlasa pusvarbūtīgu programmas stāvokļu kopu. Jo sarežģītāka un grūtāk pamanāma ir kļūda, jo mazāk ticams, ka abu zināšanas būs pietiekamas, lai garantētu, ka šī atlase ir atbilstoša.

Vienkāršām un viegli atkārtojamām kļūdām uzsvars tiks likts uz drīzāk "pus.." nekā "varbūtīgām" — tādā gadījumā atkļūdošanas prasmes un koda un arhitektūras pārzināšana ir svarīga. Bet sarežģītām kļūdām uzsvars tiks likts uz "varbūtīgām". Šādos apstākļos daudzu cilvēku paralēli mēģinājumu veidi būs daudz efektīvāki, kā dažu cilvēku pakāpeniska izpildes ceļu pārbaude, pat ja šiem dažiem ir daudz lielāks zināšanu līmenis.

Šis efekts ievērojami pastiprinās, ja sarežģītība no ārējiem programmas simptomiem uz kļūdu var mainīties ļoti dažādi un neparedzami, raugoties tikai uz simptomiem. Viens izstrādātājs, izpētot šos ceļus pakāpeniski, visticamāk, vispirms pārbaudīs garāko, nevis īsāko ceļu. No otras puses, pieņemot, ka daudz cilvēki šos izpildes ceļus pārbauda paralēli uz ātri sagatavotiem laidieniem, ļoti ticams, ka kāds no viņiem uzreiz atklās visīsāko ceļu, un norādīs uz kļūdu daudz īsākā laikā. Projekta uzturētājs atklās, ka, izlaižot jaunu laidienu, citi, kas cīnījās ar šo pašu kļūdu, pārstāj to darīt, pirms vēl viņi ir iztērējuši pārāk daudz laika sarežģīto kļūdas ceļu izpētei (RJ).