Implementacja

Odbiorca jest zawsze dostępny

Jednym z niewielu wymagań programowania ekstremalnego (XP) jest stała dostępność do klienta. Nie tylko, aby pomagać zespołowi wykonawców, ale by stać się jego częścią. Wszystkie fazy projektu opartego o metodologii XP wymagają komunikacji z odbiorcą, najlepiej twarzą w twarz, na miejscu. Najlepiej po prostu przypisać jednego lub kilku przyszłych użytkowników do zespołu. Zwróć uwagę, aby były to osoby znające się na rzeczy, a nie praktykanci, których wyznaczył nie chcąc marnować czasu bardziej wykwalifikowanych pracowników. Potrzebujesz ekspertów, a nie aktorów ich grających.

Użytkownicy spisują opowiadania z pomocą developerów, by określić szacunkowy czas na ich wprowadzenie i ustalić ich priorytet. Powinni upewnić się, że wszystkie życzenia, co do funkcjonalności są na nich uwzględnione.

Podczas spotkań związanych z planowaniem wersji klienci powinni uzgodnić, które z opowiadań mają być włączone do kolejnych wersji. Można także ustalić termin publikacji. Klienci podejmują te decyzje w oparciu o własne cele. Spotkanie te jest używane do określenia mniejszych, inkrementacyjnych publikacji, aby zapewnić jak najwcześniejsze dostarczenie pożądanej funkcjonalności do odbiorcy. Daje to użytkownikowi możliwość wcześniejszego wypróbowania systemu i szybszego odzewu do developerów.

Ponieważ szczegóły są pomijane w opowiadaniach, developerzy będą musieli kontaktować się z odbiorcami w celu zebrania odpowiedniej liczby informacji, potrzebnych do opracowania zadań programistycznych. Projekty na większą skalę wymagają stałego zaangażowania ze strony klienta.

Użytkownik będzie także potrzeby do pomocy przy testach funkcjonalności. Trzeba będzie stworzyć dane testowe a zamierzone wyniki oszacować i zweryfikować. Testy funkcjonalności sprawdzają czy system jest gotowy publikacji i wdrażania. Może zdarzyć się, że system nie przejdzie wszystkich testów wymaganej funkcjonalności, wtedy klient będzie musiał przejrzeć ich wyniki i zdecydować, czy zgodzi się na jego odbiór czy też wstrzymie wydanie.

Może wyglądać, że klient będzie musiał poświęcić sporo swojego czasu, lecz pamiętajmy, że oszczędzamy go już na początku, nie wymagając szczegółowych specyfikacji, co do wymagań i zachowując go na później, nie dostarczając nieprzydatnego systemu.

Mogą wystąpić drobne problemy, gdy wielu użytkowników będzie dostępnych różnym czasie. Eksperci z branży mają skłonności do posiadania sprzecznych poglądów. Jest to naturalne. Rozwiąż ten problem wymagając, żeby wszyscy klienci byli dostępni naraz podczas okazyjnych spotkań, aby móc wyłapać i pozbyć się różnic i nieścisłości wynikłych z ich opinii.

Standardy kodowania

Kod musi być formatowany zgodnie z przyjętymi standardami. Standardy kodowania utrzymuję zapis spójnym i łatwym do odczytania oraz przebudowy dla całego zespołu. Projekty Smalltalk mogą użyć "Smalltalk - Best Practice Patterns" jako standardu kodowania.

Najpierw arkusze testujące

Kiedy stworzysz testy najpierw, przed właściwym kodem, odkryjesz, że to, co miałeś wykonać zaimplementujesz znacznie szybciej i prościej. Oszczędzisz wiele czasu, łącząc implementację z testowaniem, które i tak musiałbyś przeprowadzić później.

Tworzenie testów znacznie pomaga developerom uzmysłowić sobie, co tak naprawdę trzeba wykonać. Wymagania są stanowczo określone przez testy. Nie można podważać ich specyfikacji, gdy jest jasno określona za pomocą kodu.

Widzisz także postępy swojej pracy. Bez testów programista często może nie być pewny, czy to, co wykonał jest wystarczające. Konsekwencją takich niedomówień mogą być zbędne dodatki i nowe błędy. Jeśli stworzymy najpierw arkusz testujący dokładnie wiemy, kiedy ukończyliśmy nasze zadanie - gdy wszystkie testy wykonają się poprawnie.

Zyskuje także projekt systemu. Często spotykamy się z oprogramowaniem, które bardzo trudno się testuje. Takie systemy przeważnie opierają się na wczesnej implementacji i późniejszym testowaniu, często przez inny zespół. Poprzez pierwsze tworzenie testów z góry wywierasz nacisk na sprawdzenia wszystkiego, czego oczekuje klient. Odbija się to na projekcie, który sam staje się łatwiejszym to testowania.

Można wyróżnić pewną rytmikę przy tworzeniu arkuszy testujących. Najpierw tworzysz jeden test by zdefiniować mały, ogólny aspekt problemu. Następnie piszesz najprostszy kod, który przejdzie ten test. Potem tworzysz drugi test. Teraz dodajesz do swojej kodu kolejne linijki, które sprawią, że ten test także zostanie zdany. Ale nic więcej! Nie, dopóki jeszcze nie będziesz miał kolejnego testu. Kontynuujesz tak dopóki nie zostanie nic do sprawdzenia. Przejrzyj przykład napisany w Javie, zilustrowany na projekcie ekspresu do kawy.

Kod, który będziesz tworzył będzie prosty i zwięzły, implementujący dokładnie tę funkcjonalność, którą potrzebujesz. Pozostali developerzy będą mogli łatwo dowiedzieć się jak ją wykorzystać po prostu przeglądając arkusze testów. Jeśli pewien aspekt użycia nie został przewidziany to będzie od razu rzucał się w oczy.

Programowanie w parach

Każdy kod dołączony do wydania jest tworzony przez dwie osoby pracujące razem na jednym komputerze. Programowanie w parach zwiększa jakoś oprogramowania nie wpływając na czas jego dostarczenia. Jest to mało oczywiste, ale dwie osoby pracujące na jednym komputerze dodadzą tyle samo funkcjonalności, co dwie osoby pracujące oddzielnie, tyle, że będzie ona znacznie bardziej dopracowana. Ze zwiększoną jakością przychodzą późniejsze zyski.

Najlepszą metodą programowania w parach jest po prostu posadzenie obok siebie dwóch developerów przed monitorem, którzy będą przekazywać sobie myszkę i klawiaturę. Gdy jedna osoba pisze i myśli nad metodą, którą właśnie tworzy, druga w tej chwili myśli strategicznie o tym, jak ta metoda sprawdzi się w tej klasie. Potrzeba odrobiny czasu by przyzwyczaić się do takiego rozwiązania, więc nie zrażaj się, jeśli przy pierwszym podejściu poczujesz się niezręcznie.

Sekwencyjna integracja

Bez kontrolowania integracji kodu źródłowego developerzy po lokalnym przetestowaniu swojego kodu będą kiedy tylko zechcą umieszczać wyniki swoich prac w publicznym repozytorium. Podczas równoległej integracji modułów kodu powstaje kombinacja, która nie została wcześniej przetestowana. Najprawdopodobniej zaistnieje wiele konfliktów, które ujawnią się później.

Pojawią się dalsze problemy, jeśli nie oczyściliśmy zależności ze starszej wersji. Odzwierciedlą się one na zestawie testów, który musi zweryfikować poprawki kodu. Jeśli nie możecie polegać na kompletnym, poprawnym i spójnym komplecie testów będą was prześladować komunikaty o być może już nieistniejących błędach oraz nowopowstałych, które nie zostały w nim przewidziane.

W niektórych projektach developerzy opiekują się wydzielonymi klasami. Właściciele tych klas dbają o to, by ich kod był spójny i właściwie udostępniony. Zmniejsza to ryzyko, ale powiązania między klasami nadal mogą być niewłaściwe. Metoda ta nie rozwiązuje problemu w całości.

Inną drogą, prowadzącą do tego samego celu, jest wyznaczenie osoby-integratora lub całej grupy, zajmującej się integracją. Jeden człowiek może nie poradzić sobie z integracją kodu dostarczanego przez wielu pracowitych programistów. Zespół ten może być zbyt duży, by przeprowadzać integrację częściej niż raz w tygodniu. W takim środowisku developerzy pracują na przestarzałych wersjach, które byłyby wtedy błędnie, reintegrowane z głównym kodem.

Te rozwiązania nie odwołują się do źródła problemu. Chcesz by developerzy mogli równolegle, odważnie wprowadzać zmiany do każdej potrzebnej cześci systemu, ale pragniesz także uniknięcia logicznych konsekwencji takiej swobodnej integracji. Gdy tuzin lokomotyw w tym samym czasie zmierzać do tej samej zwrotnicy też pojawi się problem. Zamiast narzucać stricte sekwencyjny sposób programowania lub wymagać złożonych procedur integracyjnych przemyślmy jeszcze raz ten problem. Nasze lokomotywy mogą wszystkie wejść na zwrotnicę bez katastrofy, jeśli po prostu będą to robić po kolei. Powinniśmy również w taki sposób przeprowadzać integrację kodu.

Ściśle sekwencyjna (lub jednowątkowa), samodzielna integracja kodu przez developerów połączona ze zbiorową własnością kodu będzie prostym rozwiązaniem naszego problemu. Cały kod źródłowy jest publikowany do repozytorium w turach. Tj. tylko jedna para developerów integruje, testuje i wprowadza zmiany w repozytorium kodu w danej chwili. Kolejkowana integracja pozwala na jednoznaczne zidentyfikowanie ostatniej wersji systemu.

Nie znaczy to, że nie możesz integrować swoich poprawek z ostatnią wersją na twoim własnej stacji roboczej, kiedy tylko zechcesz. Po prostu nie możesz publikować swoich zmian do repozytorium dla twojego zespołu, jeśli nie przyszła twoja kolej.

Wymagany byłby pewien rodzaj mechanizmu blokującego. Najprostszy byłby fizyczny klucz (token) przekazywany między developerami. Sprawdziłby się tutaj specjalnie przeznaczony do tego komputer, jeśli zespół pracuje w tym samym miejscu. Częsta integracja i publikacja kodu skraca czas potrzebny na trzymanie blokady, a zatem także czas oczekiwania na otrzymanie klucza.

Dedykowany komputer publikujący

Pojedynczy komputer służący do kolejnych publikacji pracuje naprawdę dobrze, pod warunkiem, że zespół developerów jest usytuowany blisko siebie. Ten komputer odgrywa rolę fizycznego dowodu kontroli publikacji. Developerzy mają możliwość zobaczenia ostatniego słowa w bieżącej konfiguracji. Mają oni źródło ostatecznego arbitrażu w sprawie problemów integracyjnych. Komputer umożliwia projektantom przekonanie się, kto i kiedy publikuje. Kiedy publikujący komputer jest w trakcie pracy, nie można wprowadzać dodatkowych zmian. Należy zapewnić stabilność.

Najnowszy połączony arkusz ciągu testów może zostać uruchomiony jeszcze przed publikacją. Test suite (ciąg testów) jest zawsze aktualny, ponieważ używany jest tylko jeden komputer. Jeśli arkusze testujące wypełniają w 100% zadania, zmiany mogą zostać opublikowane. Jeśli nie - zmiany są debugowane lub cofnięte i debugowane na jednostkach komputerach developerów.

Częsta integracja

Developerzy powinni integrować i publikować kod do repozytorium, co kilka godzin, kiedy to tylko możliwe. W żadnym razie, nigdy nie przetrzymywać zmienionej wersji dłużej niż dzień. Ciągła integracja często pozwala uniknąć rozbicia prac developerskich, kiedy to programiści nie porozumiewają się ze sobą na temat tego, co może zostać ponownie użyte albo, co powinno się dzielić. Wymaga się, aby każdy pracował na ostatniej, najnowszej wersji kodu. Wprowadzanie poprawek do i tak już nieaktualnego kodu źródłowego może tylko przyprawić o ból głowy w momencie integracji.

W miarę ciągła integracja pozwala na wczesne zapobieganie lub wykrywanie problemów z kompatybilnością. Chodzi o to, że jeśli znacznie łatwiej i bezpieczniej jest wprowadzać częściej drobne poprawki do głównego kodu niż za jednym zamachem, w chwili, gdy przychodzi czas oddania wyników, walczyć ze wprowadzeniem opracowywanych w ciągu kilku tygodni zmian do kodu, który sam już w tym czasie ewoluował. Dlatego zawsze pracuj opierając się na aktualnej wersji systemu.

Zbiorowa własność kodu

Zbiorowa własność kodu (ang. collective code ownership) motywuje wszystkich do zasilania projektu nowymi pomysłami. Każdy programista może zmienić dowolną linijkę kodu dodając nową funkcjonalność, poprawiając błędy lub przebudowując istniejące rozwiązanie.

Może to być trudne do zrozumienia na początku. Prawie nie do pomyślenia jest by cała drużyna odpowiadała za architekturę systemu. Brak jednego dowódcy, który utrzymywałby nowe idee w ryzach może wydawać się założeniem, które się nie sprawdzi w praktyce.

Nie jest niezwykłą sytuacja, gdy na pytanie skierowane do głównego projektanta otrzymamy odpowiedź, która będzie po prostu niewłaściwa. Nie świadczy to o niedouczeniach czołowego developera. Każdy nieco mniej trywialny system może okazać się zbyt złożonym, aby nad całą jego strukturą zapanowała jedna osoba. Z kolei inni wykonawcy mogą mieć trudności z rozwijaniem systemu nie mając przedstawionego zarysu wizji projektanta. Czy zdasz sobie sprawę z tego czy nie, architektura twojego systemu jest już rozdzielona w obrębie drużyny. Jeśli natomiast cała ekipa jest już w pewnym stopniu odpowiedzialna za decyzje jej dotyczące to czy nie może również stanowić autorytetu w tym zakresie?

Drogą do realizacji tego założenia jest tworzenie przez każdego z developerów arkuszy testujących kod, w miarę jego pisania. Każdy kod publikowany do repozytorium kodu źródłowego zawiera arkusze testujące. Kod, który został dodany, poprawione błędy i starszy kod będzie objęty przez automatyczne testowanie. Teraz możesz polegać na zestawie testów, strzegących waszego repozytorium kodu. Przed opublikowaniem jakiegokolwiek kodu musi on przejść cały zestaw testów w 100%.

Kiedy już zapewnimy miejsce do działania, każdy będzie mógł wprowadzić zmiany w dowolnej metodzie którejkolwiek z klas i opublikować je do repozytorium gdy zajdzie taka potrzeba. Gdy połączymy to z częstą integracją developerzy nawet rzadko będą zauważać, że klasa została rozszerzona czy poprawiona.

W praktyce zbiorowa własność kodu właściwie lepiej się sprawdza niż umieszczanie pojedynczej osoby, mającej strzec odpowiednich klas. Zwłaszcza, że taka osoba może w każdej chwili opuścić nasz projekt.

Optymalizacja na końcu

Nie optymalizuj czegoś, czego jeszcze nie skończyłeś. Nigdy nie próbuj zgadywać, co może być wąskim gardłem systemu. Zmierz to!

Zrób by działało, spraw by było dobre, a dopiero później walcz o to by było szybkie.

Bez nadgodzin

Praca po godzinach wysysa ducha i motywację zespołu. Projekty wymagające nadgodzin, aby zostały ukończone na czas i tak się spóźnią, niezależnie od tego, co zrobicie. Zamiast tego wykorzystajcie spotkania poświęcone planowaniu publikacji do zmian zakresu prac lub ich czasu. Zwiększanie zasobów poprzez przydzielanie większej ilości ludzi także jest nienajlepszym pomysłem, gdy projekt jest opóźniony.