Чифт програмиране, Computerworld България, издателски "отворени системи"

ИТ инфраструктурата за вашето предприятие

Комбинирането на развитие в група от двама души могат да се повиши качеството на генерираните заявлението на "другарите" ще се напише програма, с голямо удоволствие.

Има класове, че ако те искат да споделят с никого трудно - пасианс, шофиране, четене. Изглежда, че едно и също нещо се прилага изцяло за писане на програми. Когато става въпрос за разработка на софтуер, апелирам към образа на един мършав мъж с нездрав блясък в очите му, отпечатан списък на екрана на компютъра и трудно да се запълни своя ред код. (Да, да, разбира се, стои до бутилката кокс и смачкания пакет чипс.) Но това е вярно, че една група от "егоцентрик" - наистина най-добрият отбор за създаване на софтуер?

Привържениците на сравнително новия програмен философия, наречена програмирането по двойки (част от подхода, известен като Extreme Programming или XP), твърдейки, че асоциацията на разработчиците в подгрупата на двама души могат да се повиши качеството на генерираните приложение. Освен това се твърди спътници ще получат от своята дейност повече задоволителни. Привържениците на този подход смятат, че това е, че въпреки очевидната съкращения, обещава големи спестявания, тъй като качеството на софтуера ще бъде по-висока по отношение на адаптирането ще остави много по-малко време. И тъй като разработчиците ще бъдат щастливи, неговото управление ще бъде в състояние да се избегнат разходите, възникнали във връзка с напускането на ключови служители. (В този случай, още никой не брои, тя ще прелее в цената на една кола и чипс).

метод програмирането по двойки се приема, че две разработчиците са седнали един до друг на един и същ компютър, и заедно представляват една и съща част от софтуера. Много начин на взаимодействие между двете програмисти и по-специално необходимостта да се работи на един компютър може да изглежда неефективно и напълно безполезни. Тогава защо програмирането по двойки вече е причина за толкова много интерес? Ще се опитам да отговоря на този въпрос.

Съвместна собственост на код

Ще започна с обща дискусия. На първо място, тъй като развитието на проекта започва за програмирането по двойки? Като част от модела, XP, голямата част от работата по проекта е формулиран с помощта на КРС карти (клас, отговорност за съвместна работа - «отговорности класа и сътрудничество") - листа хартия, които са предмет на проекта.

Преди началото на работната група по проекта е среща, на която моделира връзката на всички известни обекти, както и на КРС карти се използват за целите на илюстрацията. Програмистите трябва да се обсъдят аспекти от най-съмнителни, както и премахване или добавяне на нови карти, за да се отразят промените в плана. Описването на обектите като отделни юридически лица, сложни концепции могат да бъдат опростени, като ги трансформира в ясна структура.

Резултатът от стъпка CRC става списък на малки задачи. Разработчиците се разделят на двойки, като всяка двойка определя тестова единица за избраната задача с нея. Трябва да се отбележи, че тези тестове са създадени преди да започне процеса на кодиране. Според привържениците на XP, този подход опростява и ускорява развитието на приложения: Тестовете са написани в същото време по-внимателно, защото те се използват за тестване на критична функционалност също така подобрява обратната връзка за да се определи какво точно трябва да се направи. С други думи, няма нужда да прекарват времето си създава огромен тест за проверка на изпълнението на проекта като цяло.

След това всяка двойка разработчик започва кодиране в съответствие със спецификациите на нейната задача. Висококвалифициран програмист винаги в двойка с по-малко опитни предприемачи. Последно "зад волана" - това е, програмата се набира на клавиатурата, както и първата вахта на рамото на начинаещи. Въпреки това, "водача" е длъжен да спазва кодекса за грамотност, тоест, синтаксис и правилното изграждане и "Навигатор" е отговорен за цялостната логика на проекта и следва да наблюдават грешки, които биха могли да попречат на "водача".

Въпреки това, използването на чифт програмен модел не означава, че разработчиците са принудени да седят един до друг през целия жизнен цикъл на проекта. Работата може да се уреди по-гъвкаво. Програмистите могат да работят в тандем, за да се създаде, например, един модул или на конкретна функция, и след това да се присъединят към другите групи. Във всеки случай, ролята на работниците не е задължително строго дефинирани - клавиатурата не може просто да отиде от ръка на ръка по време на писане на програмата.

След като кодът, който реализира решаването на проблема, който е отговорен за една или друга двойка се приключи, стартирайте са дефинирани преди теста. Ако кодът не е преминал изпитването може да се модифицира или теста или кода. Ако тестът е успешен, кодът е интегриран в хранилището, където тя може да бъде достъпен от всички членове на екипа за развитие. Модифицираният код трябва да бъде поставен в хранилището на всеки няколко часа (най-малко веднъж на ден). В същото време, всички разработчици ще получат действителният код - такъв подход намалява вероятността от грешки в проекта, свързани с версии несъответствия.

Ако в процеса на писане на код партньори стигат до заключението, че те се нуждаят от помощ при решаване на конкретен проблем, те могат да поискат да се образува нов чифт за тази задача. Обикновено, един от програмистите на първата двойка е свързана с другия отбор, а втората с новия разработчик продължава да отговаря на въпроси.

Когато пишете програми XP привържениците често се отнасят до процедурата, която се нарича разширяване (рефакториране), което предполага постоянно преразглеждане код с цел опростяване, така че програмата става възможно най-кратък. С кристално яснота на код, програмисти сведе до минимум необходимостта от корекция на различни видове дефекти по-късно. Методи за разлагане позволява бързо откриване на грешки и да ги поправи веднага.

Последната стъпка - създаването на цялото тяло и функционални тестове. Много е вероятно, че този процес ще трябва да се повтори няколко пъти, докато не може да достигне до правилната работа и взаимодействието на всички обекти. Може да се наложи да прекарат няколко CRC-сесии; Обектите, които не преминават функционални изследвания, трябва да бъдат прехвърлени към финализиране друга двойка програмисти.

От научна гледна точка

Резултати: двойки винаги създават по-разбираем код, в които има по-малко грешки, а освен това, програмисти признати, че този начин на работа да ги хареса повече от решаването на същия проблем сам много. От друга страна, създаването на двойки код отне малко повече от програмисти, които действат самостоятелно. Но и последвалите версии дават резултати много по-бързо. По този начин, въпреки че за първи път, разработчиците вече "набраха скорост" (и можем да предположим, че програмирането по двойки - не най-доброто решение за проекти с много кратки срокове), изглежда, че хората бързат да се адаптира към процеса.

Не можем да кажем, че програмирането двойка - тя винаги е добре. Някои от програмистите вярвал занаята си дълбоко личен въпрос и се чувства неудобно, когато трябва да го споделя с никой друг. В допълнение, много лидери са ужасени от мисълта, че е необходимо да се използва и като ограничен ресурс, тъй като разработчиците. Трябва да се има предвид, че мъж и жена не може да работи в случай на каквито и да било лични конфликти - някои хора просто не са в състояние да работят с други хора.

Времето ще покаже, ако програмирането по двойки оправдаят себе си (и екстремно програмиране като цяло). В компаниите, в които тази техника е вече в употреба, като DaimlerChrysler и Ford Motor, не бързайте да се правят заключения. Тези, които имат дълъг притеснен за болезнени въпроси в развитието на приложение - за организиране на комуникацията между програмисти, изключителната сложност, контрол и управление, и, разбира се, качеството на софтуера, че има смисъл да се опитваме да сдвоите програмиране.

програмиране двойка

Според привържениците на този подход, програмирането по двойки (програмирането по двойки) може да осигури значително увеличаване на качеството на софтуера, актуализиране на знанията на служителите, а също и да направи да работят по-приятни програмисти. Но не всички могат да работят заедно. Функционални модули от една двойка, редовно се прехвърлят върху други членове на групата на разработчиците, които допринасят за по-тясно сътрудничество между програмисти и обмен на знания помежду си.

Предимства: стимулира непрекъснатото учене; подобрява работна група и укрепва връзката между участниците; Това прави по-лесно за решаване на проблемите
Недостатъци: може да генерира лични конфликти и недоразумения; може да се удължи цикъла на развитие; недостатъчно тествани метод

Чифт програмен модел

В допълнение към това метод програмирането по двойки включва обединяване на разработчиците по двойки и насърчава по-тясното сътрудничество между тях, тя е част от една по-обща методология за развитие, която осигурява стъпка по стъпка план, непрекъснато тестване и разпадане - процесът на подобряване и опростяване на кода. Този метод позволява също така, ако е необходимо, промяна на състава на парата в рамките на екипа за развитие

Сподели снимки с приятели и колеги