True Solutions

Praktyki XP

Dzisiejszy wpis zakończy omawianie podstawowych praktyk stosowanych w extreme programming. Celowo na ten wpis rozstawiłem praktyki, które są silnie związane z kodem naszej aplikacji i często budzą mieszane uczucia wśród programistów.

Kompilacje dziesięciominutowe

Większość wiedzy na temat tej praktyki zawarta jest w jej nazwie – automatyczna kompilacja całego kodu połączona z uruchomieniem wszystkich testów nie powinna trwać dłużej niż 10 minut. Zdaniem Kent Beck’a dłuższe kompilacje ograniczają sprzężenie zwrotne, krótsze nie pozwalają bez stresu wypić kawy.

Jeżeli nie jesteśmy w stanie skompilować i przetestować całego systemu w podanym czasie, spróbujmy zrobić to dla fragmentu kodu – lepiej wykonać część testów niż nie wykonać ich wcale. Brak automatyzacji wraz z rozwojem aplikacji powoduje skomplikowanie procesu kompilacji i może zwiększać ryzyko błędu a także stres programistów. Czy nie prościej jest codziennie wciskać jeden guzik zamiast męczyć się z ręczną kompilacją od zera?

Ciągła integracja

Trudno sobie wyobrazić, by proces produkcji samolotu wyglądał następująco: dziesiątki producentów tworzy podzespoły, które później są na szybko łączone, a samolot po zespoleniu w jedną całość jest gotowy do startu.

Nie jestem ekspertem w dziedzinie lotnictwa, jednak kilka programów obejrzanych na Discovery Channel pozwoliło mi wyrobić sobie pogląd, jak skomplikowany jest taki proces. Dodatkowo, biorąc pod uwagę, że ryzyko uczestnictwa w wypadku lotniczym wynosi 1 na 11 milionów (dla samochodu 1 na 5000) a zazwyczaj głównym problemem jest czynnik ludzki, możemy być pewni, iż cały proces jest dobrze przemyślany.

Podobnie musimy myśleć o oprogramowaniu – aplikacje powinny być co najmniej tak samo niezawodne, jak samoloty. Nie osiągniemy takiej niezawodności, jeśli naszym pierwszym testem integracji będzie finalny deployment aplikacji na serwer docelowy w dzień oddania klientowi finalnego produktu. Należy integrować moduły co najmniej raz dziennie, chyba że są to mniejsze fragmenty, wtedy możemy wykonać integrację częściej.

Potwierdza się tutaj zasada płynąca z programowania opartego o model kaskadowy mówiąca, iż im później wykryjemy błąd, tym jest on bardziej kosztowny – doskonale odnosi się to do procesu integracji. Szybciej poprawimy bład na etapie programowania, niż dzień przed premierą, kiedy okaże się, że nasz “nie-integrujący-się” moduł jest silnie skorelowany z resztą systemu.

Rozpoczynanie programowania od testów

Jest to jedna z trudniejszych praktyk XP, wymagająca od programisty zmiany sposobu myślenia podczas projektowania. Kolejnośc działania w tym przypadku wygląda następująco:

• testowanie
• kodowanie
• refaktoring

Jeżeli pisanie testu przychodzi nam z trudnością, najprawdopodobniej oznacza to, że architektura została źle przemyślana. Łatwiej bowiem testować krótkie, precyzyjnie określone pod względem funkcjonalności funkcje niż długie, robiące kilka rzeczy naraz.

Zaletą pisania testów zanim zaczniemy pisać kod jest konieczność zawarcia w testach przypadków, które ocenią, czy nasz kod działa zgodnie z oczekiwaniem. Gdy pracy jest dużo, łatwo zapomnieć o fragmencie funkcjonalności – w tym przypadku uruchomienie wcześniej napisanego testu przypomni nam, które fragmenty nie zostały napisane, lub zostały napisane błędnie.

Patrząc na programowanie bardziej od strony ludzkiej, napisanie testów i poprawne ich wykonanie daje nam pewność i spokój ducha – kod który napisaliśmy działa zgodnie z oczekiwaniami. Spokój psychiczny pozwala programiście na lepsze skupienie się nad aktualnymi zadaniami, zamiast rozmyślać czy kod napisany tydzień temu przypadkowo nie “rozsypie się”.

Projektowanie przyrostowe

Trudno jest przed rozpoczęciem kodowania wyobrazić sobie większy projekt informatyczny w najdrobniejszych szczegółach. To, co wydaje się istotne dla nas (czy dla klienta, ba – nawet dla grup dobieranych dla potrzeb badań marketingowych), w zderzeniu z rzeczywistością może okazać się nie intuicyjne lub zupełnie nie potrzebne.

Wspomniany już wyżej model kaskadowy zakłada, iż doskonale zaprojektujemy system na kartce, następnie go napiszemy, przetestujemy i wdrożymy. Każdy, kto miał styczność z programowaniem wie, że jest to tylko pobożne życzenie. Klient zmienia zdanie, a do głowy przychodzą nowe pomysły, które mogą uatrakcyjnić produkt.

Rozsądniej jest zbudować prototyp i jak najwcześniej pokazać go grupie docelowej, która lepiej wie, w jakim kierunku aplikacja powinna się rozwijać. Oczywiście, taki sposób pisania wymaga rozsądnego projektowania architektury tak, aby wprowadzanie zmian nie pociągało za sobą drastycznych zmian w powiązanych modułach. Źle napisane oprogramowanie podlegające modyfikacją może okazać się niekończącym się horrorem, który nawet z najlepszego zespołu wyciągnie całą motywację i zaangażowanie.

Co dalej?

W kolejnej części opiszę praktyki uzupełniające extreme programming.

(c.d.n.)

Dodaj ten wpis do:

wykop del.icio.us