Ši knyga yra toks hitas, kad nėra paprasta rasti kitą knygą apie programų sistemų inžineriją (PSI), kuri nenukreiptų, nesiremtų arba neprieštrautų teiginiams pristatytiems šiame F. Brooks veikale. Originalus leidimas yra...
Ši knyga yra toks hitas, kad nėra paprasta rasti kitą knygą apie programų sistemų inžineriją (PSI), kuri nenukreiptų, nesiremtų arba neprieštrautų teiginiams pristatytiems šiame F. Brooks veikale. Originalus leidimas yra datuotas 1975 metais. Tie metai gali būti vaizdžiai apibūdinti kaip kompiuterijos mokslo priešaušrė. Tais laikais asmeninis kompiuterio idėja būtų buvusi tikkama tik memui su Yao Mingu, o kiekvienam naujam kompiuteriui kurdavo ir naują operacinę sistemą, nes senos netikdavo.
Toliau pasakosiu ne tiek tai, kas yra rašoma knygoje, bet daugiau tai, ką veik savarankiškai sugalvojau vis bevartydamas (arba scroll'indamas (vis tik išmaniajame skaičiau)) knygos puslapius ir besižvagydamas pro autobusų ir traukinių langus.
Tikėtina, kad programų sistemų kūrimas gali būti suprantamas, kaip veikla orientuota į artefaktų kūrimą. Nieko čia stebuklingo, liaudies menininkas drožiantis medinius šaukštus irgi kuria artefaktus. Tik, mano galva, esminis skirtumas tarp programuotojų ir liaudies menininkų yra tas, kad liaudies menininkas turi krūvas apribojimų, kurių pas programuotoją tiesiog nėra arba jie gali būti įvairiai apeinami.
Pavyzdžiui, abu mūsų lyriniai herojai (tarkim, programuotojas Tomas ir liaudies menininkas Lukas) modeliuoja prototipą ąžuolinių šaukštų gamybai. Liaudies menininkas Lukas yra reikalingas specifinės žaliavos savo ąžuolinių šaukštų modeliui, t.y. ąžuolo medienos. Programuotojo Tomo žaliava jo ažuolinių šaukštų modeliui yra Coca-Cola ir čeburėkai arba koks kitas skanėstas. Taip, iš esmės niekas susijęs su kompiuteriais nėra apribojimas ąžuolinių šaukštų modeliavimui kompiuteriu apart paties kompiuterio.
Norėdamas parodyti, kad kompiuteris yra pakankamas Tomo užduočiai galėčiau plėstis, kad konceptuoliai kompiuteris, kaip universalios Tiuringo mašinos implementacija, gali simuliuoti bet kitą specifinę (ar kitą universalią) Tiuringo mašiną (think, ąžuolinių šaukštų modeliavimo Tiuringo mašina), kuri yra algoritmas, kas yra tik instrukcijų seka, kurią va taip paprastai klaviatūra Tomas ima ir surenka, bet nesiplėsiu.
Knygos autorius kelia tokią idėją, kad apribojimai (arba suvaržymai) kūrybinėje veikloje daro tą veiklą paprastesne. Čia tą paprastumą reikia suprasti iš tos perspektyvos, kad kūrėjui reikia priimti mažiau lokalių sprendimų (apribota sprendimų aibė, pvz. Lukui nereikia sukti galvos kokią medieną naudoti), o tai sumažina protinę apkrovą ir dėl to yra lengviau kurti. Kadangi nutarėm, jog programuotojas yra labai silpnai apribotas, tai jis turi priimti daug lokalių sprendimų apie visokias smulkmenas (t.y. kaip save apriboti), o tai didina protinę apkrovą, kas reiškia, kad veiklą galima laikyti sudėtinga.
To make matters worse, tarkime, kad turime programuotojų komandą, kuriai reikia sulipdyti kažkokią didelę sistemą, kurią vienam programuotojui sukurti užtruktų labai ilgai, think, kur du stos visada daugiau padarys. Kadangi galime įsivaizduoti, kad kiekvienas programuotojas turi sąlyginai mažai apribojimų ir gali užduotį atlikti daugybe vienas už kitą elegantiškesnių (arba šlykštesnių), bet tarpusavyje skirtingų būdų (čia splypi ir vienas iš esminių programavimo džiaugsmų), tačiau tuo pat metu reikia turėti omenyje, kad galų gale programos gabalai turi būti sulipdyti į vieną kūną. Šis aspektas užkrauna didelę apkrovą komunikacijai tarp komandos narių, nes reikia suderinti, kaip galų gale turi atrodyti tie gabalai. Idealiu atveju, visi turi žinoti visus lokalius sprendimus (kitaip tariant, visi dėl visko kartu susitarė ir taip apsiribojo sprendimų aibę), tada galima tikėtis sklandaus darbo. Bet ta kiaulė realybė čia kiša koją, nes beveik niekada to nepavyksta padaryti: būna, kad kažkas kažko nesupranta, būna prieštarauja, būna užmiršta, būna, kad pagrindinis architektas išeina atostogų, arba tiesiog netelpa visos detalės vienoje galvoje... Taip ir gimė poreikis visai disciplinai vardu programų sistemų inžinerija, kurios pačioje aušroje F. Brooks ir vadovavo dideliems programinės įrangos kūrimo projektams.
Pirmame skyriuje autorius vaizdžiai programų sistemų kūrimą palygina pasilakstymui po lakiojo smėlio karjerą: gražiausi ir stipriausi bandė, bet Fortūna ko tais jiems šypsenos nerodė. Taigi, tie, kurie sako, kad žino, kaip reikia daryti programų sistemas, tai jie giliai širdyje patys žino kitą dalyką, jog jie nežino kaip tai reikia daryti, o tik kuria iliuziją, kurią daugiau ar mažiau sėkmingai pardavinėja.
Jubiliejiniame leidime yra keturi nauji skyriai. Be žymiojo "No Silver Bullet", kuris tiesiai šviesiai rėžia į akis, kad artimiausioje ateityje nesimato jokių būdų kaip padidinti programuotojų produktyvumą bent jau dešimteriopai, yra ir skyrius kuris susumuoja visą pirmąjį leidimą. Šį skyrių pavadinčiau lengvu ir įperkamu būdu susipažinti su pagrindinėmis autoriaus tezėmis išdėstytomis pirmajame leidime (arba pirmuose 177 jubiliejinio leidimo puslapiuose). Maža to, prie kai kurių tezių yra ir komentarai. Kai kurie jų sako, kad laikas (20 metų) parodė tezės klaidingumą (pvz. PL/1 jau nėra vienintelė programavimo kalba tinkama "for system programming" (nežinau kaip išverst)). Taip, kad yra pateikti keli galimi variantai susipažinti su knygos idėjomis.
Vietoje pabaigos (nes juk reikia pabaigos?), pasikartosiu, kad knygos idėjos tikrai vertos visų tų momentų su itemptais tais veido raumenimis, kurie sukuria surauktų antakių vaizdą. Gero skaitymo!
rodyti daugiau