Programavimo pakėlimas į kraštutinumą

Mansouras Raadas turėjo didelę problemą. Jo pradinė įmonė „DiscoverCast“ kūrė susidūrimų aptikimo programinę įrangą, skirtą oro linijų pramonei – kodo klaidos gali kainuoti gyvybes. Tačiau pinigai išseko po pirmojo finansavimo etapo, o papildomų programuotojų samdymas, kad būtų užbaigta nuo klaidų apsaugota versija, nebuvo svarstoma.

Taigi Raad sukūrė palyginti naują kodavimo discipliną, vadinamą ekstremaliu programavimu. Užuot dirbę vieni su individualiomis užduotimis, programuotojai susivienijo, vienas rašė kodą, o kitas stebėjo ir kritikavo – suteikdamas kritišką žvilgsnį ir ypač svarbią atsarginę kopiją. [Mano žmona] susilaukė kūdikio, bet projektas turėjo tęstis, sako Raad. Kadangi aš tai rodžiau kitiems žmonėms, kažkas galėjo įeiti į mano batus. Bendrovė laikėsi terminų, nepadaugėjo klaidų dėl komunikacijos.

Dauguma programuotojų nėra labiau patenkinti programinės įrangos kokybe nei jų klientai. Dabar vis daugiau bando rasti būdų, kaip sukurti patikimą programinę įrangą rinkoje, kuri tikisi naujų produktų ir patobulinimų ir nori jų greitai. Programinės įrangos įmonės vis dažniau kreipiasi į plėtros strategijas, kurių pavadinimai yra judrus vystymasis ir ekstremalios programavimo adrenalino kupinos frazės, puikiai tinkančios programuotojų, kaip tvirtų informacijos amžiaus herojų, įvaizdžiui. Tiesą sakant, ši tendencija, turinti ilgą istoriją, rodo primadonos programavimo atmetimą komandinio darbo ir bendradarbiavimo naudai.

Programinės įrangos pramonėje klaidingas kodas jau seniai buvo priimtas kaip gyvenimo faktas, nors ir sunkinantis ir brangus ( žr. Kodėl programinė įranga tokia bloga, VAIKAI 2002 m. liepos / rugpjūčio mėn ). Problema ta, kad programinės įrangos srityje žmonės per daug pasitiki savo išradingumu, sako Michaelas Stiefelis, konsultantas, mokantis klientus programinės įrangos patikimumo metodų. Stebėčiau, kaip visi šie 20 metų vaikinai daro tas pačias klaidas, kurias padarėme aštuntajame ir devintajame dešimtmetyje, ir galvoju, kodėl mes vėl turime visa tai išgyventi.

Siekdami sumažinti klaidų skaičių, reformatoriai reklamuoja programinės įrangos inžinerijos metodus, kurie pramonėje žinomi kaip judrus vystymas, kurie pabrėžia komandinį darbą, bendradarbiavimą su galutiniais vartotojais ir lankstų požiūrį į pokyčius. Siekdama sukurti susidūrimų išvengimo programinę įrangą, Raad įmonė naudojo vieno tipo judrią plėtrą, vadinamą ekstremaliu programavimu, kuri pabrėžia nuolatinį testavimą ir bendradarbiavimą.

Jei sugebėsite pritaikyti [bendradarbiavimo aplinką] visa galia, produktų kokybė bus geresnė, sako Michele Marchesi, pagrindinė ekstremalaus programavimo šalininkė ir elektros inžinerijos profesorė iš Kaljario universiteto Italijoje.

Vienas iš galingiausių judraus programavimo aspektų yra vadinamasis peer programavimas, kurio metu kūrėjai bendradarbiauja ir paeiliui rašo kodą ir aiškina kitiems jo logiką. Poros yra laikinos, periodiškai išsiskiriančios ir keičiamos, kad paskatintų dar daugiau sąveikos. Naujos akys tiria kiekvieną kodo dalį, sukurdamos nuolatinės peržiūros procesą.

Du žmonės gali atmušti vienas kito idėjas, sako Frankas Arkellas, gynybos rangovo „General Dynamics Decision Systems“, kuris jau du dešimtmečius taiko bendradarbiavimo metodus, vyriausiasis programinės įrangos inžinierius. Kad komandos būtų šviežios, „General Dynamics“ jas keičia kiekvienam projektui.

Kitas bendraamžių programavimo pranašumas? Bendraamžių spaudimas. Niekas nenori būti žmogumi, kuris atsipalaiduoja, todėl jie abu dirba daugiau, sako Scott W. Ambler, Ronin International prezidentas ir autorius bei pranešėjas apie judrią plėtrą.

Išbandyti

Bendradarbiaujantys metodai taip pat keičia programinės įrangos testavimo būdą. Tradiciškai bandymas buvo dviejų etapų procesas. Pirma, programuotojai rašo kodą pagal reikalavimus. Tada atskira grupė patikrina rezultatą. Tačiau kai programinėje įrangoje yra milijonai kodo eilučių, dviejų etapų procesas yra panašus į automobilio projektavimą ant popieriaus, jo sukūrimą ir patikrinimą, ar projektas veikė.

Toks požiūris tiesiog nepasiteisino tokiems kūrėjams kaip Nicholas Stamos, Waltham, MA įsikūrusios Phase Forward vyriausiasis techninis pareigūnas. Phase Forward kuria programinę įrangą, skirtą farmacijos klinikiniams tyrimams vykdyti, o jos produktai turi atitikti griežtus JAV maisto ir vaistų administracijos reikalavimus.

Stamos teigia, kad Phase Forward atitinka šiuos reikalavimus, iš dalies dėl glaudaus ir nuolatinio bendradarbiavimo tarp įmonės programuotojų ir kokybės užtikrinimo personalo. Negalite mesti jo per skersinį ir tikėtis, sako jis. Kokybė turi būti sukurta nuo pat pirmos dienos. Kai programuotojai užbaigia komponentą, kokybės komanda patikrina jų darbą. Tada komandos apsikeičia vietomis į kitą klaidų taisymo etapą. Galiausiai, integruota programa išbandoma, siekiant rasti problemų, susijusių su komponentų sąveika. Vietoj senojo dviejų etapų metodo testavimas tampa interaktyviu, nuolatiniu procesu.

Kai kurios įmonės bando panašų kartotinį metodą ne tik testuodami, bet ir pirmiausia kurdamos kodą. Konsultacijų įmonė „Cognizant Technology Solutions“, įsikūrusi Teaneck mieste, NJ, išsiaiškino, kad esami metodai pradėti nuo formalių specifikacijų, o paskui rašyti kodą, kad būtų patenkinti jas, galėjo veikti prieš 20 ar 30 metų. Tačiau pasaulyje, kuris veikia internete ir kuriam reikia lankstumo, formalumas gali reikšti kietumą.

Kai bandėme naudoti tradicinius procesus šiems naujesnio tipo projektams, klientai tikrai nusivylė, nes privertėme juos sustabdyti procesą, arba projekto komandos tiesiog nesekė proceso, sako „Cognizant“ generalinis direktorius Kumaras Mahadeva. Vietoj to, projektuose naudojama daugybė prototipų, po kurių seka industrializacijos ciklas, leidžiantis įmonei valdyti staigius klientų pokyčius taip, kad būtų mažiau įtakos patikimumui nei programos koregavimas ją užbaigus. Būsimi vartotojai teikia nuolatinį atsiliepimų srautą, kai programa įgauna formą.

Tačiau pagrindinės programinės įrangos kokybės ribos gali būti ne programuotojų įgūdžiuose ar kūrimo proceso stiprume. Tai yra mįslė, su kuria šiandien susiduriame mes ir daugelis gamintojų: koks yra priimtinas kokybės lygis? sako Jamesas Hymelis, „Motorola“ programinės įrangos inžinerijos direktorius. Jei konkurentai gamina mielus, pigius, bet bugiškus [produktus], o klientai sako, kad tai priimtina, t.

Taikydami tokius metodus kaip judrus kūrimas, kūrimo ir testavimo partnerystė ir galutinių vartotojų įtraukimas, programinės įrangos kūrėjai imasi veiksmų savo produktui tobulinti. Tačiau galų gale didžiausias kokybės suvaržymas gali būti tie patys žmonės, kurie jos reikalauja garsiausiai: vartotojai.

paslėpti