Na prośbę kilku czytelników bloga publikuje treść artykułu mojego autorstwa zamieszczonego w najnowszym numerze kwartalnika Quale. Jak zwykle zapraszam do lektury i pozostawiania komentarzy....

Po pierwsze: Repozytorium Kodu Źródłowego
Narzędzie do kontroli wersji kodu oraz synchronizowania zmian
poszczególnych członków zespołu nie jest oczywiście czymś unikalnym w projektach
zwinnych, jest tak samo ważne we wszystkich metodykach, ale piszę o nim,
ponieważ bez niego zespół nie będzie w stanie normalnie pracować. Mówiąc o
zespole mam na myśli developerów implementujących nowe funkcjonalności, testerów
badających konkretne zmiany w nowych rewizjach kodu czy osobę odpowiedzialną za
przekazanie wersji do klienta, ewentualnie wdrożenie na produkcję. Co warto
zaznaczyć, narzędzie niekoniecznie musi służyć wyłącznie do wersjonowania kodu.
Z praktyki wiem, iż można wersjonować inne rzeczy takie jak: skrypty testowe,
dokumentację, testy automatycznie, itd. W momencie, kiedy decydujemy się na
wersjonowanie dodatkowych rzeczy zależnych od wersji kodu, musimy pamiętać, aby
je w logiczny sposób skorelować z kodem. Zazwyczaj robi się to poprzez nadawanie
tagów. Nadajemy ten sam tag odpowiedniej wersji kodu oraz korespondującym z nią
plikom testów automatycznym, dokumentacji, itd.
Najpopularniejszymi narzędzi tego typu są:
- Subversion (SVN) – darmowy, prosty w instalacji system kontroli wersji, zbudowany na podstawie systemu CVS. Dodatkowo łatwo integruje się ze zintegrowanymi środowiskami programistycznymi, wspiera Continous Integration (o tym w dalszej części) oraz ma wiele innych zastosowań, które znajdziecie na stronie produktu.
- Git – darmowy, rozproszony system kontroli wersji. Początkowo zbudowany przez Linusa Torvaldsa do wsparcia rozwoju Linuxa. Aktualnie wspiera wiele systemów operacyjnych.
- Bazaar – darmowy, łatwy w obsłudze system kontroli wersji, zbudowany całkowicie od nowa z uwzględnieniem pewnych ograniczeń SVN.
Po drugie: Zintegrowane środowisko developerskie (ang. IDE)
Wybór środowiska developerskiego często narzuca nam technologia, w której chcemy
budować oprogramowanie. W projektach zwinnych jednym z wymagań, o których należy
pamiętać jest to, by środowisko developerskie integrowało się z narzędziem do
kontroli wersji. Ma to przeciwdziałać problemom wersjonowania oraz integracji
kodu tworzonego przez poszczególnych członków zespołu. W większości organizacji
wybór IDE jest z góry określany przez technologie. Dobrą praktyką jest utrzymywać
jeden rodzaj platformy w całym zespole (w projektach Java może to być np.
Eclipse). Wówczas mamy możliwość lepszej współpracy, dzielenia się wiedzą,
łatwiej też przyjdzie nam sprawdzenie technik programowania w parach czy
przeglądów kodu, jeśli się na nie zdecydujemy. Wiele z takich platform ma
rozbudowany system dodawania pluginów (dodatków), które rozszerzają środowisko
developerskie funkcjonalnie i technicznie. Równie istotne, co pisanie nowego
kodu jest przeglądanie i refactoring starego (do dyspozycji mamy statyczne
analizatory kodu, które bez kompilacji zwrócą listę potencjalnych zagrożeń i
błędów w kodzie).
Najpopularniejsze środowiska developerskie to:
- Eclipse i NetBeans używane w projektach wykorzystujących technologie i język programowania Java.
- Visual Studio używanie w projektach wykorzystujących technologie Microsoft
- IntelliJIDEA - komercyjne zintegrowane środowisko programistyczne dla Javy, Androida, Scala i wielu innych języków.
Po trzecie: Narzędzie do tworzenia buildów
W projektach zwinnych każdy z zespołów musi mieć możliwość częstego i
szybkiego weryfikowania jakości swojej pracy. Bardzo istotne jest to, aby zespół
wiedział, jak szybko przetworzyć dostarczony kod w wykonywalny plik czy gotową
do testów aplikację. W zespołach, w których pracowałem bądź aktualnie pracuję,
wykorzystuje się do tego narzędzia ANT lub Maven w celu zbudowania wykonywanej
wersji projektu. Te narzędzia łatwo współdziałają ze zintegrowanymi środowiskami
developerskimi oraz narzędziami do testów automatycznych. Idąc krok dalej
docieramy do narzędzi, które pozwalają zautomatyzować proces tworzenia buildów.
Continuous Integration (CI), bo o
nim mowa, jest jedną z kluczowych praktyk zespołów zwinnych. Z koncepcją CI
wiąże się potrzeba szybkiego feedbacku w reakcji na wprowadzoną zmianę. W kilku
słowach, polega to na zestawieniu automatycznego procesu budowania produktu, puszczeniu
na nim automatycznych testów potwierdzających jakość zastosowanych rozwiązań i zwróceniu
wyników w postaci raportu. W pełni zautomatyzowany proces jest kluczem do
sukcesu, dlatego dobierając narzędzia ważne jest, aby wszystkie wcześniej
opisane komponenty współpracowały z wybranym rozwiązaniem CI. Przykładem
darmowych narzędzi tego typu jest Hudson/Jenkins. Sprawnie działający proces CI
jest kluczowy dla powodzenia projektu, wobec czego rekomenduję go opracować i
ewentualnie zestawić przed rozpoczęciem developmentu.
Po czwarte i ostatnie: Testy jednostkowe
W przypadku tego typu praktyki istotne jest to, aby podjąć decyzję na
starcie i zacząć tworzyć testy jednostkowe od samego początku trwania
developmentu. Podejmując decyzję później, w trakcie realizacji kolejnych iteracji,
narażamy się na niepowodzenie i frustrację zespołu, który będzie musiał przejrzeć
i pokryć testami napisany już wcześniej kod. Testy jednostkowe wymagają pewnego
nakładu pracy, jednakże pamiętajmy, że z jednej strony dostarczają testowalny
kod a z drugiej budują podwaliny pod testy na kolejnych etapach tworzenia
oprogramowania. Nie bez znaczenia jest fakt, iż błędy znalezione na tym etapie nie
są powielane w późniejszych fazach projektu, przez co kosztują zespół i projekt
relatywnie najmniej. Narzędzia do pisania testów jednostkowych zależą od języka
programowania, w których tworzymy produkt. Najpopularniejsze to Junit dla Javy
i Nunit dla .Net. Również kod reprezentujący GUI powinien być testowany
wcześniej, na przykład przy pomocy TestNG lub SWTBot.
Podsumowując, narzędzia wybierajmy świadomie, dobrze wiedząc, czego od nich
oczekujemy. Wybór odpowiednich rozwiązań typu Continuous Integration, procesu
tworzenia buildów i automatyzacji testów ma wspierać zespół przez dostarczanie informacji
zwrotnej tak szybko, jak to możliwe. Zespoły, które nie podejmą przemyślanych
decyzji we właściwym momencie, mogą mieć trudności, co może prowadzić do frustracji,
złej atmosfery pracy bądź w skrajnych przypadkach przyczynić się do
niepowodzenia projektu.
Brak komentarzy:
Prześlij komentarz