Kāpēc programmatūra ir tik slikta

Tas ir viens no vecākajiem jokiem internetā, kas bezgalīgi tiek pārsūtīts no e-pasta uz e-pastu. Programmatūras magnāts — parasti Bils Geitss, bet dažreiz kāds cits — uzstājas ar runu. Ja automobiļu rūpniecība būtu attīstījusies tāpat kā programmatūras industrija, sludina magnāts, mēs visi brauktu ar 25 USD vērtām automašīnām, kas nobrauktu 1000 jūdzes līdz galonam. Uz ko automobiļu vadītājs atbild: Jā, un, ja automašīnas būtu kā programmatūra, tās divas reizes dienā bez iemesla avarētu, un, kad jūs izsaucāt servisu, viņi jums liktu pārinstalēt dzinēju.

Joks iekapsulē vienu no lielākajām mūsdienu tehnoloģiju mīklām. Apbrīnojami īsā laikā programmatūra ir kļuvusi par kritisku gandrīz visiem mūsdienu dzīves aspektiem. No banku glabātuvēm līdz pilsētas gaismas signāliem, no telefona tīkliem līdz DVD atskaņotājiem, no automašīnu gaisa spilveniem līdz gaisa satiksmes vadības sistēmām – pasauli ap mums regulē kods. Tomēr liela daļa programmatūras vienkārši nedarbojas uzticami: jautājiet ikvienam, kurš ir redzējis, ka datora ekrāns kļūst zils, noslaukot vairākas stundas. Pārāk bieži programmatūras inženieri saka, ka kods ir uzpūsts, neglīts, neefektīvs un slikti izstrādāts; pat tad, ja programmas darbojas pareizi, lietotājiem tās šķiet pārāk grūti saprotamas. Grēkājot zem ķieģeļveida rokasgrāmatu smaguma, grāmatnīcu plaukti visā valstī liecina par programmatūras ilgstošo disfunkcionalitāti.

Programmatūra mūsdienās ir vienkārši briesmīga, saka Vatss S. Hamfrijs, Kārnegija Melona universitātes Programmatūras inženierijas institūta biedrs, kurš ir sarakstījis vairākas labi zināmas grāmatas par programmatūras kvalitāti. Un visu laiku kļūst sliktāk. Laba programmatūra, pēc Hamfrija domām, ir lietojama, uzticama, bez defektiem, rentabla un apkopjama. Un programmatūra tagad nav neviena no šīm lietām. Jūs nevarat izņemt kaut ko no kastes un zināt, ka tas darbosies. Gadu gaitā, pēc Teksasas Universitātes Ostinas emeritētā datorzinātnieka Edsgera V. Dijkstras domām, vidusmēra datora lietotājs ir tik slikti apkalpots, ka viņš sagaida, ka viņa sistēma visu laiku avarēs, un mēs esam liecinieki milzīgam kļūdu izraisītas programmatūras izplatīšana visā pasaulē, par ko mums ir ļoti jākaunas.

Džims Makartijs ir dāsnāks. Programmatūras kvalitātes apmācības uzņēmuma Vudinvilā, Vašingtonā dibinātājs kopā ar sievu Mišelu Makartijs uzskata, ka lielākajai daļai programmatūras produktu ir nepieciešamās funkcijas, lai tos būtu vērts iegādāties, lietot un pieņemt. Taču viņš pieļauj, ka tikai programmatūras ārkārtējā lietderība ļauj mums paciest tās milzīgos trūkumus. Makartijs dažreiz sāk sarunas savā skolā ar PowerPoint prezentāciju. Pirmajā slaidā ir rakstīts: Lielākā daļa programmatūras ir sliktā stāvoklī.

Ir grūti pārvērtēt programmatūras problēmu unikalitāti. Kad automobiļu inženieri apspriež automašīnas tirgū, viņi nesaka, ka transportlīdzekļi šodien nav labāki par tiem, kādi tie bija pirms desmit vai piecpadsmit gadiem. Tas pats attiecas uz aeronautikas inženieriem: neviens neapgalvo, ka Boeing vai Airbus ražo sliktas lidmašīnas. Elektroinženieri arī nesūdzas, ka mikroshēmas un shēmas neuzlabojas. Kā savā 1992. gada grāmatā ierosināja inženierzinātņu vēsturnieks Henrijs Petroskis Noderīgu lietu evolūcija , nepārtraukta uzlabošana ir parastais noteikums tehnoloģijā. Inženieri pastāvīgi pamana trūkumus savos projektos un pamazām tos novērš, un Petroski šo procesu īgni raksturoja kā forma seko neveiksmei. Tā rezultātā produkti pakāpeniski uzlabojas.

Diemžēl programmatūra šķiet atšķirīga. Var sagaidīt, ka 45 miljonu līniju programmām, piemēram, Windows XP, Microsoft jaunākajai operētājsistēmai, būs dažas kļūdas. Un programmatūras inženierija ir jaunāka disciplīna nekā mašīnbūve vai elektrotehnika; pirmās reālās programmas tika izveidotas tikai pirms 50 gadiem. Bet kas ir pārsteidzoši, patiesībā ir tas, ka daudzi programmatūras inženieri uzskata, ka programmatūras kvalitāte neuzlabojas. Ja kaut kas, viņi saka, tas kļūst sliktāk. It kā Detroitā ražotās automašīnas 2002. gadā būtu mazāk uzticamas nekā 1982. gadā ražotās automašīnas.

Tā kā programmatūra kļūst arvien svarīgāka, sliktā koda iespējamā ietekme palielināsies, lai tas atbilstu, uzskata Pīters G. Neimans, datorzinātnieks no SRI International, privātā pētniecības un attīstības centra Menlo Parkā, Kalifornijā. Pēdējo 15 gadu laikā vien programmatūras defekti ir sagraujuši Eiropas satelīta palaišanu, par gadu aizkavējuši ļoti dārgās Denveras lidostas atvēršanu, iznīcinājuši NASA Marsa misiju, gājuši bojā četri jūras kājnieki helikoptera avārijā, pamudinājuši ASV jūras spēku kuģi iznīcināt. civilā lidmašīna, un Londonā slēdza ātrās palīdzības sistēmas, izraisot pat 30 nāves gadījumus. Un, ņemot vērā mūsu pieaugošo atkarību no tīkla, Neimans saka: mēs esam daudz sliktāki nekā pirms pieciem gadiem. Riski ir sliktāki, un aizsardzība nav tik laba. Mēs ejam atpakaļ, un tas ir biedējoši.

Daži programmatūras uzņēmumi reaģē uz šo kritiku, pārveidojot savas procedūras; Korporācija Microsoft, kuru nomāc apsūdzības, ka tās produkti ir kļūdaini, publiski ir vadošā loma. Tomēr problēmas ar programmatūras kvalitāti ir bijušas tik ilgi un šķiet tik neatrisināmi iestrādātas programmatūras kultūrā, ka daži kodētāji sāk domāt par neiedomājamu. Pašiem par izbrīnu šie cilvēki ir prātojuši, vai patiesā programmatūras problēma ir tā, ka nav iesaistīts pietiekami daudz juristu.

Loģikas trūkums

Korporācija Microsoft izlaida sistēmu Windows XP 2001. gada 25. oktobrī. Tajā pašā dienā, kas varētu būt rekordliels, uzņēmums publicēja 18 megabaiti ielāpus savā vietnē: kļūdu labojumi, saderības atjauninājumi un uzlabojumi. Divi ielāpi laboja svarīgus drošības caurumus. Pareizāk sakot, viens no viņiem to darīja; otrs ielāps nedarbojās. Microsoft ieteica (un joprojām iesaka) lietotājiem dublēt kritiskos failus pirms ielāpu instalēšanas. Tomēr Windows XP mājas versijas pircēji atklāja, ka sistēma nesniedza iespēju atjaunot šos dublējuma failus, ja viss noiet greizi. Kā laipni paskaidroja Microsoft tiešsaistes zināšanu bāze, īpašie Windows XP Home izveidotie rezerves disketes nedarbojas operētājsistēmā Windows XP Home.

Kritiķi saka, ka šādas novirzes ir tikai virspusējas kļūdas — pazīmes, ka programmatūras izstrādātāji bija pārāk steidzīgi vai pārāk neuzmanīgi, lai novērstu acīmredzamus defektus. Saskaņā ar R. A. Downes no Radsoft, programmatūras konsultāciju firmas, patiesās problēmas slēpjas programmatūras pamata dizainā. Pareizāk sakot, tā trūkums no dizaina. Microsoft populārā Visual Studio programmēšanas programmatūra ir piemērs Daunsa domāšanas veidam. Vienkārši novietojot kursoru virs Visual Studio loga, Dauns atklāja, ka tas nemanāmi aizsprosto centrālo procesoru ar tūkstošiem nevajadzīgu ziņojumu, lai gan programma neko nedara. Tas ir kataklizmisks. Tas ir pilnīgs haoss, viņš sūdzas.

Pēc Raisas universitātes datorzinātnieka Dena Valaha domām, problēma nav bezjēdzīga procesora kuļošana — galu galā viņš atzīmē, ka apstrādes jauda ir lēta. Arī Microsoft programmatūra nav īpaši kļūdaina; kritiķi bieži izmanto uzņēmuma produktus kā piemērus vairāk tāpēc, ka tie ir pazīstami, nevis tāpēc, ka tie ir neparasti slikti. Tā vietā, pēc Valaha domām, Visual Studio un tik daudzās citās programmās plaukstošais apjukums liecina par to, kā programmatūras rakstīšanas metodes nav spējušas sekot līdzi tās sarežģītības straujajam pieaugumam.

Programmētāji raksta kodu tādās valodās kā Java, C un C++, ko var lasīt cilvēki. Specializētās programmas, kas pazīstamas kā kompilatori, pārveido šo kodu vieninieku un nulles virknēs, ko izmanto datori. Svarīgi, ka kompilatori atsakās kompilēt kodu ar acīmredzamām problēmām — tā vietā viņi izspiež kļūdu ziņojumus. Līdz 70. gadiem kompilatori sēdēja uz lieliem lieldatoriem, kas bieži tika rezervēti dienas vai nedēļas iepriekš. Nevēloties, lai kļūdas izraisītu aizkavēšanos, kodētāji, kuri sākumā mēdza būt matemātiķi vai fiziķi, palika vēlu birojā, rūpīgi pārbaudot savu darbu. Programmatūras rakstīšana līdzinājās zinātnisku darbu rakstīšanai. Stingrība, dokumentācija un salīdzinošā pārbaude bija ierasts.

Taču, kad datori kļuva plaši izplatīti, attieksme mainījās. Tā vietā, lai rūpīgi plānotu kodu, programmētāji visu nakti turpināja uzlaušanas sesijās, kurās bija kofeīns, nepārtraukti gūstot rezultātus no kompilatora. Atkal un atkal kompilators izspļautu kļūdu ziņojumus; programmētāji labotu kļūdas pa vienam, līdz programmatūra būtu pareizi kompilēta. Šodienas attieksme ir tāda, ka jūs varat uzrakstīt jebkuru nevīžīgu kodu, un kompilators veiks diagnostiku, saka SRI Neumann. Ja tas neizspļauj kļūdas ziņojumu, tas ir jādara pareizi, vai ne?

Programmām pieaugot apjomam un sarežģītībai, tomēr kļuva acīmredzamas šī koda un labošanas pieejas robežas. Profesionālie kodētāji pieļauj vidēji 100 līdz 150 kļūdas katrā tūkstoš rakstītā koda rindiņu, liecina Hamfrija no Kārnegija Melona daudzgadīgā pētījuma par 13 000 programmām. Izmantojot Hamfrija skaitļus, biznesa operētājsistēma Windows NT 4 ar 16 miljoniem koda rindu tādējādi būtu uzrakstīta ar aptuveni diviem miljoniem kļūdu. Lielākā daļa no tiem būtu bijuši pārāk mazi, lai radītu kādu efektu, taču daži — daudzi tūkstoši — būtu radījuši nopietnas problēmas.

Protams, Microsoft pilnībā pārbaudīja NT 4 pirms izlaišanas, taču gandrīz jebkurā testu fāzē jūs atradīsit mazāk nekā pusi no defektiem, saka Hamfrijs. Ja Microsoft būtu izgājis četras pārbaudes kārtas, kas ir dārga un laikietilpīga procedūra, uzņēmums būtu atradis ne vairāk kā 15 no 16 kļūdām. Tas atstās jums apmēram piecus defektus uz tūkstoš koda rindiņu, saka Hamfrijs. Tas ir ļoti zems, taču programmatūrā joprojām būtu pat 80 000 kļūdu.

Programmatūras inženieri zina, ka viņu kods bieži ir caurstrāvots ar nepilnībām, un viņi jau sen ir meklējuši jaunas tehnoloģijas, lai tās novērstu. Lai pārvaldītu arvien vairāk paplašinātus projektus, piemēram, Windows, viņi ir izstrādājuši dažādas metodes, no kurām, iespējams, vispazīstamākā ir uz komponentiem balstīts dizains. Tāpat kā mājas tiek būvētas, izmantojot standartizētus divreiz četrus un elektrisko armatūru, uz komponentiem balstītas programmas tiek veidotas no modulāriem, maināmiem elementiem: piemērs ir gandrīz identiska izvēlņu josla katras Windows vai Macintosh programmas augšpusē. Šādi standartizēti komponenti, pēc Wallach domām, ir ne tikai laba inženierijas prakse, tie ir vienīgais veids, kā kaut ko tādu, kas ir Microsoft Office izmēra, vispār var likt darboties. Viņš saka, ka Microsoft bija agrīns, agresīvs šīs pieejas veicinātājs — tas ir vienīgais labākais inženierijas lēmums, ko viņi jebkad ir pieņēmuši.

Diemžēl kritiķi saka, ka sastāvdaļas bieži tiek salīmētas kopā bez reāla centrālā plāna, it kā darbuzņēmēji mēģinātu uzcelt lielas konstrukcijas bez rasējumiem. Neticami, saka Hamfrijs, lielu programmatūras projektu dizains dažkārt ir tikai pāris burbuļi aploksnes aizmugurē. Vēl ļaunāk, mārketinga apsvērumu dēļ uzņēmumi jaunajā programmatūrā pievieno pēc iespējas vairāk funkciju, tādējādi neitralizējot moduļu konstrukcijas priekšrocības. Visizplatītākais piemērs ir pati Windows, par kuru Bils Geitss apliecināja Microsoft pretmonopola izmēģinājuma aprīļa sesijā, vienkārši nedarbotos, ja klienti noņemtu atsevišķus komponentus, piemēram, pārlūkprogrammas, failu pārvaldniekus vai e-pasta programmas. Tas ir neticams apgalvojums, saka Neimans. Tas nozīmē, ka tam, kā viņi ir izveidojuši šīs sistēmas, nav nekādas struktūras vai arhitektūras, atskaņas vai iemesla, izņemot to, lai tās būtu pēc iespējas apvienotas, lai, noņemot kādu daļu, tas viss neizdosies.

Kritiķi apgalvo, ka galaproduktu neatbilstošais dizains atspoguļo neatbilstošu plānošanu to radīšanas procesā. Saskaņā ar pētījumu, ko veica Standish Group, konsultāciju uzņēmums West Yarmouth, MA, ASV komerciālās programmatūras projekti ir tik slikti plānoti un pārvaldīti, ka 2000. gadā gandrīz ceturtā daļa tika pilnībā atcelti, neradot galaproduktu. Atceltie projekti izmaksāja firmām 67 miljardus dolāru; pārtēriņi citiem projektiem radīja vēl 21 miljardu dolāru. Taču, tā kā kods un labojums noved pie tik apjomīgām un dārgām testēšanas kārtām, pat veiksmīgi projekti var būt ārkārtīgi neefektīvi. Neticami, ka programmatūras projekti bieži tiek veltīti 80 procenti no sava budžeta, lai novērstu trūkumus, viņi paši izstrādāja — šis skaitlis neietver vēl dārgāko produktu atbalsta nodrošināšanas procesu un ielāpu izstrādi pēc izlaišanas konstatētajām problēmām.

Sistēmas testēšana turpinās gandrīz pusi procesa, saka Hamfrijs. Un pat tad, kad viņi beidzot sāk darboties, dizaina joprojām nav. Līdz ar to programmatūru nevar atjaunināt vai uzlabot, nodrošinot, ka atjauninājumi vai uzlabojumi neradīs būtiskas kļūdas. Tas ir veids, kā programmatūra tiek izstrādāta un būvēta visur — tā ir kosmosa kuģos, Dieva dēļ.

Vai programmatūra ir īpašs gadījums?

Iespējamie sliktas programmatūras riski bija drūmi ilustrēti laikā no 1985. līdz 1987. gadam, kad ar datoru kontrolēta staru terapijas iekārta, ko ražoja valdības atbalstītā Kanādas atomenerģija, ASV un Kanādā masveidā pārdozēja pacientus, nogalinot vismaz trīs. Izsmeļošā pārbaudē Nensija Levesone, tagad MIT datorzinātniece, lielu daļu vainas piedēvēja ražotāja neatbilstošajai programmatūras inženierijas praksei. Tā kā starojuma intensitātes iestatīšanai izmantotā programma nebija izstrādāta vai rūpīgi pārbaudīta, vienkāršas drukas kļūdas izraisīja nāvējošus sprādzienus.

Neskatoties uz šo traģisko pieredzi, līdzīgas iekārtas, kurās darbojas programmatūra Multidata Systems International no Sentluisas, 2000. un 2001. gadā masveidā pārdozēja pacientus Panamā, izraisot vēl astoņus nāves gadījumus. Starptautiskās Atomenerģijas aģentūras komanda nāves gadījumus skaidroja ar datu ievadīšanu tādā veidā, kā programmētāji nebija paredzējuši. Kā atzīmē Levesons, vienkāršām datu ievades kļūdām nevajadzētu būt letālām sekām. Tāpēc arī šī kļūme var būt saistīta ar neatbilstošu programmatūru.

Programmēšanas eksperti mēdz piekrist, ka šādas katastrofas ir satraucoši izplatītas. Apsveriet Marsa klimatisko orbītu un Polar Lander, kurus 1999. gadā iznīcināja pazīstamas, viegli novēršamas kodēšanas kļūdas. Bet daži apgalvo, ka programmatūru vienkārši nevar novērtēt, izmērīt un uzlabot tāpat kā citus inženiertehniskos produktus. Tas ir tikai fakts, ka ir lietas, ko citi inženieri var izdarīt, ko mēs nevaram izdarīt, saka Shari Lawrence Pfleeger, vecākais pētnieks Rand ideju laboratorijā Vašingtonā, DC un 2001. gada sējuma autors. Programmatūras inženierija: teorija un prakse . Ja tilts iztur 500 kilogramu un 50 000 kilogramu svaru, atzīmē Pfleigers, inženieri var pieņemt, ka tas izturēs visas vērtības. Viņa saka, ka ar programmatūru es nevaru izdarīt šādu pieņēmumu — es nevaru interpolēt.

Turklāt programmatūras ražotāji strādā saskaņā ar ārkārtējām prasībām. Ford un General Motors ir ražojuši vienu un to pašu produktu — četru riteņu kasti ar iekšdedzes dzinēju — gadu desmitiem. Rezultātā, saka Čārlzs H. Konels, bijušais Lotus Development (tagad daļa no IBM) galvenais inženieris, viņi ir spējuši pakāpeniski uzlabot savus produktus. Taču programmatūras uzņēmumiem pastāvīgi tiek lūgts izveidot produktus — tīmekļa pārlūkprogrammas 90. gadu sākumā, jaunas mobilo tālruņu saskarnes mūsdienās — atšķirībā no jebkā agrāk. Tas ir tāpat kā automašīnu ražotājs, sakot: šogad mēs taisīsim raķešu kuģi, nevis automašīnu, ”saka Konels. Protams, viņiem būs problēmas.

Klasiskā programmatūras dilemma ir tāda, ka cilvēki nemitīgi vēlas iegūt arvien vairāk un vairāk lietu, saka Neitans Mairvolds, bijušais Microsoft tehnoloģiju vadītājs. Diemžēl viņš atzīmē, ka pastāvīgais pieprasījums pēc jaunumiem nozīmē, ka programmatūra vienmēr atrodas attīstības fāzē, kad produkti pēc būtības ir mazāk uzticami. Viņš saka, ka 1983. gadā programmā Microsoft Word bija tikai 27 000 koda rindiņu. Problēma ir tā, ka tas nedeva pārāk daudz, ko klienti šodien nepieņemtu. Ja Microsoft nebūtu turpinājusi papildināt Word ar jaunām funkcijām, produkts vairs nepastāvētu.

Lietotāji ārkārtīgi neapzinās sevi, piebilst Myhrvold. Viņš saka, ka Microsoft korporatīvie klienti bieži pieprasīja, lai uzņēmums vienlaikus pievieno jaunas funkcijas un pārtrauc jaunu funkciju pievienošanu. Burtiski, es to esmu dzirdējis vienā elpas vilcienā, vienā teikumā. Mēs neesam pārliecināti, kāpēc mums vajadzētu jaunināt uz šo jauno versiju — tajā ir viss tas, ko mēs nevēlamies — un kad jūs plānojat ievietot šīs trīs lietas?” Un jūs sakāt: Whaaat?” Myhrvold sardonisks kopsavilkums: Programmatūra. skumji, jo lietotāji to pieprasa.

Augstāki standarti

Janvārī Bils Geitss aicināja Microsoft darbiniekus noteikt uzticamu un drošu skaitļošanu par savu augstāko prioritāti. Uzņēmums, ko uzņēmums uzskatīja par vienu no svarīgākajām iniciatīvām gadiem ilgi, Geitss pieprasīja, lai Microsoft ievērojami samazinātu savu produktu defektu skaitu. Mēnesi vēlāk uzņēmums veica bezprecedenta soli, apturot visu jauno kodu rakstīšanu uz gandrīz diviem mēnešiem. Tā vietā tā pulcēja programmētājus, tūkstoti vienlaikus, lai masveida apmācību sesijās par uzticamību un drošību. Izmantojot milzīgus ekrānus milzīgā auditorijā, uzņēmuma vadītāji rādīja apkaunojošus kļūdaina koda fragmentus, ko radīja auditorijas dalībnieki.

Acīmredzot Geitsa iniciatīvu iedvesmoja kritikas trieciens, kas pārņēma Microsoft 2001. gada jūlijā, kad bufera pārpilde — sen pazīstams kļūdu veids — tās interneta informācijas pakalpojumu tīmekļa servera programmatūrā ļāva Code Red tārpam kļūt par tūkstošiem tās korporatīvo klientu. (Bufera pārpildes gadījumā programma saņem vairāk datu, nekā paredzēts — tā, it kā pasta indeksa vieta tiktu aizpildīta ar 50 ciparu numuru. Datorā papildu informācija nonāks blakus esošajās atmiņas daļās, sabojājot vai pārrakstot. tur esošos datus, ja vien tie nav rūpīgi bloķēti.) Divus mēnešus vēlāk Nimda tārps izmantoja citus programmatūras trūkumus, lai uzbruktu tūkstošiem citu iekārtu.

Šādas pieredzes pārņemti, programmatūras izstrādātāji arvien vairāk pievērš uzmanību kvalitātei. Pat tad, kad Geitss pulcēja savu karaspēku, domnīcas, piemēram, Kestrel Institute, Palo Alto, Kalifornijā, izstrādāja pareizi izstrādātas programmēšanas rīku komplektus, kas gandrīz piespiež kodētājus rakstīt uzticamas programmas ( skatiet Pirmā palīdzība kļūdaina koda gadījumā ). Saskaņā ar uzņēmuma programmētāju produktivitātes pētījumu centra vadītāja Amitabha Srivastava teikto, kodētāji strādā ar jaunām, augstāka līmeņa valodām, piemēram, C#, kas nepieļauj noteiktas kļūdas. Maijā Microsoft kopā ar NASA un 16 citām firmām kopā ar NASA un 16 citām firmām nodibināja ilgtspējīgas skaitļošanas konsorciju par 30 miljoniem ASV dolāru, lai veicinātu programmatūras uzticamības mērīšanu un uzlabošanu. Kvalitātes kontroles centieni var atmaksāties ļoti labi: palīdzot uzņēmumam Lockheed Martin atjaunināt programmatūru savā C130J lidmašīnā, Praxis Critical Systems no Batas, Anglijā, izmantoja šādas metodes, lai samazinātu izstrādes izmaksas par 80 procentiem, vienlaikus ražojot programmatūru, kas nokārtoja stingrus Federālās aviācijas administrācijas eksāmenus. ļoti maz kļūdu.

paslēpties