LEKKIE METODOLOGIE WYTWARZANIA OPROGRAMOWANIA

Transkrypt

1 LEKKIE METODOLOGIE WYTWARZANIA OPROGRAMOWANIA Wykład 6 Programowanie Ekstremalne Jacek Dajda <dajda@agh.edu.pl> Kraków, 22 listopada 2007

2 Plan wykładu Wprowadzenie Założenia i podział praktyk Praktyki warstwy pracy w parach Strona: 2

3 Wprowadzenie

4 Skąd nazwa? Pierwsze skojarzenie: sporty ekstremalne - nowe, chwytne skojarzenie, dobry chwyt marketingowy XP to pewna rewolucja w myśleniu o procesie tworzenia oprogramowania (lata 90-te) - ekstremalna zmiana kierunku myślenia Oficjalna wykładnia: XP to przestrzeganie 12 podstawowych praktyk do ekstremalnych granic - wtedy pojawia się synergia Żródła: Strona: 4

5 Czym jest Programowanie Ekstremalne? extreme Programming (XP) to przede wszystkim nowy sposob myślenia Wynik zapotrzebowania na zmiany (jeden z elementów naturalnej ewolucji) Zbiór sprawdzonych doświadczeń Odpowiedź na wzrastające tempo i stopień złożoności współczesnych projektów A lightweight, efficient, low-risk, flexible, predictable, scientific and fun way to develop software Kent Beck, Extreme Programming Explained A humanistic discipline of software development Ron Jeffries Strona: 5

6 Charakterystyka XP Przyrostowy, nieformalny oprogramowania i lekki model tworzenia Metodyka... zorientowana na ludziach i ich wzajemnej wspołpracy przewidziana dla niewielkich zespołow (do 12 osób) oparta na synergii wynikajacej ze stosowania prostych praktyk i reguł najbardziej metodologii znana z rodziny lekkich (zwinnych) Strona: 6

7 Powstanie XP Projekt Comprehensive Compensation System (C3) w Daimler-Chrysler System rozliczeniowy dla pracowników, głowne cele to: 1. Przeniesienie dużego systemu mainframe na PC 2. Problem roku 2000 Realizacja oparta na Smalltalku Źródło: Strona: 7

8 Powstanie XP (2) Kent Beck, Ward Cunningham, Ron Jefferies ukończenie podstawowej (pilotażowej) wersji systemu, sformułowanie założeń metodyki wydanie Extreme Programming Explained projekt anulowany Źródła: wiki.mozcn.org, Strona: 8

9 Założenia i podział praktyk

10 Punkty widzenia 5 wartości Komunikacja Prostota Sprzężenie zwrotne 12 praktyk Gra planistyczna Programowanie w parach Programowanie sterowane testami Doskonalenie modelu (refaktoryzacja) Odwaga Prosty projekt Respekt Małe przyrosty Ciągła integracja Współwłasność kodu Standard kodowania Brak nadgodzin Klient w zespole Metafora Testy klienta 4 aktywności Kodowanie Testowanie Słuchanie Projektowanie Strona: 10

11 Wartości XP Komunikacja - krytyczna w pracy zespołu, pozwala na uniknięcie poważnych problemow, podstawa wielu praktyk XP Prostota KISS = Keep It Simple, Stupid albo Keep It Simple and Stupid BUZI = Bez Udziwnień Zapisuj, Idioto Sprzężenie zwrotne pochodzące od: Systemu Klienta Zespołu Odwaga - konieczność dokonywania radykalnych decyzji Respekt podstawa współpracy Strona: 11

12 Aktywności...czyli co robić by osiągnąć zamierzony cel Kodowanie - sposob komunikacji, przekazywania wiedzy, najważniejszy artefakt Testowanie - zwiększa żywotność kodu i zaufanie do jego jakości, uczy przewidywania, niebezpieczeństwo złych testow Słuchanie - uzyskiwanie wiedzy o wymaganiach i potrzebach systemu, wymiana informacji dot. problemow i aktualnego stanu prac Projektowanie - organizowanie prac nad systemem w logiczną całość, niebezpieczeństwo skomplikowanej i statycznej struktury Strona: 12

13 Obecny status Żródło: Strona: 13

14 Podstawowe praktyki XP Programowanie parami Współwłasność kodu Klient w zespole Programowanie sterowane testami Ciągła integracja Gra planistyczna Prosty projekt Standard kodowania Metafora Doskonalenie modelu Stałe tempo Małe przyrosty Testy klienta Strona: 14

15 Podział praktyk Klient w zespole Gra planistyczna Współwłasność kodu Warstwa organizacji projektu Programowanie parami Kod Testy Doskonalenie modelu Standard kodowania Małe przyrosty Prosty projekt Programowanie sterowane testami Stałe tempo Testy klienta Warstwa pracy w parach Ciągła integracja Warstwa pracy z klientem Metafora Strona: 15

16 Synergia i zależności pomiędzy praktykami Gra planistyczna Klient w zespole Małe przyrosty Metafora Testy klienta Prosty projekt Ciągła integracja Programowanie parami Standard kodowania Refaktoryzacja Współwłasność kodu Programowanie sterowane testami Brak nadgodzin Strona: 16

17 Koszty zmian Standardowe podejście Koszty zmian XP w praktyce XP w teorii Czas Wymagania Analiza i projekt Kodowanie Testowanie Produkcja Strona: 17

18 Cykl projektu XP Źródło: Strona: 18

19 Przebieg iteracji Źródło: Strona: 19

20 Praktyki warstwy pracy nad kodem

21 Klient w zespole Gra planistyczna Współwłasność kodu Warstwa organizacji projektu Programowanie parami Kod Testy Doskonalenie modelu Standard kodowania Małe przyrosty Warstwa pracy w parach Prosty projekt Programowanie sterowane testami Stałe tempo Testy klienta Ciągła integracja Warstwa pracy z klientem Metafora

22 Doskonalenie modelu (refaktoryzacja) i Programowanie Sterowane Testami (TDD) Testy jednostkowe przed kodem Testy muszą spełniać warunki: Doskonalenie modelu Programowanie sterowane testami być niezależne od innych testow, żeby nie powodować kaskad błędow, być zautomatyzowane, ponieważ będą wykonywane przy każdej integracji Wszystkie testy muszą przejść pomyślnie by moc iść naprzod Uruchamiane po każdej zmianie Stanowią o jakości Doskonalenie modelu... czyli refaktoring Ulepszanie struktury istniejącego kodu z zachowaniem zewnętrznego zachowania (pielęgnacja oprogramowania) Rozrastanie się kodu zmniejsza jego przejrzystość Strona: 22

23 Prosty projekt Bezpośrednio związane z programowaniem, tylko to co jest niezbędne Dobry projekt to prosty projekt, czyli taki, który: przechodzi pomyślnie wszystkie testy jednostkowe i funkcjonalne nie ma redundancji logicznych potrafi czytelnie przekazać odbiorcy zamysł (intencję) projektanta zawiera najmniejszą możliwą liczbę komponentow niezbędnych do realizacji danej funkcji Prosty nie znaczy banalny Czytelność, gotowość do zmiany niż jej przewidywanie Przyszłość jest niepewna Strona: 23

24 Złote myśli :-) KISS (BUZI) Keep It Simple Stupid (Keep It Simple and Stupid) Bez Udziwnień Zapisuj Idioto Dbanie o prosty, czytelny kod. Unikanie barokowych konstrukcji YAGNI You Aren t Gonna Need It Bez dodawania nowych, zbędnych funkcjonalności DTSTTCPW Do The Simplest Thing That Could Possibly Work Dochodzenie do celu powinno odbywać się nakrotszą, najłatwiejszą i najpewniejszą drogą OAOO Once And Only Once Wszystko co istotne powinno zostać zapisane. Ale tylko raz. DRY Don t Repeat Yourself - patrz OAOO Strona: 24

25 Pokusa nowych funkcjonalności Podczas pracy nad kodem często pojawia się pokusa dodania funkcjonalności, które nie są potrzebne w tej chwili, ale mogą się przydać w przyszłości. Należy wówczas pamiętać, że: każda nowa funkcjonalność zabiera czas, być może kosztem istotnych funkcjonalności każda nowa funkcjonalność musi być przetestowana, zintegrowana, sprawdzona przed użytkownika i zdokumentowana (chociażby w dokumentacji użytkownika) każda nowa funkcjonalność to możliwe ograniczenia, które mogą zablokować rozwój ważnych funkcjonalności w przyszłości każda nowa niepotrzebna funkcjonalność to ryzyko niepełnych (zgadywanych?) wymagań, co utrudnia testowanie. Nawet jeśli w przyszłości okaże się potrzebna, może wymagać poprawy każda nowa funkcjonalność to zaburzenie i niepotrzebny wzrost rozmiarów i stopnia skomplikowania kodu, który nie oferuje nic nowego z punktu widzenia klienta Strona: 25

26 Pokusa nowych funkcjonalności (2) każda nowa konieczność poinformowania programistów funkcjonalność to dodatkowego o niej innych każda nowa funkcjonalność to szersza perspektywa nowych funkcjonalności. Efekt kuli śniegowej Źródło: Strona: 26

27 Obawy Proste rozwiązania nie nadają się do wszystkiego Prostota ogranicza skalowalność Lepiej dobrze przygotować środowisko i potem zaoszczędzić czas na jego rozwijanie Jeżeli nowa funkcjonalność to niewiele pracy to czemu jej nie dodać - zawsze coś więcej do pokazania klientowi W niektorych aspektach programista ma większe doświadczenie czego może potrzebować klient - nowe funkcjonalności na pewno będą potrzebne Łatwiej dodać nową funkcjonalność ma się dobrą znajomość danego fragmentu systemu. Poźniejsze rozszerzanie wiąże się z koniecznością odświeżenia pamięci Strona: 27

28 Programowanie w parach Dwoch programistow przy jednym komputerze, role Pilota i Nawigatora Częsta i swobodna zmiana par w obrębie zespołu Jedna z najbardziej charakterystycznych i najbardziej kontrowersyjnych praktyk XP Czasami trudna, wymaga szczegolnego podejścia do pracy Nie każdy nadaje się do pracy w parach Źródła: Strona: 28

29 7 synergicznych zachowań programistów w parach Pytanie o skuteczność programowania w parach Wszędzie gdzie mamy do czynienia z czynnikiem ludzkim istotną rolę odgrywają psychologiczne aspekty (np. Sport) Laurie Williams, Robert Kessler: Pair Programming Illuminated Na podstawie ekspetymentow i własnych doświadczeń wyrożnili 7 synergicznych zachowań: Presja Negocjacje Odwaga Inspekcje Debugowanie Nauka Zaufanie Źródła: Strona: 29

30 Presja Osoby pracujące razem wspolnie odczuwają wszystko co im przeszkadza w pracy (kawa, mejle, gadu-gadu etc.) stąd presja, która pomaga w samodyscyplinie i sposobie organizacji pracy e-czynnik = nieprzerwany czas pracy / pełny czas pracy W efekcie starają się zminializować potrzebę przerw i maksymalnie wykorzystać dostępny im czas Źródła: Zasada Agile: znajdować sposób, a nie zmuszać Strona: 30

31 Negocjacje Żeby napisać kod w parze dwie osoby muszą ustalić wspolną drogę implementacji - to wymaga nieustających negocjacji Poprzez negocjacje są w stanie przejrzeć większy zakres rozwiązań niż pojedyczy programista i wybrać najlepszy - dzięki temu łatwiej uniknąć tzw. ślepych uliczek Co dwie głowy to nie jedna - pary są w stanie rozwiązywać trudniejsze zadania Pracują stabilniej Źródła: Strona: 31

32 Odwaga Często barierą w podjęciu inicjatywy jest obawa przed obnażeniem swojej słabości lub koniecznością konfrontacji z innymi Zawsze pojawia się moment kiedy posiadana wiedza nie wystarcza Pojedynczy programista obawia się obnażenia braku swojej wiedzy, jeśli dwoch programistow czegoś nie wie być może nie jest to takie proste Podobnie z wyrażaniem sprzeciwu, rozwiązywaniem błędów i problemow łatwiej wyrazić sprzeciw parze niż pojedynczemu programiście Świadomość wsparcia i współodpowiedzialności partnera daje komfort i poczucie bezpieczeństwa w kupie zawsze raźniej ;-) Źródła: Strona: 32

33 Inspekcje Inspekcje kodu pomagają w utrzymaniu jego jakości Podczas programowania w parach ten proces zachodzi cały czas Źródła: Strona: 33

34 Debugowanie Często wypowiedzenie problemu na głos prowadzi do jego rozwiązania Konieczność wyjaśnienia czegoś drugiej osobie pozwala w orządkowaniu własnego sposobu myślenia Podczas programowania w parach te sytuacje są naturalnym elementem Źródła: Strona: 34

35 Nauka Każdy ma unikalny zasob wiedzy i doświadczeń programowanie w parach jest okazją do naturalnej wymiany, nawet doświadczony programista może poznać inny punkt widzenia Dzięki częstym zmianom par wiedza i doświadczenie dyfunduje w obrębie całego zespołu i niweluje rożnice Źródła: Strona: 35

36 Zaufanie Odwaga, nauka, satysfakcja z pracy oraz jakość osiąganych wynikow zwiększają wiarę w możliwości zespołu i własne Pozytywne podejście do pracy daje lepsze wyniki Źródła: Strona: 36

37 A może 3 programistów? W parze jeden programistów? komunikacji, a w przypadku 3 Gdzie kucharek sześć... kanał Kwestia organizacji miejsca pracy Większa trudność w sposobie organizacji projektu i ustaleniu harmonogramu prac Opór materii Większe sesje programistyczne stosowane w razie specjalnych okoliczności: np. praca z ekspertem, klientem, debugowanie, burza mozgów etc. Strona: 37

38 Efektywność programistów w parach Jedno z głównych wątpliwości i kontrowersji Zakłada się, że programiści w parach pracują szybciej niż pojedynczy programista (reguła 20/20) Aby to zweryfikować przeprowadzono kilka eksperymentow Eksperyment Johna Noska - podział uczestnikow na pracujących w parach i indywidualnie. Proste zadanie. Uzyskany średni wynik: indywidualnie: 42 minuty w parach: 30 minut 1999, Laurie A. Williams, North Carolina State University, The Costs and Benefits of Pair Programming, eksperyment wśrod studentow, 3 zadania. Porownanie programistow w parach i indywidualnych pod kątem: kosztów implementacji jakości kodu Strona: 38

39 W illiam s podaje: IBM raportuje w ydanie 250 milionów $ na napraw ę 30 tys. błędów w jednym ze sw oich system ów

40

41 Problemy i dobre praktyki związane z Programowaniem w Parach Problemy związane w programowaniem w parach Zależność od partnera, konieczność częstej zmiany Proponowane rozwiązania Akceptacja własnej ułomności Zaufanie do własnych umiejętności Ustalanie harmonogramu Ciągła komunikacja Problem jednego eksperta Słuchanie Kolokacja Zespołowość Organizacja stanowiska pracy Różnice umiejętności i wiedzy Równowaga kompromisu i asertywności Przerwy w pracy Psychologiczne problemy bliskiej współpracy np. The Prima Donna Programmer, The Hero, The Human Compiler etc. Strona: 41