Izlaid ātri un bieži

Ātri un bieži laidieni ir svarīgākā Linux izstrādes īpašība. Vairums programmētāju (mani ieskaitot) mēdza domāt, ka tā ir slikta prakse projektiem, kas nav triviāli, jo agras versijas jau pēc definīcijas ir kļūdainas, bet jūs nevēlaties pārbaudīt savu lietotāju pacietību.

Šāda nostāja nostiprināja uzticību katedrāles stila izstrādei. Ja galvenais ir, lai lietotāji atrastu pēc iespējas mazāk kļūdu, tad jaunus laidienus vajag izlaist pēc iespējas retāk, bet starp laidieniem kā zirgam jāstrādā ar atkļūdošanu. Šādā veidā tika izstrādāts Emacs un C kodols. Bet Lisp bibliotēka nē — jo bija daudz aktīvu lietotāju ārpus FSF kontroles, kur katrs varēja saņemt jaunu izstrādes versiju neatkarīgi no Emacs laidienu cikliem (QR).

Viens no nozīmīgākajiem bija Ohaijo pavalsts Emacs Lisp arhīvs, kas jau tajā laika atklāja šodienas Linux arhīvu veidu un garu. Bet tikai retais no mums nopietni aizdomājās par to, ko mēs tajā laikā darījām, un tas mūs neuzvedināja uz domām par FSF katedrāles stila izstrādes modeļa problēmām. 1992. gadā es mēģināju lielāko daļu no Ohaijo koda iekļaut oficiālajā Emacs Lisp bibliotēkā. Es nokļuvu politiskās nepatikšanās, un tas bija ļoti neveiksmīgi.

Bet gadu vēlāk, kad Linux kļuva atpazīstams, kļuva skaidrs, ka tur notiek kaut kas daudz savādāks un veselīgāks. Linusa atvērtā izstrādes bija pilnīgi pretēja katedrāles stila izstrādei. Linux Interneta arhīvi raisīja pumpurus un parādījās ļoti daudzas Linux versijas. Un tas viss tika veikts ar nepieredzētu sistēmas kodola laidienu biežumu.

Linuss izmantoja savus lietotājus kā līdzizstrādātājus visefektīvākajā veidā, vadoties pēc principa:

7. Izlaid ātri un bieži. Un ieklausies savos lietotājos.

Linusa jaunievedums bija ne tik daudz īsais lietotāju atsauksmju iekļaušanas cikls, (kaut kas līdzīgs Unix pasaulē pastāvēja jau labu laiku), bet gan šīs apmaiņas intensitātes samērošana ar izstrādājamā produkta sarežģītību. Tajos laikos (ap 1991. gadu) viņam nebija nekas neparasts veidot jaunu laidienu katru dienu! Un tāpēc viņš kopa savu līdzizstrādātāju pulku un iedibināja Interneta sadarbības iespējas pamatīgāk, kā jebkurš cits pirms tam. Un tas darbojās.

Bet kā tas strādāja, un vai tas bija kas tāds, ko es varētu atkārtot? Vai arī tas bija tikai un vienīgi Linusa Torvaldsa ģēnijs?

Es tā nedomāju. Skaidrs, ka Linuss ir ellišķīgi labs hakeris. Cik daudz no mums varētu izstrādāt pilnīgu produkcijas kvalitātes operētājsistēmu no nulles? Bet Linux neparādīja nekādus dievišķīgus konceptuālus lēcienus. Linuss nav (vismaz pagaidām) tik izcils dizaina ģēnijs kā piemēram, Ričards Stallmans vai Džeimss Goslings (James Gosling, NeWS un Java). Drīzāk Linuss ir izstrādes un ražošanas ģēnijs ar sesto prātu kļūdu novēršanā, izstrādes strupceļu un vieglākā ceļa atrašanā no punkta A uz punktu B. Arī viss Linux elpo un tā dizains atspoguļo Linusa noteikto konservatīvismu dizaina vienkāršošanā.

Tātad, ja īsi laidienu cikli un intensīvā Interneta iespēju iedarbināšana nebija nejaušība, bet gan Linusa izstrādes ģēnija atklāsme, kā minimizēt piepūli, ko tad viņš īsti palielināja? Ko viņš ieguva no šīs mašinērijas?

Šāds jautājums pats pasaka priekšā atbildi. Linuss nodrošināja savus lietotājus — hakerus ar pastāvīgu stimulu un atalgojumu — veicinot katra individuāla hakera darbību, un atalgojot tos ar pastāvīgu (pat ikdienas) uzlabojumu viņu darba rezultātā.

Linuss apzināti centās maksimizēt cilvēkstundu skaitu, kas pavadīts atkļūdojot un izstrādājot kodu, pat samaksājot ar iespējami nestabilu kodu un lietotāju pulka nogurdināšanu ar grūti pamanāmām kritiskām kļūdām. Linuss tā rīkojās, jo viņš ticēja, ka:

8. Ar pietiekami lielu beta testētāju un līdzizstrādātāju skaitu, praktiski jebkura problēma tiks atrasta ātri, un kādam liksies vienkārši novēršama.

Vai, vienkāršāk sakot: "Pietiekami daudziem skatieniem visas kļūdas ir acīmredzamas." Es to nosaucu par "Linusa likumu".

Mans sākotnējais formulējums bija "katra problēma kādam būs acīmredzama". Linuss iebilda, ka cilvēks, kas problēmu ir sapratis un novērsis, var nebūt, un parasti arī nav tas, kas to pirmais ir pamanījis. "Kāds problēmu atrod", viņš saka un "kāds cits to saprot. Un es uzsvērtu to, ka manuprāt, atrašana ir lielāks izaicinājums." Šis labojums ir svarīgs. Nākošajā nodaļā, kad pievērsīsimies atkļūdošanai, mēs to redzēsim. Bet galvenais ir tas, ka šī procesa abas daļas — kļūdu meklēšana un novēršana notiek ātri.

Man šķiet, Linusa likumā vislabāk parādās atšķirība starp katedrāles un tirgus izstrādes paņēmieniem. Katedrāles stila programmētājiem kļūdas un izstrādes problēmas ir sarežģītas, viltīgas un dziļas mīklas. Pirms jūs kaut ko saņemat, izstrādātāji pūlas un pucē mēnešiem. Neskatoties uz retiem laidienu cikliem, laidieni nav perfekti un vilšanās ir neizbēgama.

Tirgus stilā jūs pieņemat, ka kļūdas ir lielākoties vienkāršas — vai vismaz tās diezgan ātri kļūst vienkāršas, kad tiek pakļautas tūkstošiem līdzizstrādātāju apskatei līdz ar katru jaunu laidienu. Līdz ar to, jūs izlaižat bieži, lai iegūtu vairāk labojumu, un papildus iegūstat to, ka  mazāk zaudējat, ja pagadās izlaist arī kādu sliktu būvējumu.

Un tas arī viss. Ar to pietiek. Ja "Linusa likums" nestrādā, katrai sistēmai, kas ir tikpat sarežģīta un tiek bakstīta ar tikpat daudzām rokām kā Linux kodols, kādā brīdī būtu jāsabrūk no pašas svara, ar nesaprotamu darbību un pamatīgi ielaistām "dziļām" kļūdām. Ja tas strādā, ar to pietiek, lai izskaidrotu Linux relatīvi mazo kļūdu skaitu, kas kļūst vēl mazāks ritot mēnešiem un gadiem.

Varbūt, tam nemaz nevajadzētu būt tādam pārsteigumam. Sociologi jau daudzus gadus atpakaļ atklāja, ka vidējais masu (ar līdzvērtīgām zināšanām vai ignoranci) viedoklis ir vairāk uzticams, kā jebkura viena novērotāja viedoklis. Viņi to nosauca par Delfu efektu. Linuss ir parādījis, ka šis likums strādā arī operētājsistēmas atkļūdošanā — Delfu efekts var savaldīt pat tādu sarežģītu lietu kā operētājsistēmas kodols. (CV)

Vēl viena svarīga lieta, kas palīdz Linux gadījumā ir tas, ka, neskaitot Delfu efektu, visi projektā iesaistījušies atbalstītāji ir pieteikušies paši. Viens no respondentiem norādīja, ka atbalstītāji nav atlasīti bezmērķīgi, bet gan tie ir cilvēki, kas ir pietiekami ieinteresēti programmas izmantošanā, vēlas apgūt kā tā strādā, mēģina atrast risinājumus sastaptajām problēmām, un piedāvā acīmredzami saprātīgu risinājumu. Ļoti ticams, ka katram, kurš iztur šos nosacījumus, ir kaut kas noderīgs, ko piedāvāt.

Linusa likumu var pārfrāzēt kā "Atkļūdošana ir paralelizējama". Lai arī atkļūdošana prasa zināmu sadarbību ar izstrādātāju, tā neprasa īpašu koordināciju starp testētājiem. Līdz ar to, tā nekļūst par kvadrātisku sarežģītību un pārvaldības izmaksām, kā tas notiek ar izstrādātāju skaita palielināšanu.

Praksē teorētiskais zaudējums, ko rada testētāju atkārtoti izdarītais darbs, Linux pasaulē nekad nav bijusi problēma. Viens no "izlaid agri un bieži" politikas rezultātiem ir tas, ka ātri izlaižot kļūdu labojumus, šāds dublēts darbs ir minimizēts (JH).

Brūks (The Mythical Man-Month autors) šajā sakarā pat izvirzīja vienkāršu novērojumu: "Kopējās uzturēšanas izmaksas plaši lietotai programmai parasti ir 40 procentu vai vairāk no tās izstrādes izmaksām. Pārsteidzoši, ka šīs izmaksas būtiski nosaka lietotāju skaits. Vairāk lietotāju atrod vairāk kļūdu." (uzsvērums pievienots).

Vairāk lietotāju atrod vairāk kļūdu, jo tie izmanto vairākus programmas pārbaudes veidus. Šis efekts tiek pastiprināts, ja lietotāji ir līdzizstrādātāji. Katrs no viņiem kļūdas nosaka ar dažādiem paņēmieniem, ar dažādiem rīkiem un noteikšanas veidiem, raksturojot problēmu no dažādiem aspektiem. "Delfu efekts" darbojas precīzi tieši šīs dažādības dēļ. Kļūdu noteikšanā šādas variācijas palīdz arī samazināt darbību dublēšanos.

Līdz ar to, lai arī beta testētāju skaitu palielināšana nemazina kādas esošās "dziļās" kļūdas sarežģītību no izstrādātāja viedokļa, tas tomēr palielina varbūtību, ka kāda testētāja rīki būs atbilstoši, lai viņam šī kļūda būtu acīmredzama.

Linuss nodrošinās arī pret to, ja gadījumā ir kāda nopietna kļūda. Linux kodola versijas ir numurētas tā, ka potenciālie lietotāji var izvēlēties, vai nu lietot jaunāko stabilo versiju, vai arī izmantot pēdējo sasniegumu iegūstot jaunas iespējas, bet riskējot ar nopietnām kļūdām. Vairums Linux hakeru vēl šo taktiku sistemātiski neizmanto, bet iespējams, vajadzētu, jo piedāvātā izvēle abus variantus padara atraktīvākus. (HBS)