XP versus open source

Je možné pomocí technik extrémního programování vytvářet open source software? Mohou tyto dvě techniky koexistovat? ...


Je možné pomocí technik extrémního programování vytvářet open source software?
Mohou tyto dvě techniky koexistovat?
Podívejme se, jak spolu souvisejí základní principy extrémního programování a
metody, které jsou obvykle uplatňovány při vývoji open source projektů.

Plánovací hra
Návrh projektu by podle zastánců extrémního programování měl vznikat za
spolupráce se zákazníkem, tedy s konečným uživatelem softwaru, který nejlépe
ví, jak a k čemu bude vyvíjený produkt používán. Vývojáři open source softwaru
jsou většinou v první fázi projektu sami svými zákazníky. Výsledky projektu
chtějí používat pro sebe, pro své potěšení nebo práci. Takto vznikla většina
open source projektů např. i operační systém Linux. Poněkud problematické je
zapojení uživatele/zákazníka do vývoje projektu. Uživatelé spíše vývojářům
navrhují nové vlastnosti nebo oznamují chyby, ale jejich přímé zapojení do
vývoje nebo systematické testování není v open source projektech obvyklé a
rozšířené.

Akceptační testy
Testování v open source komunitě je obecně obrovský problém. Vývojáři jej
jakoby přenášejí na koncové uživatele. Tím se ale bohužel nevyhnou
nekvalifikované zpětné vazbě od uživatelů, kteří narazí na nějaké chyby a v
konečném důsledku budou muset vyvinout mnohem více energie, než kdyby provedli
základní testování vlastními prostředky. Stejně jako všude i mezi open source
softwarem existují vzácné výjimky. Některé projekty (např. oblíbený databázový
server PostgreSQL) mají vybudováno rozsáhlé testovací prostředí a před
uvolněním každé verze ji podrobí náročným automatizovaným testům včetně testů
výkonnostních.

Rychle a často
Při systematickém vývoji open source softwaru jsou používány dva vývojové
modely: model katedrály a model bazaru; oba popsal ve svém eseji "Cathedraal
and Bazaar"
(http://tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/) Eric
Raymond.
Model katedrály se vyznačuje uzavřenou skupinkou vývojářů, kteří jednou za
(dlouhý) čas zveřejní další verzi vyvíjeného softwaru. Tento model po dlouhou
dobu používal např. GNU Emacs, projekt vedený Richardem. M. Stallmanem. Model
bazaru potom přímo koresponduje s druhou zásadou extrémního programování.
Ostatně oblíbený slogan extrémního programování "release early, release often"
pochází z citovaného díla.

Jednoduchý návrh
Aneb v jednoduchosti je síla. Jednoduchý, ale efektní návrh se skrývá za
většinou open source programů. Při open source programování, kdy jsou
programátoři nezřídka rozmístěni po celé zeměkouli, je příprava detailní
analýzy projektu považována za ztrátu času. Mnoho distribuovaných open source
projektů dokonce skončilo ve fázi detailní analýzy, protože většina vývojářů o
takový projekt ztratila zájem. V open source projektech je tento aspekt nutno
vzít v potaz, a pokud se najdou jeden nebo dva vývojáři, kteří chtějí problém
hlouběji analyzovat, neměli by totéž chtít po ostatních.

Párové programování
Programování v páru není v typickém open source projektu možné používat,
protože vývojáři jsou rozmístěni po celém světě. Jistou formou této metody může
být on--line konzultace programátora s jinými pomocí messaging technologií,
jako je IRC nebo Jabber, nicméně opravdové programování v páru to samozřejmě
není. Programátorské styly

Většina open source projektů má definovány své standardy, jak mají vypadat
zdrojové soubory, jak odsazovat jednotlivé bloky kódu, jak má být zdrojový kód
komentován. Obecně lze říci, že čím větší projekt, tím lepší pravidla má
stanovena. Velmi dobrým příkladem je např. linuxové jádro nebo tzv. coding
standards projektu GNU.

Kolektivní kód
Pod tímto termínem je v extrémním programování myšleno, že každý programátor,
který narazí na chybu, ji má také opravit a to i tehdy, když není autorem dané
části kódu. Tento princip je v mnoha open source projektech aplikován pouze
částečně. Vzhledem k rozsahu těchto projektů jsou definována pravidla pro
odstranění chyby v různých částech kódu. Např. v linuxovém jádře existuje
několik správců kódu, kteří "vlastní" určité části kódu. Jejich rukama musí
projít téměř všechny opravy chyb.

40hodinový týden
Tento princip je v open source projektech poměrně těžko aplikovatelný, protože
mnoho vývojářů pracuje na těchto projektech ve svém volném čase.

Integrace změn
I v aplikaci tohoto principu je mezi open source projekty možné nalézt oba
extrémy. U některých projektů je možné sledovat snahy o prakticky okamžitou
integraci změn (samozřejmě při zachování určitého standardu kvality), jiné
projekty jsou v tomto směru výrazně pomalejší. U větších projektů může být
dokonce situace odlišná u jednotlivých částí projektu. Vždy záleží na
konkrétních jednotlivcích.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.