XP: pair programming, TDD i CI w praktyce

XP, czyli Extreme Programming, brzmi ekstremalnie i właśnie takie jest.

XP to zestaw nawyków, które sprawiają, że praca zespołu technicznego staje się przewidywalna i bezpieczna.

Skąd się wzięło Extreme Programming?

Z projektu, który miał kłopoty. Kent Beck rozwijał XP pod koniec lat 90., między innymi w projekcie systemu płacowego C3 w Chryslerze, i opisał je w książce „Extreme Programming Explained” z 1999 roku. Nazwa oddaje pomysł: weź praktyki, o których wiadomo, że działają, i rób je w skrajnej wersji. Skoro przegląd kodu pomaga, rób go cały czas. Skoro testy pomagają, pisz je przed kodem. Skoro integracja pomaga, integruj kilka razy dziennie.

Beck był potem jednym z sygnatariuszy Manifestu Agile, a wiele praktyk XP stało się standardem w zespołach, które nigdy nie mówiły o sobie „robimy XP”.

Czy pair programming to strata czasu?

Rzadziej, niż się wydaje. Dwie osoby przy jednym ekranie to mniej błędów, szybsze przekazywanie wiedzy i kod, który rozumie ktoś poza autorem.

Alistair Cockburn i Laurie Williams opisali w 2000 roku eksperyment, w którym studenci informatyki pisali programy w parach albo samodzielnie. Pary potrzebowały łącznie około 15% więcej czasu pracy, a ich kod miał około 15% mniej defektów. Biorąc pod uwagę, ile kosztuje błąd wykryty na produkcji, ten rachunek często wychodzi na plus.

Jest też korzyść, której nie widać w liczbie błędów. Wiedza o systemie przestaje być zamknięta w głowie jednej osoby. Pisałem o tym, co się dzieje, gdy specjalizacja rozmywa odpowiedzialność.

Jak działa test-driven development?

Odwraca kolejność. Najpierw piszesz test, czyli definiujesz, co ma działać. Potem piszesz kod, który ten test spełnia. Na końcu poprawiasz strukturę kodu, wiedząc, że test pilnuje działania. Beck nazywa ten cykl: czerwony, zielony, refaktoryzacja.

Błędy łapiesz, zanim trafią do klienta. Test napisany przed kodem wymusza też jasność: trudno napisać test do czegoś, czego się nie rozumie. Jeśli test jest trudny do napisania, często to sygnał, że wymaganie jest niejasne.

Co daje continuous integration?

Zmiany wchodzą do systemu małymi porcjami, wiele razy dziennie. Znika tygodniowe „merge hell”, kiedy kilka osób próbuje naraz połączyć tygodnie pracy. Martin Fowler opisuje zasadę: każdy integruje swoją pracę z główną gałęzią przynajmniej raz dziennie, a każda integracja przechodzi automatyczne budowanie i testy.

Małe zmiany łatwo sprawdzić i łatwo cofnąć. Jeśli coś się psuje, wiadomo, która z ostatnich zmian to zrobiła. To ten sam mechanizm, który daje małe poprawki: drobne kroki składają się na dużą zmianę bez dużego ryzyka.

Co z tego dostajesz?

Mniej błędów na produkcji i wiedzę rozproszoną po całym zespole. Zespół mniej zależy od jednej osoby, która „wie, jak to działa”.

XP pokazuje, że dyscyplina techniczna jest sposobem na spokojniejsze dostarczanie. Bez niej kod z czasem psuje się sam, a każda zmiana jest coraz droższa.

Narzędzie jest narzędziem. Pytanie, co z niego wyciągniesz.

Bibliografia

Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley.
Beck, K. (2002). Test-Driven Development: By Example. Addison-Wesley.
Cockburn, A., Williams, L. (2000). The Costs and Benefits of Pair Programming. Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000).
Williams, L., Kessler, R. R., Cunningham, W., Jeffries, R. (2000). Strengthening the Case for Pair Programming. IEEE Software, 17(4), 19–25.
Fowler, M. (2006). Continuous Integration. martinfowler.com/articles/continuousIntegration.html.

💬 Dołącz do dyskusji na LinkedIn → Komentuj i podziel się swoim podejściem

Ten o Extreme Programming