Programmēšanas līdz galējībai

Mansour Raad bija liela problēma. Viņa jaunizveidotā firma DiscoverCast izstrādāja sadursmju noteikšanas programmatūru aviosabiedrību nozarei — kļūdas kodā var maksāt dzīvības. Taču nauda izsīka pēc pirmās finansēšanas kārtas, un papildu programmētāju nolīgšana, lai pabeigtu pret kļūdām drošu versiju, nebija jautājuma.

Tātad Rāts ierosināja salīdzinoši jaunu kodēšanas disciplīnu, ko sauc par ekstrēmo programmēšanu. Tā vietā, lai strādātu vieni ar atsevišķiem uzdevumiem, programmētāji sadarbojās pārī, viens rakstīja kodu, bet otrs skatījās un kritizēja, nodrošinot gan kritisku aci, gan kritiski svarīgu rezerves kopiju. [Manai sievai] bija bērns, bet projektam bija jāturpina, saka Rāds. Tā kā es to rādīju citiem cilvēkiem, kāds varēja iekāpt manās kurpēs. Uzņēmums ievēroja termiņus, nepalielinot kļūdu skaitu komunikācijas dēļ.

Lielākā daļa programmētāju nav apmierinātāki ar programmatūras kvalitāti nekā viņu klienti. Tagad arvien vairāk cilvēku cenšas atrast veidus, kā izveidot stabilu programmatūru tirgū, kas sagaida jaunus produktus un uzlabojumus un vēlas tos ātri. Arvien biežāk programmatūras uzņēmumi pievēršas attīstības stratēģijām ar tādiem nosaukumiem kā veiklā izstrāde un ekstrēmas programmēšanas adrenalīna uzpildītas frāzes, kas ir labi piemērotas kodētāju paštēlam kā izturīgiem informācijas laikmeta varoņiem. Patiesībā šī tendence, kurai ir sena vēsture, liecina par primadonnas programmēšanas noraidīšanu par labu komandas darbam un sadarbībai.

Programmatūras nozarē kļūdains kods jau sen ir pieņemts kā dzīves fakts, kaut arī tas ir apgrūtinošs un dārgs ( skatiet, kāpēc programmatūra ir tik slikta, BĒRNI 2002. gada jūlijs/augusts ). Problēma ir tā, ka programmatūras jomā cilvēki pārāk uzticas savai atjautībai, saka Maikls Stīfels, konsultants, kurš apmāca klientus programmatūras uzticamības metodēs. Es noskatījos, kā visi šie jaunie puiši 20. gados pieļauj tās pašas kļūdas, ko pieļāvām 70. un 80. gados, un domāju, kāpēc mums tas viss ir jāpiedzīvo vēlreiz.

Lai samazinātu kļūdas, reformu veidotāji reklamē programmatūras inženierijas pieejas, kas nozarē pazīstamas kā elastīga izstrāde, kas uzsver komandas darbu, sadarbību ar galalietotājiem un elastīgu pieeju pārmaiņām. Lai izveidotu sadursmju novēršanas programmatūru, Raad uzņēmums izmantoja viena veida veiklu izstrādi, ko sauc par ekstrēmo programmēšanu, kas uzsver pastāvīgu testēšanu, kā arī sadarbību.

Ja varēsit izmantot [sadarbības vidi] ar pilnu jaudu, produktu kvalitāte būs labāka, saka Mišela Markesi, vadošā ekstrēmas programmēšanas aizstāve un elektrotehnikas profesore Kaljāri Universitātē Itālijā.

Viens no spēcīgākajiem veiklās programmēšanas aspektiem ir tā sauktā peer programmēšana, kurā izstrādātāji sadarbojas un pārmaiņus raksta kodu un izskaidro otram tā loģiku. Pāri ir īslaicīgi, periodiski sadalās un mainās, lai veicinātu vēl vairāk mijiedarbības. Jaunas acis pārbauda katru koda daļu, radot nepārtrauktas pārskatīšanas procesu.

Divi cilvēki var radīt idejas viens otram, saka Frenks Ārkels, aizsardzības darbuzņēmēja General Dynamics Decision Systems galvenais programmatūras inženieris, kurš ir izmantojis sadarbības metodes jau divus gadu desmitus. Lai komandas būtu svaigas, General Dynamics tās maina katram projektam.

Vēl viena vienaudžu programmēšanas priekšrocība? Vienaudžu spiediens. Neviens nevēlas būt tas, kurš slinko, tāpēc viņi abi strādā vairāk, saka Skots V. Amblers, Ronin International prezidents un autors un runātājs par veiklu attīstību.

Lieciet pārbaudīt

Sadarbības pieejas arī maina programmatūras testēšanas veidu. Tradicionāli testēšana ir bijusi divpakāpju process. Pirmkārt, programmētāji raksta kodu, pamatojoties uz prasībām. Pēc tam rezultātu pārbauda atsevišķa grupa. Bet, ja programmatūra ietver miljoniem koda rindu, divpakāpju process ir līdzīgs automašīnas projektēšanai uz papīra, tā uzbūvēšanai un pēc tam pārbaudīšanai, vai dizains darbojas.

Šī pieeja vienkārši nedarbojās tādiem izstrādātājiem kā Nikolass Stamoss, Waltham, MA Phase Forward galvenais tehniskais darbinieks. Phase Forward izstrādā programmatūru farmaceitisko klīnisko izmēģinājumu veikšanai, un tās produktiem ir jāatbilst stingrām ASV Pārtikas un zāļu pārvaldes prasībām.

Stamos saka, ka Phase Forward atbilst šīm prasībām, daļēji pateicoties ciešai un pastāvīgai sadarbībai starp uzņēmuma programmētājiem un kvalitātes nodrošināšanas personālu. Viņš saka, ka jūs nevarat to mest pāri šķērsām un cerēt. Kvalitāte ir jāveido jau no pirmās dienas. Kad programmētāji pabeidz kādu komponentu, kvalitātes komanda pārbauda viņu darbu. Pēc tam komandas apmainās vietām ar citu kļūdu labojumu kārtu. Visbeidzot, integrētā lietojumprogramma tiek pārbaudīta, lai atrastu problēmas ar komponentu mijiedarbību. Vecās divpakāpju pieejas vietā testēšana kļūst par interaktīvu, nepārtrauktu procesu.

Daži uzņēmumi izmēģina līdzīgi iteratīvu pieeju ne tikai testēšanai, bet arī koda izstrādei. Konsultāciju uzņēmums Cognizant Technology Solutions, kas atrodas Tenekā, Ņūdžersijā, ir atklājis, ka esošās metodes, kas sākas ar formālām specifikācijām un pēc tam koda rakstīšanu, lai tās apmierinātu, varēja darboties pirms 20 vai 30 gadiem. Taču pasaulē, kas darbojas tīmeklī un kurai ir nepieciešama elastība, formāls var nozīmēt stīvumu.

Kad mēs mēģinājām izmantot tradicionālos procesus šiem jaunāka veida projektiem, vai nu klienti bija patiešām neapmierināti, jo mēs piespiedām viņus iesaldēt procesu, vai arī projekta komandas vienkārši neseko procesam, saka Cognizant izpilddirektors Kumars Mahadeva. Tā vietā projektos tiek izmantota virkne prototipu, kam seko industrializācijas cikls, ļaujot uzņēmumam rīkoties ar pēkšņām klientu izmaiņām tādā veidā, kas mazāk ietekmē uzticamību nekā programmas pielāgošana pēc tās pabeigšanas. Nākamie lietotāji nodrošina vienmērīgu atgriezenisko saiti, lietojumprogrammai veidojoties.

Taču programmatūras kvalitātes galīgie ierobežojumi var nebūt programmētāju prasmēs vai izstrādes procesa stiprumā. Šī ir problēma, ar kuru šodien saskaramies mēs un daudzi ražotāji: kāds ir pieņemams kvalitātes līmenis? saka Džeimss Haimels, Motorola programmatūras inženierijas direktors. Ja jums ir konkurenti, kas izdod glītus, lētus, bet buggy [produktus], un klienti saka, ka tas ir pieņemami, tas ir, viņi tērē viņiem naudu, jūs tiksit apstrīdēts.

Izmantojot tādas metodes kā elastīga izstrāde, izstrādes un testēšanas partnerība un galalietotāju iesaistīšana, programmatūras izstrādātāji veic pasākumus, lai uzlabotu savu produktu. Bet galu galā vislielākais kvalitātes ierobežojums var būt tie paši cilvēki, kuri to pieprasa visskaļāk: patērētāji.

paslēpties