Kodėl programinė įranga tokia bloga

Tai vienas seniausių pokštų internete, be galo persiunčiamas iš el. pašto dėžutės į el. pašto dėžutę. Programinės įrangos magnatas – dažniausiai Billas Gatesas, bet kartais kitas – sako kalbą. Jei automobilių pramonė būtų vystoma taip, kaip programinės įrangos pramonė, skelbia magnatas, mes visi važiuotume 25 USD kainuojančiais automobiliais, kurie nuvažiuoja 1000 mylių iki galono. Į ką automobilio vadovas atkerta: Taip, o jei automobiliai būtų kaip programinė įranga, jie du kartus per dieną sudužtų be jokios priežasties, o kai iškviestumėte servisą, jie lieptų iš naujo įdiegti variklį.





Pokštas apima vieną didžiausių šiuolaikinių technologijų galvosūkių. Per stebėtinai trumpą laiką programinė įranga tapo labai svarbia beveik visuose šiuolaikinio gyvenimo aspektuose. Nuo bankų saugyklų iki miesto šviesoforų, nuo telefono tinklų iki DVD grotuvų, nuo automobilių oro pagalvių iki oro eismo valdymo sistemų – mus supantis pasaulis yra reguliuojamas kodu. Tačiau daugelis programinės įrangos paprasčiausiai neveikia patikimai: paklauskite kiekvieno, kas matė, kaip kompiuterio ekranas pamėlynavo, o tai išbraukė kelias valandas. Labai dažnai programinės įrangos inžinieriai sako, kad kodas yra išpūstas, bjaurus, neefektyvus ir prastai suprojektuotas; net kai programos veikia tinkamai, vartotojams jas per sunku suprasti. Dejuojantys po plytų pavidalo žinynų svoriu, knygynų lentynos visoje šalyje liudija apie nuolatinį programinės įrangos disfunkciją.

Programinė įranga šiandien yra tiesiog baisi, sako Watts S. Humphrey, Carnegie Mellon universiteto Programinės įrangos inžinerijos instituto bendradarbis, parašęs keletą gerai žinomų knygų apie programinės įrangos kokybę. Ir vis blogėja. Gera programinė įranga, Humphrey nuomone, yra tinkama naudoti, patikima, be defektų, ekonomiška ir prižiūrima. Ir programinė įranga dabar nėra nieko iš tų dalykų. Negalite kažko išimti iš dėžutės ir žinoti, kad tai veiks. Teksaso universiteto Ostine kompiuterių mokslininko emerito Edsgerio W. Dijkstra nuomone, eilinis kompiuterių vartotojas buvo taip prastai aptarnaujamas, kad jis tikisi, kad jo sistema nuolat strigs, o mes esame didžiulio pasauliniu mastu platinama programinė įranga, kurioje yra klaidų, dėl kurios turėtume labai gėdytis.

Jimas McCarthy yra dosnesnis. McCarthy, kartu su žmona Michele iš Vudinvilyje, WA, programinės įrangos kokybės mokymo įmonės įkūrėjas mano, kad dauguma programinės įrangos produktų turi reikiamų funkcijų, kurias verta pirkti, naudoti ir pritaikyti. Tačiau, jis leidžia, tik ypatingas programinės įrangos naudingumas leidžia toleruoti didžiulius jos trūkumus. McCarthy kartais pradeda pokalbius savo mokykloje PowerPoint pristatymu. Pirmoje skaidrėje rašoma „Most Software Sucks“.



Sunku per daug pabrėžti programinės įrangos problemų unikalumą. Kai automobilių inžinieriai aptarinėja automobilius rinkoje, jie nesako, kad šiandieninės transporto priemonės nėra geresnės nei buvo prieš dešimt ar penkiolika metų. Tas pats pasakytina ir apie aeronautikos inžinierius: niekas netvirtina, kad „Boeing“ ar „Airbus“ gamina niūrius lėktuvus. Elektros inžinieriai taip pat nesiskundžia, kad lustai ir grandinės netobulėja. Kaip pasiūlė inžinerijos istorikas Henris Petroskis savo 1992 m Naudingų daiktų evoliucija , nuolatinis tobulinimas yra įprasta technologijos taisyklė. Inžinieriai nuolat pastebi savo projektų trūkumus ir po truputį juos taiso – šį procesą Petroskis niūriai apibūdino kaip gedimą seka forma. Dėl to produktai palaipsniui tobulėja.

Deja, programinė įranga atrodo kitaip. Galima tikėtis, kad 45 milijonų eilučių programa, pvz., „Windows XP“, naujausia „Microsoft“ operacinė sistema, turės keletą klaidų. O programinės įrangos inžinerija yra naujesnė disciplina nei mechaninė ar elektros inžinerija; pirmosios tikros programos buvo sukurtos tik prieš 50 metų. Tačiau iš tikrųjų stebina tai, kad daugelis programinės įrangos inžinierių mano, kad programinės įrangos kokybė negerėja. Jie sako, kad viskas blogėja. Atrodo, kad 2002 m. Detroite pagaminti automobiliai būtų mažiau patikimi nei tie, kurie buvo pagaminti 1982 m.

Kadangi programinė įranga tampa vis svarbesnė, galimas blogo kodo poveikis padidės, kaip teigia Peteris G. Neumannas, kompiuterių mokslininkas iš SRI International, privataus tyrimų ir plėtros centro Menlo parke, Kalifornijoje. Vien per pastaruosius 15 metų programinės įrangos defektai sužlugdė Europos palydovo paleidimą, metams atidėjo itin brangaus Denverio oro uosto atidarymą, sunaikino NASA Marso misiją, žuvo keturi jūrų pėstininkai per sraigtasparnio katastrofą, paskatino JAV karinio jūrų laivyno laivą sunaikinti. civilinio lėktuvo, o Londone išjungė greitosios medicinos pagalbos sistemas, dėl kurių žuvo net 30 žmonių. Dėl didėjančios priklausomybės nuo tinklo Neumannas sako: „Mums daug blogiau nei prieš penkerius metus. Rizika yra didesnė, o gynyba nėra tokia gera. Mes einame atgal – ir tai yra baisu.



Kai kurios programinės įrangos įmonės reaguoja į šią kritiką atnaujindamos savo procedūras; „Microsoft“, pakerėta kaltinimų, kad jos produktai yra klaidingi, viešai pirmauja. Tačiau problemos, susijusios su programinės įrangos kokybe, ištvėrė taip ilgai ir atrodo taip sunkiai įterptos į programinės įrangos kultūrą, kad kai kurie programuotojai pradeda galvoti apie tai, kas neįsivaizduojama. Savo pačių nuostabai šie žmonės susimąstė, ar tikroji programinės įrangos problema yra ta, kad nėra pakankamai teisininkų.

Logikos trūkumas

„Microsoft“ išleido „Windows XP“ 2001 m. spalio 25 d. Tą pačią dieną, galbūt rekordiškai, bendrovė paskelbė 18 megabaitų pataisymų savo svetainėje: klaidų pataisymai, suderinamumo naujinimai ir patobulinimai. Dvi pataisos ištaisė svarbias saugumo spragas. Tiksliau, vienas iš jų padarė; kitas pleistras neveikė. „Microsoft“ patarė (ir vis dar pataria) vartotojams prieš diegiant pataisas pasidaryti atsargines svarbių failų kopijas. Tačiau namų versijos „Windows XP“ pirkėjai išsiaiškino, kad sistema nesuteikė būdo atkurti šių atsarginių failų, jei viskas pasisektų. Kaip švelniai paaiškino „Microsoft“ internetinė žinių bazė, specialūs „Windows XP Home“ sukurti atsarginiai diskeliai neveikia su „Windows XP Home“.



Kritikai teigia, kad tokie slydimai yra tik paviršiniai trūkumai – ženklai, rodantys, kad programinės įrangos kūrėjai per daug skubėjo arba per neatsargiai ištaisė akivaizdžius defektus. Pasak R. A. Downeso iš „Radsoft“, programinės įrangos konsultavimo įmonės, tikrosios problemos slypi pagrindinėje programinės įrangos konstrukcijoje. O tiksliau, jos trūkumas dizaino. „Microsoft“ populiari „Visual Studio“ programavimo programinė įranga yra Downeso mąstymo būdo pavyzdys. Tiesiog užvedęs žymeklį ant „Visual Studio“ lango, Downesas pastebėjo, kad jis nepastebimai užtveria centrinį procesorių tūkstančiais nereikalingų pranešimų, nors programa nieko nedaro. Tai kataklizma. Tai visiškas chaosas, skundžiasi jis.

Rice universiteto kompiuterių mokslininko Dano Wallacho nuomone, problema nėra beprasmiškas procesoriaus kramtymas – juk, pažymi jis, apdorojimo galia yra pigi. Microsoft programinė įranga taip pat nėra ypač ydinga; kritikai dažnai naudoja įmonės produktus kaip pavyzdžius labiau dėl to, kad jie yra pažįstami, o ne todėl, kad jie yra neįprastai blogi. Vietoj to, Wallach nuomone, klesti, šurmuliuojanti painiava „Visual Studio“ ir daugybėje kitų programų išduoda, kaip programinės įrangos rašymo technikos nesugebėjo neatsilikti nuo sparčiai didėjančio jos sudėtingumo.

Programuotojai rašo kodą tokiomis kalbomis kaip Java, C ir C++, kurias gali skaityti žmonės. Specializuotos programos, žinomos kaip kompiliatoriai, paverčia šį kodą į kompiuterių naudojamas vienetų ir nulių eilutes. Svarbu tai, kad kompiliatoriai atsisako kompiliuoti kodą su akivaizdžiomis problemomis – vietoj to jie išspjauna klaidų pranešimus. Iki aštuntojo dešimtmečio kompiliatoriai sėdėjo ant didelių pagrindinių kompiuterių, kurie dažnai buvo užsakyti prieš kelias dienas ar savaites. Nenorėdami, kad klaidos vėluotų, programuotojai, kurie pradžioje buvo mokomi matematikų ar fizikų, vėlavo savo biure ir nuodugniai tikrino savo darbą. Programinės įrangos rašymas buvo panašus į mokslinių darbų rašymą. Griežtumas, dokumentacija ir tarpusavio peržiūros tikrinimas buvo įprastas.



Tačiau plačiai paplitus kompiuteriams požiūris pasikeitė. Užuot kruopščiai suplanavę kodą, programuotojai visą naktį vykdavo įsilaužimo seansuose su kofeinu ir nuolat gaudavo rezultatus iš kompiliatoriaus. Vėl ir vėl kompiliatorius išspjaudavo klaidų pranešimus; programuotojai taisydavo klaidas po vieną, kol programinė įranga būtų tinkamai sukompiliuota. Šiandien laikomasi nuostatos, kad galite parašyti bet kokį netvarkingą kodo fragmentą, o kompiliatorius atliks diagnostiką, sako SRI Neumannas. Jei jis neišspjauna klaidos pranešimo, tai turi būti padaryta teisingai, tiesa?

Tačiau didėjant programų dydžiui ir sudėtingumui, išryškėjo šio kodo ir taisymo metodo ribos. Remiantis daugiamečiu 13 000 programų tyrimu, kurį atliko Humphrey iš Carnegie Mellon, profesionalūs programuotojai padaro vidutiniškai nuo 100 iki 150 klaidų tūkstančiuose parašytų kodo eilučių. Remiantis Humphrey skaičiais, verslo operacinė sistema Windows NT 4, turinti 16 milijonų kodo eilučių, būtų parašyta su maždaug dviem milijonais klaidų. Dauguma jų būtų buvę per maži, kad padarytų kokį nors poveikį, tačiau kai kurie – daugelis tūkstančių – būtų sukėlę rimtų problemų.

Natūralu, kad „Microsoft“ nuodugniai išbandė NT 4 prieš išleisdama, tačiau beveik bet kuriame bandymų etape rasite mažiau nei pusę defektų, sako Humphrey. Jei „Microsoft“ būtų atlikusi keturis bandymų etapus – brangią ir daug laiko reikalaujančią procedūrą, įmonė būtų radusi daugiausia 15 iš 16 klaidų. Tai paliks jums maždaug penkis defektus tūkstančiui kodo eilučių, sako Humphrey. Tai labai mažai, tačiau programinėje įrangoje vis tiek būtų net 80 000 klaidų.

Programinės įrangos inžinieriai žino, kad jų kode dažnai gausu spragų, ir jie jau seniai ieško naujų technologijų, kaip jų išvengti. Siekdami valdyti vis labiau besiplečiančius projektus, pavyzdžiui, „Windows“, jie sukūrė įvairių metodų, iš kurių bene geriausiai žinomas yra komponentais pagrįstas dizainas. Lygiai taip pat, kaip namai statomi naudojant standartizuotus du po keturis ir elektros įrangą, komponentais pagrįstos programos kuriamos iš modulinių, keičiamų elementų: pavyzdys yra beveik identiška meniu juosta kiekvienoje „Windows“ ar „Macintosh“ programoje. Tokie standartizuoti komponentai, anot Wallacho, yra ne tik gera inžinerinė praktika, bet ir vienintelis būdas iš viso padaryti kažką tokio, kaip Microsoft Office. „Microsoft“, anot jo, buvo ankstyva, agresyvi šio požiūrio propaguotoja – tai vienintelis geriausias jų kada nors priimtas inžinerinis sprendimas.

Deja, kritikai sako, kad komponentai dažnai suklijuojami neturint tikro centrinio plano – tarsi rangovai bandytų statyti dideles konstrukcijas be brėžinių. Neįtikėtina, sako Humphrey, kad didelių programinės įrangos projektų dizainas kartais yra tik keli burbuliukai voko gale. Dar blogiau, kad dėl rinkodaros priežasčių įmonės į naują programinę įrangą įdeda kuo daugiau funkcijų, o tai neutralizuoja modulinės konstrukcijos pranašumus. Labiausiai paplitęs pavyzdys yra pati „Windows“, kuri, kaip pareiškė Billas Gatesas per „Microsoft“ antimonopolinio tyrimo balandį, tiesiog neveiks, jei klientai pašalintų atskirus komponentus, tokius kaip naršyklės, failų tvarkyklės ar el. pašto programos. Tai neįtikėtinas teiginys, sako Neumannas. Tai reiškia, kad tai, kaip jie sukūrė tas sistemas, neturi jokios struktūros ar architektūros, rimo ar priežasties, išskyrus tai, kad jos būtų kuo labiau sujungtos, kad pašalinus kurią nors dalį viskas suges.

Kritikai teigia, kad netinkamas galutinių gaminių dizainas atspindi netinkamą jų kūrimo proceso planavimą. Pagal Standish Group, konsultacinės įmonės West Yarmouth, MA, tyrimą, JAV komercinės programinės įrangos projektai yra taip prastai suplanuoti ir valdomi, kad 2000 m. beveik ketvirtadalis buvo atšaukti iš karto, nesukuriant jokio galutinio produkto. Atšaukti projektai įmonėms kainavo 67 mlrd. kitų projektų viršijimas atnešė dar 21 mlrd. Tačiau kadangi kodas ir pataisymas sukelia tokius didelius ir brangius testavimo etapus, net sėkmingi projektai gali būti nepaprastai neveiksmingi. Neįtikėtina, kad programinės įrangos projektai dažnai skirti 80 proc savo biudžeto lėšų trūkumams taisyti jie patys sukūrė – šis skaičius neapima dar brangesnio produkto palaikymo teikimo ir pataisų kūrimo po išleidimo rastoms problemoms spręsti.

Sistemos testavimas trunka beveik pusę proceso, sako Humphrey. Ir net kai jie pagaliau pradeda veikti, vis tiek nėra dizaino. Todėl programinės įrangos negalima atnaujinti ar tobulinti užtikrinant, kad atnaujinimai ar patobulinimai nesukels didelių gedimų. Taip visur kuriama ir kuriama programinė įranga – taip yra erdvėlaiviuose, dėl Dievo meilės.

Ar programinė įranga yra ypatingas atvejis?

Galimas blogos programinės įrangos pavojus buvo niūriai iliustruotas 1985–1987 m., kai vyriausybės remiamos Kanados atominės energijos kompanijos pagamintas kompiuteriu valdomas spindulinės terapijos aparatas JAV ir Kanadoje masiškai perdozavo pacientų, žuvo mažiausiai trys. Atlikdama išsamų tyrimą, Nancy Leveson, dabar MIT kompiuterių mokslininkė, didžiąją dalį kaltės priskyrė netinkamai gamintojo programinės įrangos kūrimo praktikai. Kadangi spinduliuotės intensyvumui nustatyti naudojama programa nebuvo sukurta ar kruopščiai išbandyta, paprastos spausdinimo klaidos sukėlė mirtinus sprogimus.

Nepaisant šios tragiškos patirties, panašios mašinos, kuriose veikia Sent Luiso „Multidata Systems International“ sukurta programinė įranga, 2000 ir 2001 m. Panamoje smarkiai perdozavo pacientų, dėl kurių mirė dar aštuonios. Tarptautinės atominės energijos agentūros komanda mirties atvejus priskyrė duomenų įvedimui tokiu būdu, kurio programišiai nesitikėjo. Kaip pažymi Levesonas, paprastos duomenų įvedimo klaidos neturėtų turėti mirtinų pasekmių. Taigi šis gedimas taip pat gali būti dėl netinkamos programinės įrangos.

Programavimo ekspertai linkę sutikti, kad tokios nelaimės yra labai dažnos. Apsvarstykite „Mars Climate Orbiter“ ir „Polar Lander“, kuriuos 1999 m. sunaikino pažįstamos, lengvai išvengiamos kodavimo klaidos. Tačiau kai kurie teigia, kad programinės įrangos tiesiog negalima vertinti, išmatuoti ir tobulinti taip, kaip kitų inžinerinių produktų. Faktas yra tai, kad yra dalykų, kuriuos gali padaryti kiti inžinieriai, kurių mes negalime padaryti, sako Shari Lawrence'as Pfleegeris, vyresnysis mokslininkas iš Rand ekspertų grupės Vašingtone ir 2001 m. tomo autorius. Programinės įrangos inžinerija: teorija ir praktika . Jei tiltas atlaikys 500 ir 50 000 kilogramų svorį, pažymi Pfleegeris, inžinieriai gali manyti, kad jis turės visas reikšmes tarp jų. Ji sako, kad su programine įranga negaliu daryti tokios prielaidos – negaliu interpoliuoti.

Be to, programinės įrangos kūrėjai dirba pagal ypatingus reikalavimus. „Ford“ ir „General Motors“ dešimtmečius gamina tą patį produktą – keturių ratų dėžę su vidaus degimo varikliu. Dėl to, sako Charlesas H. Connellas, buvęs pagrindinis Lotus Development (dabar priklauso IBM) inžinierius, jie sugebėjo palaipsniui tobulinti savo produktus. Tačiau programinės įrangos įmonių nuolat prašoma kurti produktus – žiniatinklio naršykles 1990-ųjų pradžioje, naujas mobiliųjų telefonų sąsajas šiandien – kitaip nei anksčiau. Panašu, kad automobilių gamintojas sako: „Šiemet vietoj automobilio gaminsime raketinį laivą“, – sako Connell. Žinoma, jie turės problemų.

Klasikinė programinės įrangos dilema yra ta, kad žmonės nuolat nori vis daugiau ir daugiau dalykų, sako Nathanas Myhrvoldas, buvęs „Microsoft“ vyriausiasis technologijų pareigūnas. Deja, jis pažymi, kad nuolatinė naujovių paklausa reiškia, kad programinė įranga visada yra tobulėjimo fazėje, kai produktai iš prigimties yra mažiau patikimi. Pasak jo, 1983 m. „Microsoft Word“ turėjo tik 27 000 kodo eilučių. Bėda ta, kad tai nedavė daug naudos – šiandien klientai to nepriimtų. Jei „Microsoft“ nebūtų nuolat tobulinusi „Word“ naujų funkcijų, produkto nebebūtų.

Myhrvold priduria, kad vartotojai nepaprastai nesuvokia savęs. Pasak jo, „Microsoft“ verslo klientai dažnai reikalaudavo, kad įmonė tuo pačiu metu pridėtų naujų funkcijų ir nebepridėtų naujų. Žodžiu, išgirdau tai vienu atodūsiu, vienu sakiniu. Nesame tikri, kodėl turėtume atnaujinti į šį naują leidimą – joje yra visa tai, ko mes nenorime – ir kada ketini įdėti šiuos tris dalykus?“ O jūs sakote „Whaaat?“ Sardoniška Myhrvoldo santrauka: Programinė įranga blogai, nes vartotojai to reikalauja.

Aukštesni standartai

Sausio mėnesį Billas Gatesas paragino „Microsoft“ darbuotojus, kad jų didžiausias prioritetas būtų patikimas ir saugus kompiuteris. Gatesas pareikalavo, kad „Microsoft“ smarkiai sumažintų savo gaminių defektų skaičių. Po mėnesio įmonė ėmėsi precedento neturinčio žingsnio – beveik dviem mėnesiams sustabdė visų naujų kodų rašymą. Vietoj to jis subūrė programuotojus, tūkstantį vienu metu, į masinius mokymus apie patikimumą ir saugumą. Naudodami didžiulius ekranus milžiniškoje auditorijoje, įmonės vadovai rodė gėdingus klaidingo kodo fragmentus, kuriuos sukūrė žiūrovai.

Geitso iniciatyva, matyt, buvo įkvėpta kritikos, kuri apėmė „Microsoft“ 2001 m. liepos mėn., kai buferio perpildymas – seniai žinomos klaidos tipas – jos interneto informacijos paslaugų žiniatinklio serverio programinėje įrangoje leido „Code Red“ kirminui nukentėti tūkstančius jos verslo klientų. (Buferio perpildymo metu programa gauna daugiau duomenų nei tikėtasi – tarsi pašto kodo vieta būtų užpildyta 50 skaitmenų numeriu. Kompiuteryje papildoma informacija išsilies į gretimas atminties dalis, sugadindama arba perrašydama ten esančius duomenis, nebent jie būtų kruopščiai užblokuoti.) Po dviejų mėnesių Nimda kirminas pasinaudojo kitais programinės įrangos trūkumais, kad atakuotų dar tūkstančius mašinų.

Dėl tokios patirties programinės įrangos kūrėjai tampa vis atidesni kokybei. Netgi tuo metu, kai Geitsas telkė savo kariuomenę, ekspertų grupės, tokios kaip Kestrel institutas iš Palo Alto, Kalifornijos valstijoje, kūrė taisyklingus programavimo įrankių rinkinius, kurie beveik priverčia programuotojus rašyti patikimas programas ( žr. Pirmoji pagalba dėl sugedusio kodo ). Pačioje „Microsoft“, įmonės programuotojų produktyvumo tyrimų centro vadovo Amitabho Srivastavos teigimu, programuotojai dirba su naujomis aukštesnio lygio kalbomis, tokiomis kaip C#, kurios neleidžia daryti tam tikrų klaidų. Gegužės mėnesį „Microsoft“ kartu su NASA ir 16 kitų įmonių įkūrė 30 mln. Kokybės kontrolės pastangos gali atsipirkti su kaupu: padėdamas „Lockheed Martin“ atnaujinti savo C130J orlaivio programinę įrangą, „Praxis Critical Systems“ iš Bato (Anglija) naudojo tokius metodus, kad sumažintų kūrimo išlaidas 80 procentų, gamindama programinę įrangą, kuri išlaikė griežtus Federalinės aviacijos administracijos egzaminus. labai mažai klaidų.

paslėpti