Extreme Programming to metodologia tworzenia oprogramowania mająca na celu poprawę jakości oprogramowania i jego zdolności do właściwego dostosowania się do zmieniających się potrzeb klienta lub klienta. W połowie i pod koniec lat dziewięćdziesiątych, podczas pracy nad Chrysler Comprehensive Compensation System (C3), aby pomóc w zarządzaniu płacami firmy, inżynier oprogramowania Ken Beck po raz pierwszy opracował metodologię programowania Extreme., W październiku 1999 opublikował Extreme Programming Explained, szczegółowo opisując całą metodę dla innych, a wkrótce potem uruchomiono także oficjalną stronę internetową.

podobnie jak inne zwinne metody programowania, Extreme Programming ma na celu zapewnienie iteracyjnych i częstych małych wydań w całym projekcie, umożliwiając członkom zespołu i klientom zbadanie i przegląd postępów projektu w całym SDLC.,

w tym artykule przyjrzymy się dokładnie, czym jest programowanie ekstremalne i jak ono działa, od wartości i zasad, które za nim stoją, po zasady i najlepsze praktyki proceduralne, które są używane do wdrożenia nowego projektu programowania ekstremalnego, więc zacznijmy!,/td>

Rational Unified Process Model Big Bang Model V model koncepcyjny Model Kaizen

Model Kanban Model spiralny

wartości ekstremalne

te pięć podstawowych wartości stanowią fundament, na którym zbudowana jest całość paradygmatu programowania ekstremalnego, pozwalając osobom zaangażowanym w projekt czuć się pewnie w kierunku, w którym zmierza projekt i zrozumieć ich osobiste opinie i wgląd jest tak potrzebny i mile widziany jak każdy inny.,

prostota: zrobimy to, co jest potrzebne i wymagane, ale nie więcej. To zmaksymalizuje wartość stworzoną dla inwestycji dokonanej do tej pory. Podejmiemy małe proste kroki do naszego celu i zminimalizujemy awarie w miarę ich występowania. Stworzymy coś, z czego jesteśmy dumni i utrzymamy to długoterminowo za rozsądne koszty.

Komunikacja: każdy jest częścią zespołu i codziennie komunikujemy się twarzą w twarz. Będziemy współpracować nad wszystkim, od wymagań po Kod. Stworzymy najlepsze rozwiązanie naszego problemu, jakie możemy razem.,

informacje zwrotne: traktujemy poważnie każde zobowiązanie iteracji, dostarczając działające oprogramowanie. Wcześnie demonstrujemy nasze oprogramowanie, a następnie często uważnie słuchamy i wprowadzamy wszelkie potrzebne zmiany. Porozmawiamy o projekcie i dostosujemy do niego nasz proces, a nie na odwrót.

szacunek: każdy daje i czuje szacunek, na jaki zasługuje jako ceniony członek zespołu. Każdy wnosi wartość, nawet jeśli jest to po prostu entuzjazm. Deweloperzy szanują wiedzę klientów i odwrotnie. Kierownictwo szanuje nasze prawo do przyjęcia odpowiedzialności i uzyskania autorytetu nad naszą własną pracą.,

Odwaga: powiemy prawdę o postępach i szacunkach. Nie dokumentujemy wymówek za porażkę, ponieważ planujemy odnieść sukces. Nie boimy się niczego, bo nikt nigdy nie pracuje sam. Dostosujemy się do zmian, kiedy tylko się pojawią.

Extreme Rules

pierwotnie opublikowany przez Dona Wellsa w 1999 roku, właściciela strony Extreme Programming, ten zestaw ekstremalnych zasad programowania pierwotnie miał pomóc w przeciwdziałaniu twierdzeniom, że Extreme Programming nie wspiera niektórych ważnych dyscyplin niezbędnych dla współczesnego rozwoju.,

planowanie

• historie użytkowników są pisane.
• planowanie Wydania tworzy harmonogram wydania.
• dokonują częstych małych wydań.
• projekt jest podzielony na iteracje.
• planowanie iteracji rozpoczyna każdą iterację.

Zarządzanie

• zapewnienie zespołowi dedykowanej otwartej przestrzeni roboczej.
• każdego dnia rozpoczyna się spotkanie stand up.
• prędkość projektu jest mierzona.
• poruszaj ludzi.
• napraw Ekstremalne Programowanie, gdy się zepsuje.

projektowanie

• prostota.,
• Wybierz metaforę systemu.
• używaj kart CRC do sesji projektowych.
• tworzenie rozwiązań spike w celu zmniejszenia ryzyka.
• Żadna funkcjonalność nie jest dodawana wcześniej.
• Refaktor zawsze i wszędzie tam, gdzie to możliwe.

kodowanie

• klient jest zawsze dostępny.
• kod musi być napisany zgodnie z uzgodnionymi standardami.
• najpierw Zakoduj test jednostkowy.
• cały kod produkcyjny jest zaprogramowany w parę.
• tylko jedna para integruje kod na raz.
• integruj się często.
• Skonfiguruj dedykowany komputer integracyjny.
• stosować własność zbiorową.,

testowanie

• cały kod musi mieć testy jednostkowe.
• cały kod musi przejść wszystkie testy jednostkowe, zanim będzie mógł zostać wydany.
• Po znalezieniu błędu tworzone są testy.
• testy akceptacyjne są często przeprowadzane, a wynik jest publikowany.

Extreme Practices

dwanaście najlepszych praktyk programowania ekstremalnego zostało stworzonych przy użyciu najlepszych praktyk programowania ekstremalnego.,

drobna informacja zwrotna

programowanie w parach

zasadniczo programowanie w parach oznacza, że dwie osoby pracują w tandemie na tym samym systemie podczas opracowywania dowolnego kodu produkcyjnego. Poprzez częstą rotację partnerów w całym zespole, Extreme Programming promuje lepszą komunikację i budowanie zespołu.

gra Planowa

często ma to formę spotkania w częstym i dobrze określonym przedziale czasu (co jeden lub dwa tygodnie), gdzie odbywa się większość planowania projektu.,

w ramach tej procedury istnieje etap planowania wydania, na którym dokonuje się ustaleń co do tego, co jest wymagane dla zbliżających się wydań. Sekcje planowania Wydania obejmują:

• Faza eksploracji: karty historii są używane do wyszczególniania najcenniejszych wymagań klientów.
• Faza zaangażowania: planowanie i zobowiązania zespołu są podejmowane w celu zaspokojenia potrzeb następnego wydania harmonogramu i dostarczenia go na czas.,
• Faza sterująca: pozwala to na dostosowanie wcześniej opracowanych planów do zmieniających się potrzeb projektu, podobnie jak wiele innych metod modelowania zwinnego.

Po planowaniu wydania jest również sekcja planowania iteracji, która składa się z tych samych trzech podpfaz, ale z wariantami na ich implementacjach:

• Faza eksploracji: wszystkie wymagania projektu są zapisywane.
• Faza zaangażowania: niezbędne zadania, które jeszcze nie zostały ukończone, aby sprostać nadchodzącemu wydaniu iteracji, są przypisane do deweloperów i odpowiednio zaplanowane.,
• Faza sterująca: rozwój ma miejsce, a po jego zakończeniu, wynikająca z niego iteracja jest porównywana z opisanymi kartami historii utworzonymi na początku procedury planowania.

Test-driven development

chociaż można napisać cały artykuł o test-driven development, koncepcja ta jest dość dobrze znana wśród programistów i skutecznie oznacza, że testy są generowane dla każdego wymogu projektu i dopiero wtedy powstaje kod, który pomyślnie przejdzie te testy.,

cały zespół

podobnie jak w przypadku wielu innych metod i praktyk SDLC, Extreme Programming promuje integrację klientów i klientów w całym procesie, wykorzystując ich opinie, aby pomóc kształtować projekt przez cały czas.

proces ciągły

Integracja ciągła

kolejną powszechną praktyką we współczesnym rozwoju, ideą ciągłej integracji jest to, że cały kod opracowany przez cały zespół jest scalany w jedno wspólne repozytorium wiele razy dziennie., Gwarantuje to, że wszelkie problemy z integracją w całym projekcie zostaną zauważone i rozwiązane tak szybko, jak to możliwe.

refaktoryzacja kodu

kolejną bardzo powszechną praktyką, ideą refaktoryzacji kodu jest po prostu poprawa i przeprojektowanie struktury już istniejącego kodu, bez modyfikowania jego fundamentalnego zachowania. Proste przykłady refaktoryzacji obejmują naprawianie niewłaściwych nazw zmiennych lub metod oraz redukcję powtarzającego się kodu do jednej metody lub funkcji.,

Small releases

koncepcja ta, zgodnie z praktykami modelu iteracyjnego, zapewnia, że projekt będzie często zawierał iteracyjne, małe wydania, umożliwiając klientowi, jak również wszystkim członkom zespołu, zrozumienie, w jaki sposób projekt się rozwija.

wspólne zrozumienie

standardy kodowania

standard kodowania jest po prostu zestawem najlepszych praktyk w samym kodzie, takich jak formatowanie i styl, które cały zespół przestrzega przez cały cykl życia projektu., Promuje to lepsze zrozumienie i czytelność kodu nie tylko dla obecnych członków, ale także dla przyszłych programistów.

wspólna własność kodu

ta praktyka pozwala każdemu programiście w zespole na zmianę dowolnej części kodu, w razie potrzeby. Chociaż praktyka ta może wydawać się niebezpieczna dla niektórych, przyspiesza czas rozwoju, a wszelkie potencjalne problemy można stłumić za pomocą odpowiednich testów jednostkowych.

Prosta konstrukcja

nie ma powodu, aby komplikować rzeczy, gdy dostępna jest prostsza opcja., Ta podstawowa praktyka utrzymywania wszystkich komponentów i kodu tak prostego, jak to tylko możliwe, zapewnia, że cały zespół zawsze ocenia, czy można zrobić coś łatwiejszego.

metafora systemowa

najlepsza myśl jako część standardów kodowania, metafora systemowa jest ideą, że każda osoba w zespole powinna być w stanie spojrzeć na kod wysokiego poziomu, który jest rozwijany, i mieć jasne zrozumienie, jakie funkcje pełni ten kod.,

dobrostan programisty

zrównoważone Tempo

kluczową koncepcją dla lepszej równowagi między pracą a życiem prywatnym z programistami w ekstremalnych projektach programistycznych jest przekonanie, że nikt nie powinien być zobowiązany do pracy poza normalnym zaplanowanym tygodniem pracy. Nadgodziny są mile widziane, podobnie jak koncepcja „crunch time”, gdzie deweloperzy mają pracować w ekstremalnych godzinach pod koniec Wydania, aby wszystko ukończyć na czas.