W ciągu ostatnich dwóch tygodni pracowałem z kilkoma podstawowymi koncepcjami programowania ekstremalnego w małej grze zręcznościowej dla wielu graczy. Spędziłem tydzień opracowując historie użytkowników i określając wymagania, aby stworzyć plan wydania. Spędziłem również tydzień na kodowaniu i stosowaniu pierwszego planu iteracji, jaki wymyśliłem. Zidentyfikowałem kilka oczywiście przydatnych pojęć dla jednego programisty.
- Ciągła integracja
- Nigdy wcześniej nie dodawaj funkcjonalności
- Rozwój oparty na testach
- Wybierz metaforę systemu
- Użyj jednego punktu integracji
- Przetestuj wszystkie błędy
- Ciągle refaktoryzujący
- Ustaw zrównoważone tempo
- Prostota
- Częste wydania
Jestem ciekawy, czy brakuje mi czegoś konkretnego, co mogłoby być przydatne do pracy z jednym projektem deweloperskim?
Również w tym świetle, biorąc pod uwagę ideę prostoty i rozwoju opartego na testach, czy lepiej jest używać sprawdzonych, bogatych w funkcje, gotowych platform?
A może powinienem pracować od podstaw, jeśli jest to wykonalne, aby uniknąć problemów związanych z regułami, takimi jak ciągłe refaktoryzowanie i brak wcześniejszego dodawania funkcjonalności?
źródło
Odpowiedzi:
Ostatecznie programowanie ekstremalne dotyczy zestawu praktyk i metodologii, które prowadzą do poprawy wartości biznesowej. Najlepszą ilustracją tego, co znalazłem, jest http://c2.com/cgi/wiki?ExtremeProgrammingEnablingChart
Wszystko w kolorze niebieskim jest częścią rdzenia XP.
Istnieją części, które znajdują się na zewnątrz, które pomagają aktywować rzeczy w niebieskim obszarze i są częścią XP jako całości, ale nie są dla niego krytyczne. Zauważ, że osobiście nie jestem praktykiem XP i przeczytałem sporo krytyki ludzi „prawie” po XP, które według różnych osób nie są XP. Odłóżmy na bok ten aspekt dogmatu XP i spójrzmy na to, co mamy.
Uświadom sobie, że jedną z pierwszych i większości rzeczy jest zaangażowanie klienta w proces. Kluczowym elementem XP jest zaangażowanie klienta. Widać to w wielu miejscach, takich jak planowanie wydań, małe wydania, ocena klienta poza firmą. Są to rzeczy, które Twoi klienci będą musieli zasubskrybować, jeśli chcesz odnieść sukces w XP jako programista solo. Jeśli zamiast tego poprosą o projekt, a następnie okres programowania, a następnie testowanie i tak dalej, nie będziesz mieć od nich zobowiązania do pójścia dalej.
XP nie oznacza braku planowania. Jest w tym kilka aspektów, w których planowanie jest częścią - ustalanie priorytetów, szacowanie historii użytkowników, planowanie iteracji i definiowanie zadań. Nawet jeśli jesteś jednym programistą w tej dziedzinie, są to rzeczy, które będziesz musiał współpracować z klientem przy dostarczaniu.
Punkty, takie jak zbiorowa własność kodu i programowanie w parach, wymagają więcej niż jednego. Podejmowanie decyzji takich jak standardy kodowania jest znacznie łatwiejsze, ale nie oznacza to, że nie musisz ich przestrzegać. Nadal obowiązuje zbiorowe prawo własności - po prostu własność jest także kolejnym deweloperem - nie pisz kodu, który jest przeznaczony tylko dla Ciebie i dla Ciebie. Zauważ, że jest to w pewnym stopniu sprzeczne z „kodem ujawnia wszelką intencję”, który jest włączony przez programowanie parami - nie masz tej osoby, aby sprawdzić, czy piszesz kod, który można utrzymać, więc dokumentacja kodu jest również krytyczna.
Oprócz tych zastrzeżeń nadal obowiązuje wiele zasad projektowania XP. Takie rzeczy, jak testowanie pierwszego projektu, ciągła integracja, spotkania z klientem, refaktoryzacja, YAGNI, rozwiązania typu spike - połączenia te można wykonać samodzielnie.
Pamiętaj, że solo XP wymaga tyle samo dyscypliny, co zwykłe XP. XP jest często uważane za metodologię o wysokiej dyscyplinie , ponieważ wymaga od ludzi rygorystycznego przestrzegania najlepszych praktyk, które próbuje wcielić w życie. Kiedy nie masz trenera lub innych ludzi, którzy wsparliby tę dyscyplinę, może popaść w zbiór praktyk, które przypominają trochę XP.
Powiązana lektura:
Chciałbym wyciągnąć cytat z pierwszego z linków C2:
źródło