azin i kupit' uzhe gotovym to, chto oni sobirayutsya razrabotat'. |to ne shutka: dostupnost' deshevyh i moshchnyh korobochnyh programm udovletvorila mnogie iz potrebnostej, ranee udovletvoryavshihsya zakaznymi programmami. |ti elektroinstrumenty dlya uma bol'she pohozhi na elektricheskte dreli, pily i shlifoval'nye mashiny, chem na bol'shie i slozhnye proizvodstvennye stanki. Integraciya ih v sovmestimye i perekrestno-svyazannye nabory, takie kak Microsoft Works ili luchshe integrirovannyj ClarisWorks, obespechivaet ogromnuyu gibkost'. I podobno domashnej kollekcii instrumenta, v rezul'tate chastogo ispol'zovaniya nabol'shogo nabora dlya raznyh zadach vyrabatyvayutsya privychnye navyki. Takoj instrument podcherkivaet prostotu ispol'zovaniya obychnym pol'zovatelem, dazhe ne professionalom. Ivan Selin (Ivan Selin), glava American Management Systems pisal mne v 1987 godu: YA hochu pridrat'sya k vashemu utverzhdeniyu, chto v dejstvitel'nosti pakety ne nastol'ko izmenilis'... YA dumayu, chto vy slishkom legko otbrosili glavnye sledstviya vashego zamechaniya, chto (programmnye pakety) "mogut byt' nemnogo bolee obshchimi i nemnogo luchshe nastraivaemymi, chem ran'she, no ne namnogo". Dazhe prinimaya eto zayavlenie za chistuyu monetu, ya polagayu, chto pol'zovateli rascenivayut pakety, kak obladayushchie bolee shirokimi vozmozhnostyami i legche nastraivaemye, i chto takoe vospriyatie delaet pol'zovatelej bolee podatlivymi pered paketami. V bol'shinstve sluchaev, izvestnyh moej kompanii, ne programmisty, a (konechnye) pol'zovateli neohotno pol'zuyutsya paketami, pokskol'ku dumayut, chto lishatsya vazhnyh vozmozhnostej i funkcij, a potomu vozmozhnost' legkoj nastrojki ves'ma povyshaet dlya nih privlekatel'nost' produkta. YA dumayu, chto Selin sovershenno prav: ya nedoocenil kak stepen' nastraivaemosti paketa, tak i vazhnost' etogo faktora. Ob容ktno-orientirovannoe programmirovanie: a medna pulya ne podojdet? Razrabotka iz bol'shih chastej. Esli osushchestvlyat' sborku iz chastej, kotorye dostatochno slozhny i imeyut odnorodnye interfejsy, mozhno bystro obrazovyvat' dovol'no bogatye struktury. Soglasno odnomu iz vzglyadov na ob容ktno-orientirovannoe programmirovanie eta disciplina osushchestvlyaet modul'nost' i chistye interfejsy. Drugaya tochka zreniya podcherkivaet inkapsulyaciyu - nevozmozhnost' uvidet' i eshche menee izmenit' vnutrennyuyu strukturu detali. Eshche odna tochka zreniya otmechaet nasledovanie i soputstvuyushchuyu emu ierarhicheskuyu strukturu klassov s virtual'nymi funkciyami. I eshche odin vzglyad: vazhnejshej yavlyaetsya sil'naya abstraktnaya tipizaciya dannyh vmeste s garantiyami, chto konkretnyj tip dannyh budet obrabatyvat'sya tol'ko primenimymi k nemu operaciyami. V nastoyashchee vremya ne nuzhen ves' paket Smalltalk ili C++, chtoby ispol'zovat' lyuboj iz etih disciplin - mnogie iz nih poglotili ob容ktno-orientirovannye tehnologii. Ob容ktno-orientirovannyj podhod privlekatelen, kak polivitaminy: odnim mahom (t.e. perepodgotovkoj programmista) poluchaesh' vse. Ochen' mnogoobeshchayushchaya koncepciya. Pochemu ob容ktno-orientirovannaya tehnologiya medlenno razvivalas'? V techenie devyati let posle vyhoda "SPN" nadezhdy neuklonno rosli. Pochemu razvitie bylo takim medlennym? Teorij mnogo. Dzhejms Koggins, v techenie chetyreh let vedushchij kolonku v The C++ Report, daet takoe ob座asnenie: Problema v tom, chto programmisty, rabotayushchie v OOP, eksperimentirovali s krovosmesitel'nymi prilozheniyami i byli naceleny na nizkij uroven' abstrakcii. Naprimer, oni stroili takie klassy, kak "svyazannyj spisok" vmesto "interfejs pol'zovatelya", ili "luch radiacii", ili "model' iz konechnyh elementov". K neschast'yu, strogaya proverka tipov, kotoraya pomogaet programmistam C++ izbegat' oshibok, odnovremenno zatrudnyaet postroenie bol'shih ob容ktov iz malen'kih.21 On vozvrashchaetsya k fundamental'noj probleme programmirovaniya i dokazyvaet, chto odin iz sposobov udovletvorit' potrebnost' v programmnom obespechenii - uvelichit' chislennost' obrazovannoj rabochej sily putem podgotovki i privlecheniya nashih klientov. V pol'zu nishodyashchego proektirovaniya privodyatsya takie argumenty: Esli my proektiruem krupnye klassy, predstavlyayushchie koncepcii, s kotorymi nashi klienty uzhe rabotayut, to oni v sostoyanii ponimat' i kritikovat' proekt po mere ego razvitiya, a takzhe vmeste s nami razrabatyvat' kontrol'nye primery. Oftal'mologov, s kotorymi ya rabotayu, ne volnuet organizaciya steka; ih volnuet opisanie formy rogovicy s pomoshch'yu polinomov Lezhandra. Malen'kaya inkapsulyaciya daet i malen'kuyu vygodu. Devid Parnas, ch'ya stat'ya byla odnim iz istochnikov idej ob容ktno- orientirovannogo programmirovaniya, smotryat na veshchi po inomu. On pisal mne: Otvet prost. |to iz-za privyazannosti OOP k slozhnym yazykam. Vmesto ob座asneniya lyudyam, chto OOP yavlyaetsya vidom proektirovaniya, i vooruzheniya ih principami proektirovaniya, ih uchili, chto OOP - eto ispol'zovanie opredelennogo instrumenta. Lyubymi sradstvami mozhno pisat' i plohie, i horoshie programmy. Esli ne uchit' lyudej proektirovaniyu, to yazyki ne imeyut bol'shogo znacheniya. Rezul'tatom budut plohie razrabotki s pomoshch'yu etih yazykov i malaya vygoda. A esli vygoda nevelika, to OOP ne vojdet v modu. Rashody sejchas, pribyl' potom. Po moemu mneniyu, u ob容ktno-orientirovannyh metodologij osobenno tyazhelyj sluchaj bolezni, harakternoj dlya mnogih usovershenstvovanij v metodologii. Ves'ma sushchestvenny predvaritel'nye izderzhki - v osnovnom, chtoby nauchit' programmistov myslit' sovershenno po novomu, a takzhe na preobrazovanie funkcij v obobshchennye klassy. Vygody, kotorye ya schitayu real'nymi, a ne chisto predpolozhitel'nymi, dostigayutsya vo vremya vsego cikla razrabotki, no nastoyashchaya okupaemost' proishodit pri razrabotke posleduyushchih programm, rasshirenii i soprovozhdenii. Koggins kovorit: "Ob容ktno-orientirovannoe programmirovanie ne uskorit razrabotku pervogo proekta, tak zhe kak i vtorogo. A vot pyatyj proekt iz togo zhe semejstva budet sdelan ochen' bystro."22 Riskovat' real'nymi nachal'nymi den'gami radi predpolagaemyh, no neopredelennyh pribylej v budushchem - eto to, chem investory zanimayutsya izo dnya v den'. Odnako vo mnogih programmiruyushchih organizaciyah menedzheram trebuetsya dlya etogo smelost' - kachestvo bolee redkoe, chem kompetenciya v tehnicheskih voprosah ili administrativnoe masterstvo. YA polagayu, chto krajnyaya stepen' avansiroaniya rashodov i otkladyvaniya pribyli yavlyaetsya samym sushchestvennym faktorom, zamedlyayushchim prinyatie O-O tehnologij. No dazhe v takih usloviyah C++, pohozhe, uverenno vytesnyaet C vo mnogih organizaciyah. CHto s povtornym ispol'zovaniem? Luchshij sposob spravit'sya s razrabotkoj chasti programmnoj sistemy, otnosyashchejsya k ee sushchnosti - eto voobshche ee ne razrabatyvat'. Pakety programm - odin iz sposobov sdelat' eto. Drugoj sposob - povtornoe ispol'zovanie. Dejstvitel'no, odnoj iz naibolee privlekatel'nyh chert ob容ktno-orientirovannogo programmirovaniya yavlyaetsya obeshchanie prostoty povtornogo ispol'zovaniya klassov v sochetanii s legkost'yu nastrojki blagodarya nasledovaniyu. Kak chasto byvaet, posle polucheniya nekotorogo opyta raboty po novoj tehnologii obnaruzhivaetsya, chto ona ne tak prosta, kak kazalos' na pervyj vzglyad. Konechno, programmisty vsegda povtorno ispol'zovali sobstvennye razrabotki. Dzhons pishet: U naibolee opytnyh programmistov est' svoi lichnye biblioteki, pozvolyayushchie im pri razrabotke novyh programm povtorno ispol'zovat' do 30% koda po ob容mu. Na korporativnom urovne povtornoe ispol'zovanie priblizhaetsya k 75% po ob容mu i trebuet special'nyh bibliotek i administrirovaniya. Povtornoe ispol'zovanie koda v korporativnyh masshtabah trebuet izmenenij v buhgalterii proekta i metodah izmereniya raboty.23 U. Huan (W. Huang) predlozhil organizaciyu programmnogo proizvodstva s matrichnoj strukturoj upravleniya funkcional'nymi specialistami, chtoby derzhat' pod kontrolem ih estestvennuyu sklonnost' k povtornomu ispol'zovaniyu sobstvennogo koda.24 Van SHnajder (Van Snyder) iz JPL napominaet mne, chto v krugah razrabotchikov matematicheskogo programmnogo obespecheniya sushchestvuet davnyaya tradiciya povtornogo ispol'zovaniya programm: My polagaem, chto prepyatstviya k povtornomu ispol'zovaniyu voznikayut ne so storony proizvoditelya, a so storony potrebitelya. Esli razrabotchik programmnogo obespecheniya - potencial'nyj potrebitel' standartnyh programmnyh komponentov - schitaet, chto najti i proverit' nuzhnyj komponent dorozhe, chem napisat' ego zanovo, znachit, budet napisan novyj komponent, dubliruyushchij prezhnij. Obratite vnimanie, my skazali "schitaet" - real'naya stoimost' povtornoj razrabotki ne imeet znacheniya. Povtornoe ispol'zovanie koda imeet uspeh pri razrabotke matematicheskih programm. Prichin etomu dve: 1) eto magiya, trebuyushchaya ogromnogo intellektual'nogo vklada v kazhduyu strochku koda, i 2) sushchestvuet bogataya i standartnaya terminologiya, a imenno - matematika, dlya opisaniya funkcional'nosti lyubyh komponentov. Poetomu povtorno razrabotat' matematicheskij komponent stoit dorogo, a razobrat'sya v funkcional'nosti stoit deshevo. Davnyaya tradiciya publikacii i sbora algoritmov professional'nymi zhurnalami i predlozheniya ih po umerennoj cene, a takzhe kommercheskoe predlozhenie vysokokachestvennyh algoritmov po neskol'ko bolee vysokoj, no vse zhe skromnoj cene, delayut poisk trebuemyh komponentov proshche, chem v drugih oblastyah, gde chasto nevozmozhno tochno i szhato opisat' trebuemoe. Blagodarya sovmestnomu dejstviyu etih faktorov povtornoe ispol'zovanie matematicheskih programm bolee privlekatel'no, chem povtornoe ih izobretenie. Takoe zhe yavlenie povtornogo ispol'zovaniya obnaruzhivaetsya i v drugih soobshchestvah, naprimer, v razrabotke programm dlya atomnyh reaktorov, modelirovaniya klimata, modelirovaniya okeanov - po tem zhe samym prichinam. Kazhdoe iz etih soobshchestv vyroslo na odnih i teh zhe uchebnikah, s odnoj i toj zhe sistemoj oboznachenij. Kak segodnya obstoyat dela s povtornym ispol'zovaniem na korporativnom urovne? Provedeno mnozhestvo issledovanij, a vot praktikuetsya v SSHA otnositel'no malo. CHto zhe kasaetsya povtornogo ispol'zovaniya za rubezhom, to tut imeyut mesto nepravdopodobnye otchety.25 Dzhons soobshchaet, chto vse klienty ego firmy, u kotoryh bolee 5000 programmistov, provodyat formal'nye issledovaniya povtornoj ispol'zuemosti, v to vremya kak iz chisla klientov s 500 i menee programmstami eto delaet menee 10 procentov.26 Po ego soobshcheniyu, v otraslyah s vysokim potencialom povtornogo ispol'zovaniya issledovaniya (ne realizaciya) "vedutsya aktivno i energichno, dazhe esli ne vpolne uspeshno". |d Jordon soobshchaet o programmnoj firme v Manile, v kotoroj 50 programmistov iz obshchego chisla 200 zanyaty tol'ko razrabotkoj povtorno ispol'zuemyh modulej dlya ispol'zovaniya vsemi ostal'nymi, i chto v teh sluchayah, kotorye on videl, prinyatie etoj tehnologii bylo vyzvano organizacionnymi, a ne tehnicheskimi faktorami - naprimer, sistemoj pooshchrenij. Demarko soobshchaet mne, chto nalichie massovyh rynochnyh paketov i vozmozhnost' predostavleniya imi obshchih funkcij, takih kak sistemy baz dannyh, sushchestvenno snizili kak nastoyatel'nost', tak i predel'nuyu poleznost' povtornogo ispol'zovaniya modulej sobstvennyh prilozhenij. "Povtorno ispol'zuemye moduli imeli tendenciyu v konce koncov stanovit'sya obshchimi funkciyami." Parnas pishet sleduyushchee: Povtornoe ispol'zovanie - eto to, o chem legche govorit', chem osushchestvit'. Dlya nego trebuyutsya kak horoshee proektirovanie, tak i ochen' horoshaya dokumentaciya. Dazhe kogda my vidim horoshee proektirovanie, chto po- prezhnemu ne chasto, bez horoshej dokumentacii komponenty ne budut ispol'zovat'sya povtorno. Ken Bruks soobshchaet, chto trudno rasschitat', kakaya stepen' obobshchennosti okazhetsya neobhodimoj: "Mne prihoditsya menyat' veshchi, dazhe v pyatyj raz ispol'zuya sobstvennuyu biblioteku pol'zovatel'skih interfejsov." Real'no povtornoe ispol'zovanie tol'ko nachinaetsya. Dzhons soobshchaet, chto na otkrytom rynke est' neskol'ko modulej s povtorno ispol'zuemym kodom po cene ot 1 do 20 procentov ot obychnoj stoimosti razrabotki.27 Demarko govorit: Menya vse bolee obeskurazhivaet vsya eta istoriya s povtornym ispol'zovaniem. Prakticheski otsutstvuet teorema sushchestvovaniya dlya povtornogo ispol'zovaniya. Vremya podtverdilo, chto sdelat' veshchi povtorno ispol'zuemymi stoit dorogo. Jordon daet ocenku togo, skol'ko eto stoit: "Horoshee empiricheskoe pravilo govorit, chto povtorno ispol'zuemye komponenty potrebuyut vdvoe bol'shih zatrat, chem "odnorazovye" komponenty."28 YA rassmatrivayu etu cenu kak velichinu zatrat na zapusk komponentov v proizvodstvo, obsuzhdavshuyusya v glave 1, poetomu ya ocenivayu rost zatrat kak troekratnyj. Konechno, my vidim razlichnye formy i varianty povtornogo ispol'zovaniya, no ono daleko ne tak shiroko primenyaetsya, kak my predpolagali. Predstoit eshche mnogoe ponyat'. Ponimanie bol'shih slovarej: neozhidannaya problema povtornogo ispol'zovaniya, kotoruyu mozhno bylo predvidet' CHem vyshe uroven', na kotorom osushchestvlyaetsya myshlenie, tem bolee mnogochislenny primitivnye sostavlyayushchie mysli, s kotorymi prihoditsya imet' delo. Tak, yazyki vysokogo urovnya gorazdo slozhnee mashinnyh yazykov, a estestvennye yazyki eshche bolee slozhny. U yazykov vysokogo urovnya bol'she slovari, bolee slozhnyj sintaksis i bolee strogaya semantika. Kak nauchnaya disciplina, my ne vzvesili posledstviya etogo fakta dlya povtornogo ispol'zovaniya programm. CHtoby povysit' kachestvo i proizvoditel'nost', my hotim stroit' programmy iz chastej s otlazhennymi funkciyami, kotorye sushchestvenno vyshe po urovnyu, chem operatory yazykov programmirovaniya. Poetomu, delaem li my eto s pomoshch'yu bibliotek klassov ili bibliotek procedur, nam pridetsya stolknut'sya s rezkim uvelicheniem razmerov nashih slovarej programmirovaniya. Izuchenie slovarya sostavlyaet znachitel'nuyu chast' prepyatstvij k povtornomu ispol'zovaniyu. Na segodnyashnij den' est' biblioteki klassov, naschityvayushchie svyshe 3000 chlenov. Mnogie ob容kty trebuyut zadaniya ot 10 do 20 parametrov i peremennyh- pereklyuchatelej. Vsyakij, ispol'zuyushchij takuyu biblioteku, dolzhen izuchit' sintaksis (vneshnie interfejsy) i semantiku (podrobnoe povedenie funkcii) ee chlenov, esli sobiraetsya polnost'yu realizovat' potencial povtornogo ispol'zovaniya. |ta zadacha vovse ne beznadezhna. Obychno chelovek ispol'zuet okolo 10000 slov rodnogo yazyka, obrazovannye lyudi - znachitel'no bol'she. Kakim-to obrazom my obuchaemsya sintaksisu i tonkim semanticheskim razlichiyam. My pravil'no operedelyaem razlichiya mezhdu slovami gigantskij, ogromnyj, prostrannyj, kolossal'nyj, gromadnyj - nikto ne govorit o kolossal'nyh pustynyah i prostrannyh slonah. Nuzhny dopolnitel'nye issledovaniya, chtoby mozhno bylo primenit' k probleme povtornogo ispol'zovaniya programm sushchestvuyushchie znaniya o tom, kak lyudi ovladevayut yazykom. Nekotorye vyvody neposredstvenno ochevidny: - Obuchenie proishodit v kontekste predlozheniya, poetomu nuzhno publikovat' mnogochislennye primery sostavnyh produktov, a ne prosto biblioteki sostavlyayushchih chastej. - CHelovek zapominaet tol'ko pravopisanie. Sintaksis i semantika izuchayutsya postepenno, v kontekste, putem primeneniya. - CHelovek gruppiruet pravila soedineniya slov v sintaksicheskie klassy, a ne v sovmestimye podmnozhestva ob容ktov. CHistyj itog po pulyam: polozhenie prezhnee Itak, my vozvrashchaemsya k osnovam. Slozhnost' - eto to, chem my zanimaemsya, i slozhnost' - eto to, chto nas ogranichivaet. R. L. Glass (R. L. Glass) pisal v 1988 godu, tochno summiruya moi vzglyady 1995 goda: Tak chto zhe v itoge soobshchili nam Parnas i Bruks? CHto razrabotka programm yavlyaetsya konceptual'no slozhnym zanyatiem. CHto volshebnye resheniya ne lezhat za kazhdym uglom. CHto zanimayushchimsya etim delom pora izuchit' dostizheniya, imeyushchie evolyucionnyj harakter, a ne zhdat' revolyuciyu i ne nadeyat'sya na nee. Nekotorye schitayut eto bezradostnoj kartinoj. |to te, kto polagal, chto vot-vot nastupit proryv. No nekotorye iz nas - dostatochno svarlivye, chtoby schitat' sebya realistami, - otnosyatsya k etomu kak k glotku svezhego vozduha. Nakonec-to mozhno sosredotochit'sya na chem-to bolee blizkom k zhizni, chem zhuravl' v nebe. Teper', veroyatno, my smozhem zanyat'sya postepennymi usovershenstvovaniyami proizvodstva programmnogo obespecheniya, kotorye dejstvitel'no dostizhimy, a ne zhdat' proryvov, kotorye vryad li kogda-libo proizojdut.29 Glava 18. Zayavleniya "Mificheskogo cheloveko-mesyaca": pravda ili lozh'? Kratkost' ochen' polezna, Kogda nas ponimayut ili ne ponimayut. S|MYU|L BATLER, "GUDIBRAS" Segodnya o tehnike razrabotki programmnogo obespecheniya izvestno znachitel'no bol'she, chem v 1975 godu. Kakie iz utverzhdenij, soderzhashchihsya v pervom izdanii 1975 goda, podtverdilis' opytom i dannymi? Kakie byli oprovergnuty? Kakie ustareli v nashem izmenchivom mire? CHtoby vam legche bylo sudit', zdes', v vide svodki, privedeny vazhnejshie utverzhdeniya knigi 1975 goda, kotorye ya schital vernymi: fakty i izvlechennye iz opyta prakticheskie pravila, privedennye s sohraneniem iznachal'nogo smysla. (Mozhno zadat'sya voprosom: esli eto vse, chto bylo skazano v pervonachal'nom izdanii, pochemu togda eto zanyalo tak mnogo mesta?) V skobkah privedeny svezhie kommentarii. Bol'shinstvo etih predlozhenij mozhno proverit' na praktike. Izlagaya ih v szhatoj forme, ya nadeyus' skoncentrirovat' mysli chitatelya, izmereniya i kommentarii. Glava 1. Smolyanaya yama 1.1 Dlya sozdaniya sistemnogo programmnogo produkta trebuetsya primerno v devyat' raz bol'she usilij po sravneniyu s sostavlyayushchimi ego programmami, napisannymi otdel'no dlya chastnogo ispol'zovaniya. Po moej ocenke, prevrashchenie programmy v produkt vvodit koefficient, ravnyj trem; proektirovanie, integraciya i testirovanie komponentov, kotorye dolzhny obrazovat' soglasovannuyu sistemu, takzhe vvodit koefficient, ravnyj trem; vse eti sostavlyayushchie stoimosti sushchestvenno nezavisimy drug ot druga. 1.2 Zanyatie programmirovaniem "otvechaet glubokoj vnutrennej potrebnosti v tvorchestve i udovletvoryaet chuvstvennye potrebnosti, kotorye est' u vseh u nas", dostavlyaya pyat' vidov radosti: - Radost', poluchaemaya pri sozdanii chego-libo svoimi rukami. - Udovol'stvie sozdavat' veshchi, kotorye mogut byt' polezny drugim lyudyam. - Ocharovanie sozdaniya slozhnyh golovolomnyh ob容ktov, sostoyashchih iz vzaimodejstvuyushchih dvizhushchihsya chastej. - Radost', poluchaemaya ot neizmennogo uznavaniya novogo, nepovtoryaemosti zadachi. - Udovol'stvie ot raboty so stol' podatlivym materialom - chistoj mysl'yu, kotoryj, tem ne menee, sushchestvuet, dvizhetsya i rabotaet tak, kak ne mogut slovesnye ob容kty. 1.3 V to zhe vremya etomu zanyatiyu prisushchi i ogorcheniya: - Pri izuchenii programmirovaniya trudnee vsego privyknut' k trebovaniyu sovershenstva. - Postanovka zadach osushchestvlyaetsya drugimi lyud'mi i prihoditsya zaviset' ot veshchej (osobenno, programm), kotorye nel'zya kontrolirovat'; polnomochiya ne sootvetstvuyut otvetstvennosti. - Strashno tol'ko na slovah: fakticheskaya vlast' priobretaetsya kak sledstvie uspeshnogo vypolneniya zadach. - Programmnyj proekt priblizhaetsya k okonchatel'nomu vidu tem medlennee, chem blizhe okonchanie, hotya kazhetsya, chto k koncu shodimost' dolzhna byt' bolee bystroj. - Programmnomu produktu grozit ustarevanie eshche do ego zaversheniya. Nastoyashchij tigr - ne para bumazhnomu, esli trebuetsya real'noe ispol'zovanie. Glava 2. Mificheskij cheloveko-mesyac 2.1 Programmnye proekty chashche provalivayutsya iz-za nehvatki kalendarnogo vremeni, chem po vsem ostal'nym prichinam, vmeste vzyatym. 2.2 CHtoby prigotovit' vkusnuyu pishchu, nuzhno vremya; nekotorye zadachi nel'zya uskorit', ne isportiv rezul'tat. 2.3 Vse programmisty yavlyayutsya optimistami: "Vse budet horosho". 2.4 Poskol'ku programmist rabotaet s chistymi ideyami, my ne ozhidaem osobyh trudnostej pri realizacii. 2.5 No sami nashi idei byvayut oshibochnymi - otsyuda i oshibki v programmah. 2.6 Nashi metody ocenivaniya, osnovannye na uchete zatrat, smeshivayut zatraty s poluchennym rezul'tatom. CHeloveko-mesyac yavlyaetsya oshibochnym i opasnym zabluzhdeniem, poskol'ku predpolagaet, chto mesyacy i kolichestvo lyudej mozhno menyat' mestami. 2.7 Razdelenie zadachi mezhdu neskol'kimi lyud'mi vyzyvaet dopolnitel'nye zatraty na obuchenie i obmen informaciej. 2.8 Moe prakticheskoe pravilo: 1/3 vremeni - na proektirovanie, 1/6 - na napisanie programmy, 1/4 - na testirovanie komponentov i 1/4 - na sistemnoe testirovanie. 2.9 Kak nauchnoj discipline nam ne hvataet metodov ocenki. 2.10 Poskol'ku my ne uvereny v svoih ocenkah srokov raboty, nam chasto ne dostaet smelosti upryamo otstaivat' ih pod nazhimom rukovodstva i klientov. 2.11 Zakon Bruksa: esli proekt ne ukladyvaetsya v sroki, to dobavlenie rabochej sily zaderzhit ego eshche bol'she. 2.12 Dobavlenie rabochej sily uvelichivaet obshchij ob容m zatrat tremya putyami: trud po perekraivaniyu zadach i proishodyashchee pri etom narushenie raboty, obuchenie novyh lyudej, dopolnitel'noe obshchenie. Glava 3. Operacionnaya brigada 3.1 Samye luchshie programmisty-professionaly v 10 raz produktivnee slabyh pri ravnoj podgotovke i dvuhletnem stazhe (Sakman, Grant i |rikson). 3.2 Dannye Sakmana, Granta i |riksona ne vyyavili korrelyacii mezhdu opytom i produktivnost'yu. YA dumayu, chto eto vsegda tak. 3.3 Luchshe vsego imet' malen'kuyu aktivnuyu komandu - kak mozhno men'she myslitelej. 3.4 CHasto luchshe vsego, esli komanda sostoit iz dvuh chelovek, odin iz kotoryh yavlyaetsya liderom. (Obratite vnimanie, kak Bogom zaduman brak.) 3.5 Dlya sozdaniya dejstvitel'no krupnyh sistem malen'kaya aktivnaya komanda rabotaet slishkom medlenno. 3.6 Opyt razrabotki bol'shinstva dejstvitel'no bol'shih sistem pokazyvaet, chto podhod k uskoreniyu s pozicij gruboj sily okazyvaetsya dorogostoyashchim, medlennym, neeffektivnym i privodit k poyavleniyu sistem, ne yavlyayushchihsya konceptual'no celostnymi. 3.7 Organizaciya po tipu hirurgicheskih brigad s glavnym programmistom predlagaet sposob dostizheniya celostnosti produkta blagodarya ego proektirovaniyu v neskol'kih golovah i obshchej produktivnosti blagodarya nalichiyu mnogochislennyh pomoshchnikov pri radikal'no sokrashchennom obmene informaciej. Glava 4. Aristokratiya, demokratiya i sistemnoe proektirovanie 4.1 "Konceptual'naya celostnost' yavlyaetsya naibolee vazhnym soobrazheniem pri proektirovanii sistem." 4.2 "Okonchatel'nuyu ocenku proektu sistemy daet otnoshenie funkcional'nosti k slozhnosti koncepcij", a ne tol'ko bogatstvo funkcij. (|to sootnoshenie yavlyaetsya meroj prostoty ispol'zovaniya, prigodnoj kak dlya prostogo, tak i dlya slozhnogo ispol'zovaniya.) 4.3 Dlya dostizheniya konceptual'noj celostnosti proekt dolzhen sozdavat'sya odnim chelovekom ili gruppoj edinomyshlennikov. 4.4 "Otdelenie razrabotki arhitektury ot realizacii yavlyaetsya effektivnym sposobom dostizheniya konceptual'noj celostnosti pri rabote nad ochen' bol'shimi proektami." (I malen'kimi tozhe.) 4.5 "Esli vy hotite, chtoby sistema obladala konceptual'noj celostnost'yu, kto- to odin dolzhen vzyat' rukovodstvo koncepciyami. |to aristokratizm, kotoryj ne nuzhdaetsya v izvineniyah." 4.6 Disciplina polezna iskusstvu. Poluchenie arhitektury izvne usilivaet, a ne podavlyaet tvorcheskuyu aktivnost' gruppy ispolnitelej. 4.7 Konceptual'no celostnye sistemy bystree razrabatyvayutsya i testiruyutsya. 4.8 Proektirovanie arhitektury, razrabotku i realizaciyu mozhno v znachitel'noj mere osushchestvlyat' parallel'no. (Proektirovanie apparatnogo i programmnogo obespecheniya tozhe mogut prohodit' parallel'no.) Glava 5. |ffekt vtoroj sistemy 5.1 Svyaz', ustanovlennaya na rannih etapah i prodolzhayushchayasya nepreryvno, mozhet dat' arhitektoru vernuyu ocenku stoimosti, a razrabotchiku - uverennost' v proekte, ne snimaya pri etom chetkogo razgranicheniya sfer otvetstvennosti. 5.2 Kak arhitektoru uspeshno vliyat' na realizaciyu: - Pomnit', chto otvetstvennost' za tvorchestvo, proyavlyaemoe pri realizacii, neset stroitel', poetomu arhitektor tol'ko predlagaet. - Vsegda byt' gotovym predlozhit' nekotoryj sposob realizacii svoih zamyslov i byt' gotovym soglasit'sya s lyubym drugim sposobom, kotoryj ne huzhe. - Vydvigaya takie predlozheniya, dejstvovat' tiho i chastnym obrazom. - Ne rasschityvat' na priznatel'nost' za predlozhennye usovershenstvovaniya. - Vyslushivat' predlozheniya razrabotchikov po usovershenstvovaniyu arhitektury. 5.3 Iz vseh proektiruemyh sistem naibol'shuyu opasnost' predstavlyaet vtoraya po schetu; obychno ee prihoditsya pereproektirovat' zanovo. 5.4 OS/360 yavlyaetsya yarkim primerom effekta vtoroj sistemy. (Pohozhe, chto Windows NT - eto primer dlya 1990 goda.) 5.5 Dostojnoj vnimaniya praktikoj yavlyaetsya predvaritel'noe naznachenie funkciyam velichin v bajtah i mikrosekundah. Glava 6. Donesti slovo 6.1 Dazhe v bol'shoj komande proektirovshchikov oformlenie rezul'tatov nuzhno poruchit' odnomu ili dvum lyudyam, chtoby obespechit' soglasovannost' mini- reshenij. 6.2 Vazhno yavno opredelit' te chasti arhitektury, kotorye ne propisany stol' zhe tshchatel'no, kak ostal'nye. 6.3 Neobhodimo imet' kak formal'noe opisanie proekta - dlya tochnosti, tak i tekstual'noe - dlya ponimaniya. 6.4 Libo formal'noe, libo tekstual'noe opredeleniya vybirayutsya v kachestve standarta, pri etom vtoroe opredelenie yavlyaetsya proizvodnym. Kazhdoe opredelenie mozhet vystupat' v lyuboj iz rolej. 6.5 Realizaciya, v tom chisle model', mozhet sluzhit' opredeleniem arhitektury; takoe ispol'zovanie imeet sushchestvennye nedostatki. 6.6 Pryamoe vklyuchenie yavlyaetsya ochen' iskusnym priemom dlya osushchestvleniya standartov arhitektury v programmnom obespechenii (v apparatnom obespechenii - tozhe: voz'mite interfejs Mac WIMP, vstroennyj v ROM). 6.7 Arhitekturnoe "opredelenie budet yasnee, a (arhitekturnaya) disciplina krepche, esli iznachal'no stroyatsya kak minimum dve realizacii". 6.8 Vazhno, chtoby arhitektor v telefonnyh razgovorah otvechal ispolnitelyam na ih voprosy; obyazatel'no nuzhno registrirovat' eti razgovory v zhurnale i dovodit' ih do obshchego svedeniya. (Sejchas dlya etogo predpochtitel'nee elektronnaya pochta.) 6.9 "Luchshij drug menedzhera proekta - ego postoyannyj protivnik, nezavisimaya organizaciya, testiruyushchaya produkt." Glava 7. Pochemu ne udalos' postroit' Vavilonskuyu bashnyu? 7.1 Proekt Vavilonskoj bashni provalilsya iz-za nedostatka obmena informaciej i, kak sledstvie, organizacii. Obmen informaciej 7.2 "Otstavanie grafika, nesootvetstvie funkcional'nosti, sistemnye oshibki - vse eto iz-za togo, chto levaya ruka ne znaet, chto tvorit pravaya." Predpolozheniya komand rashodyatsya. 7.3 Brigady dolzhny podderzhivat' mezhdu soboj svyaz' vsemi vozmozhnymi sposobami: neformal'no, putem regulyarnyh soveshchanij po proektu s tehnicheskimi otchetami i cherez obshchuyu rabochuyu tetrad' proekta. (A takzhe elektronnuyu pochtu.) Rabochaya tetrad' proekta 7.4 Rabochaya tetrad' proekta est' "ne stol'ko otdel'nyj dokument, skol'ko struktura, nalagaemaya na vse dokumenty, kotorye, tak ili inache, budut sozdany vo vremya vypolneniya proekta." 7.5 "Vse dokumenty proekta dolzhny vhodit' v etu strukturu (rabochej tetradi)." 7.6 Strukturu rabochej tetradi nuzhno proektirovat' tshchatel'no i rano. 7.7 Pravil'noe strukturirovanie tekushchej dokumentacii s samogo nachala pozvolyaet "sostavlennye pozdnee dokumenty oformit' v vide otryvkov, kotorye vpisyvayutsya v etu strukturu" i uluchshaet rukovodstva po produktu. 7.8 "Kazhdyj chlen komandy dolzhen videt' vse materialy (rabochej tetradi)." (Sejchas ya by skazal "dolzhen imet' vozmozhnost' videt'". Naprimer, dostatochno WWW-stranic.) 7.9 Svoevremennoe obnovlenie mozhet imet' kriticheskoe znachenie. 7.10 Neobhodimo, chtoby vnimanie pol'zovatelya bylo osobo privlecheno k izmeneniyam, proizoshedshim posle ego poslednego prochteniya, prichem s pometkami ob ih znachenii. 7.11 Rabochaya tetrad' proekta OS/360 nachinalas' s bumazhnogo varianta s posleduyushchim perehodom na mikrofishi. 7.12 Segodnya (i dazhe v 1975 godu) obshchij elektronnyj bloknot yavlyaetsya znachitel'no luchshim, bolee deshevym i prostym mehanizmom dostizheniya etih celej. 7.13 Neobhodimo pomechat' tekst s pomoshch'yu polosok izmeneniya dat peresmotra (ili ih funkcional'nogo ekvivalenta). Tak zhe neobhodima svodka izmenenij po tipu steka. 7.14 Parnas staraetsya dokazat', chto stremlenie k tomu, chtoby kazhdyj videl vse, sovershenno oshibochno: chasti dolzhny inkapsulirovat'sya takim obrazom, chtoby nikomu ne trebovalos' ili ne razreshalos' videt' soderzhanie kakih- libo chastej, krome svoih sobstvennyh, a vidny mogut byt' tol'ko interfejsy. 7.15 Predlozhenie Parnasa - put' k katastrofe. (Parnas vpolne ubedil menya v obratnom, i ya sovershenno izmenil svoe mnenie.) Organizaciya 7.16 Zadachej organizacii yavlyaetsya sokrashchenie ob容ma neobhodimogo obshcheniya i soglasovaniya. 7.17 Organizaciya zaklyuchaet v sebe razdelenie truda i specializaciyu funkcij s cel'yu sokratit' obmen informaciej. 7.18 Obychnaya drevovidnaya organizaciya otrazhaet strukturnyj princip vlasti, kotoryj pokazyvaet, chto nel'zya odnovremenno sluzhit' dvum hozyaevam. 7.19 Struktura obmena informaciej v organizacii yavlyaetsya ne derevom, a set'yu, i nuzhno pridumat' razlichnye vidy special'nyh organizacionnyh mehanizmov ("punktirnye linii"), chtoby preodolet' deficit obmena informaciej v drevovidnoj organizacii. 7.20 V kazhdom subproekte est' dve rukovodyashchie dolzhnosti: prodyuser i tehnicheskij direktor, ili arhitektor. Ih funkcii sovershenno razlichny i trebuyut raznyh sposobnostej. 7.21 Vpolne effektivnym mozhet byt' lyuboj tip vzaimootnoshenij mezhdu etimi dvumya dolzhnostyami: - |to mozhet byt' odno lico. - Prodyuser mozhet byt' nachal'nikom, a direktor - ego pravoj rukoj. - Direktor mozhet byt' nachal'nikom, a prodyuser - ego pravoj rukoj. Glava 8. Ob座avlyaya udar 8.1 Nel'zya tochno ocenit' obshchij ob容m ili grafik rabot programmnogo proekta, prosto oceniv vremya napisaniya programmy i umnozhiv na nekotorye koefficienty dlya ostal'nyh chastej zadaniya. 8.2 Dannye, otnosyashchiesya k sozdaniyu nebol'shih otdel'nyh sistem, ne primenimy k proektam sozdaniya programmnyh kompleksov. 8.3 Ob容m rabot rastet kak stepennaya funkciya razmera programmy. 8.4 Nekotorye opublikovannye issledovaniya pokazyvayut, chto pokazatel' stepeni primerno raven 1,5. (Rezul'taty Bema s etim ne soglasuyutsya i menyayutsya ot 1,05 do 1,2.)1 8.5 Dannye Portmana po ICL pokazyvayut, chto zanyatye na polnyj rabochij den' programmisty tol'ko okolo 50 procentov vremeni zanimayutsya programmirovaniem i otladkoj, a ostal'noe vremya zanimayut raznye dopolnitel'nye zadachi. 8.6 Po dannym Arona iz IBM, proizvoditel'nost' truda lezhit v predelah ot 1,5 do 10 tysyach strok programmy na cheloveka v god v zavisimosti ot kolichestva vzaimodejstvij mezhdu chastyami sistemy. 8.7 Po dannym Harra iz Bell Labs, proizvoditel'nost' truda pri zadache tipa razrabotki operacionnoj sistemy sostavila okolo 0,6 tysyach strok koda na cheloveka v god, a pri razrabotke kompilyatorov - 2,2 tysyachi dlya zakonchennyh produktov. 8.8 Dannye Bruksa po OS/360 soglasuyutsya s dannymi Harra: 0,6-0,8 tysyach strok koda na cheloveko-god dlya operacionnyh sistem i 2-3 tysyachi dlya kompilyatorov. 8.9 Dannye Korbato po proektu MTI MULTICS pokazyvayut, chto proizvoditel'nost' truda pri razrabotke smesi operacionnoj sistemy i kompilyatorov sostavila 1,2 tysyach strok koda na cheloveka v god, no eto stroki koda PL/I, a ostal'nye dannye otnosyatsya k strokam koda assemblera! 8.10 Proizvoditel'nost' primerno postoyanna v perevode na elementarnye operatory. 8.11 Pri ispol'zovanii podhodyashchih yazykov vysokogo urovnya proizvoditel'nost' mozhno uvelichit' v pyat' raz. Glava 9. Dva v odnom 9.1 Esli ne schitat' vremeni vypolneniya, to glavnye izderzhki prihodyatsya na zanimaemoe programmoj prostranstvo pamyati. |to v osobennosti verno dlya operacionnyh sistem, znachitel'naya chast' kotoryh ostaetsya rezidentnoj. 9.2 Nesmotrya na eto, den'gi, potrachennye na pamyat' dlya razmeshcheniya programmy, dayut ochen' horoshee uluchshenie harakteristik na edinicu vlozhenij - luchshee, chem vse drugie sposoby investirovaniya v konfiguraciyu. Ploh ne razmer programmy, a lishnij razmer. 9.3 Razrabotchik programmy dolzhen ustanavlivat' zadanie po razmeru, kontrolirovat' razmer i pridumyvat' metody sokrashcheniya razmera, tak zhe, kak razrabotchik apparatnoj chasti delaet eto dlya detalej. 9.4 Resursy po pamyati dolzhny yavno zadavat' ne tol'ko razmer rezidentnoj chasti, no i intensivnost' obrashchenij programmy k disku. 9.5 Resursy pamyati dolzhny privyazyvat'sya k naznacheniyu funkcij: tochno opredelyajte, chto dolzhen delat' modul', kogda zadaete ego razmery. 9.6 Gruppy v sostave bol'shih brigad sklonny proizvodit' optimizaciyu v svoih uzkih interesah, ne dumaya o konechnom effekte, kotoryj ona okazhet na pol'zovatelya. |ta poterya orientacii yavlyaetsya bol'shoj opasnost'yu dlya krupnyh proektov. 9.7 Na vsem protyazhenii realizacii sistemnye arhitektory dolzhny postoyanno proyavlyat' bditel'nost' s cel'yu nepreryvnogo obespecheniya celostnosti sistemy. 9.8 Vospitanie obshchesistemnogo i orientirovannogo na pol'zovatelya podhoda yavlyaetsya, vozmozhno, glavnoj zadachej menedzhera po programmirovaniyu. 9.9 Nuzhno uzhe na rannih etapah opredelit', naskol'ko detalizirovannym budet predostavlyaemyj pol'zovatelyu vybor opcij, poskol'ku ob容dinenie opcij v gruppy sberegaet pamyat' (a chasto i rashody na marketing). 9.10 Vazhno opredelit' razmer tranzitnoj pamyati, svyazannyj s razmerom peregruzhaemogo koda, poskol'ku zavisimost' proizvoditel'nosti ot etogo razmera sil'nee, chem linejnaya. (|tot punkt polnost'yu ustarel blagodarya nalichiyu virtual'noj pamyati i deshevizne fizicheskoj pamyati. Teper' pol'zovateli obychno pokupayut pamyat' v kolichestve, dostatochnom dlya razmeshcheniya vsego koda osnovnyh prilozhenij.) 9.11 Dlya dostizheniya horoshego kompromissa mezhdu prostranstvom i vremenem neobhodimo provodit' obuchenie tehnike programmirovaniya, prisushchej dannomu yazyku ili mashine, osobenno esli oni novye. 9.12 U programmirovaniya est' tehnologiya, i kazhdyj proekt nuzhdaetsya v biblioteke standartnyh komponentov. 9.13 Biblioteki programm dolzhny imet' po dve versii kazhdogo komponenta - bystruyu i kompaktnuyu. (Pohozhe, chto segodnya eto ustarelo.) 9.14 Kompaktnye i bystrye programmy pochti vsegda yavlyayutsya rezul'tatom strategicheskogo proryva, a ne takticheskoj gramotnosti. 9.15 Takim proryvom chasto yavlyaetsya novyj algoritm. 9.16 Eshche chashche proryv proishodit blagodarya izmeneniyu predstavleniya dannyh ili tablic. Predstavlenie - sushchnost' programmirovaniya. Glava 10. Dokumentarnaya gipoteza 10.1 Gipoteza: Sredi morya bumag neskol'ko dokumentov stanovyatsya kriticheski vazhnymi osyami, vokrug kotoryh vrashchaetsya vse upravlenie proektom. Oni yavlyayutsya glavnymi lichnymi instrumentami menedzhera. 10.2 Dlya proekta razrabotki komp'yutera reshayushchimi dokumentami yavlyayutsya celi, rukovodstvo, grafik, byudzhet, organizacionnaya struktura, plan pomeshchenij, a takzhe ocenka, prognoz i ceny dlya samoj mashiny. 10.3 Dlya fakul'teta universiteta vazhnejshie dokumenty analogichny: celi, trebovaniya k soiskatelyam stepenej, opisaniya kursov, predlozheniya po nauchnoj rabote, raspisanie zanyatij i plan obucheniya, byudzhet, plan pomeshchenij, a takzhe naznacheniya prepodavatelej i aspirantov. 10.4 Dlya programmnogo proekta trebovaniya te zhe: celi, rukovodstvo pol'zovatelya, vnutrennyaya dokumentaciya, grafik, byudzhet, organizacionnaya struktura i plan pomeshchenij. 10.5 Poetomu dazhe dlya samogo malen'kogo proekta menedzher s samogo nachala dolzhen formalizovat' takoj nabor dokumentov. 10.6 Podgotovka kazhdogo dokumenta ih etogo malen'kogo nabora koncentriruet mysl' i kristallizuet obsuzhdenie. Pri izlozhenii na bumage trebuetsya prinyatie soten mini-reshenij, i ih nalichie otlichaet chetkuyu i tochnuyu politiku ot rasplyvchatoj. 10.7 Soprovozhdenie kazhdogo vazhnogo dokumenta trebuet nalichiya mehanizma slezheniya za sostoyaniem i preduprezhdeniya. 10.8 Kazhdyj dokument v otdel'nosti sluzhit kontrol'nym spiskom i bazoj dannyh. 10.9 Vazhnejshaya zadacha menedzhera - obespechit' obshchee dvizhenie v odnom napravlenii. 10.10 Glavnaya postoyannaya zadacha menedzhera - obshchenie, a ne prinyatie reshenij; dokumenty informiruyut vsyu komandu o planah i resheniyah. 10.11 Tol'ko malen'kaya chast', vozmozhno, 20 procentov, rabochego vremeni administratora zanyata zadachami, kotorye trebuyut svedenij, otsutstvuyushchih v ego pamyati. 10.12 Po etoj prichine modnaya ideya "vseohvatyvayushchej informacionnoj sistemy dlya upravleniya", obespechivayushchej podderzhku rukovoditelya, osnovyvaetsya na nevernoj modeli povedeniya rukovoditelya. Glava 11. Planirujte na vybros 11.1 Inzhenery-himiki vyyasnili, chto osushchestvlennyj v laboratorii process nel'zya odnim mahom perenesti v zavodskie usloviya, no neobhodimo postroit' opytnyj zavod, chtoby poluchit' opyt narashchivaniya kolichestv veshchestv i funkcionirovaniya v nezashchishchennyh sredah. 11.2 |tot promezhutochnyj shag v ravnoj mere neobhodim dlya programmnyh produktov, no dlya inzhenerov-programmistov poka ne stalo obychnoj praktikoj provodit' polevye ispytaniya opytnoj sistemy, prezhde chem nachinat' postavki gotovogo produkta. (Sejchas eto uzhe stalo obshchej praktikoj blagodarya vypusku beta-versij. |to ne to zhe samoe, chto maket s ogranichennoj funkcional'nost'yu, al'fa-versiya, kotoruyu ya takzhe propagandiruyu.) 11.3 Dlya bol'shinstva proektov pervuyu postroennuyu versiyu edva mozhno ispol'zovat': slishkom medlennaya, slishkom bol'shaya, slishkom slozhnaya v primenenii, ili vse eto vmeste. 11.4 Otbrosit' i pereproektirovat' mozhno vse srazu, a mozhno po chastyam, no vse ravno eto pridetsya sdelat'. 11.5 Postavka pervoj sistemy (hlama) klientu pozvolyaet vyigrat' vremya, no proishodit eto cenoj muchenij pol'zovatelej, otvlecheniya razrabotchikov, podderzhivayushchih sistemu vo vremya pereproektirovaniya i durnoj reputacii produkta, kotoruyu budet trudno pobedit'. 11.6 Poetomu planirujte vybrosit' pervuyu versiyu - vam vse ravno pridetsya eto sdelat'. 11.7 "Programmist postavlyaet udovletvorenie potrebnosti pol'zovatelya, a ne kakoj-to osyazaemyj produkt" (Kosgrouv). 11.8 Kak fakticheskie potrebnosti pol'zovatelya, tak i ponimanie im svoih potrebnostej menyayutsya vo vremya sozdaniya, testirovaniya i ispol'zovaniya programmy. 11.9 Podatlivost' i neosyazaemost' programmnogo produkta pobuzhdayut ego sozdatelej (isklyuchitel'no) k vechnomu izmeneniyu trebovanij. 11.10 Nekotorye zakonnye izmeneniya v zadachah (i strategiyah razrabotki) neizbezhny, i luchshe podgotovit'sya k nim zaranee, chem predpolagat', chto ih ne budet. 11.11 Sposoby proektirovaniya sistemy s uchetom budushchih izmenenij, osobenno strukturnoe programmirovanie s tshchatel'nym dokumentirovaniem interfejsov modulej, horosho izvestny, no ne vsegda primenyayutsya. Polezno takzhe, gde tol'ko mozhno, ispol'zovat' tehnologii tablichnogo upravleniya. (Takaya tehnika blagodarya stoimosti i razmeru pamyati v nastoyashchee vremya primenyaetsya vse bolee uspeshno.) 11.12 Dlya sokrashcheniya vnosimyh pri izmeneniyah oshibok sleduet ispol'zovat' yazyki vysokogo urovnya, operacii vremeni kompilyacii, vstraivanie ssylok na ob座avleniya i tehniku samodokumentirovaniya. 11.13 Vnosite izmeneniya kvantami v horosho opredelennye numerovannye versii. (Sejchas eto obychnaya praktika.) Planirujte organizaciyu dlya izmeneni