Programowanie ekstremalne dla jednego programisty [zamknięte]

10

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?

Kody Manharth
źródło
5
Elsesite, na c2.com (strona, która została wcześniej utworzona w celu omówienia zwinnych (a zwłaszcza XP) pojęć) - Extreme Programming For One
To niesamowity zasób, dziękuję. Szczególnie podoba mi się idea XP Pledge of Allegiance.
Kody Manharth
Jeśli czytasz uważnie, znajdziesz nazwy takie jak Ron Jeffries i Kent Beck komentowania ... i dobrze, że jest Warda Wiki .
Więc jest napisany przez twórców paradygmatu, to fantastycznie. Nie wiem, jak się jeszcze na to natknąłem. Korzystałem z www.extremeprogramming.org
Kody Manharth
2
W pytaniu nie ma ani jednej kropki, która jest obowiązkowa dla pomyślnego rozwoju oprogramowania. Prawdziwe pytanie brzmi: które naprawdę potrzebujesz?
Robert Harvey

Odpowiedzi:

5

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

Extreme Programming Enablement

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:

Damian Conway, znany ze świetności język Perl i szalony naukowiec, uważa, że ​​programowanie ekstremalne jest w rzeczywistości błędne. Ponieważ zawiera wiele dobrych praktyk programistycznych, których uczy się programistów, ale prawie na pewno je ignoruje, uważa, że ​​tak naprawdę powinno to być nazwane Programowaniem Ultra Konserwatywnym


źródło
Oświecające, delikatnie mówiąc. Obecnie mam do czynienia z problemami związanymi z TDD, we Flashu za pomocą Starling. Korzystam z FlexUnit i nie ma on możliwości przeprowadzania testów graficznych, ponieważ jest bezgłowy. Czy w takich przypadkach właściwe byłoby po prostu przekazanie tych testów do kontroli ręcznych (np. Czy test logo jest wyśrodkowany na ekranie). Czy byłoby to uważane za test integracyjny? (tj. czy moduł ekranu powitalnego działa poprawnie z modułem scenicznym Flasha?) Czy powinienem używać kpiny symulującej wymaganą sytuację? Czy testy mogą być konstrukcjami czysto eterycznymi?
Kody Manharth,