Projektowanie oprogramowania systemów NARZĘDZIA PRACY GRUPOWEJ, KONTROLI WERSJI, DOKUMENTOWANIA I ŚLEDZENIA BŁĘDÓW

Transkrypt

1 Projektowanie oprogramowania systemów NARZĘDZIA PRACY GRUPOWEJ, KONTROLI WERSJI, DOKUMENTOWANIA I ŚLEDZENIA BŁĘDÓW

2 plan wykładu Narzędzia pracy grupowej Edycja grupowa w czasie rzeczywistym Narzędzia Systemy kontroli wersji Podejście rozproszone kontra klient-serwer Wspólny słownik i koncepcje Narzędzia Narzędzia generowania dokumentacji Metajęzyki dokumentowania API Narzędzia Systemy śledzenia błędów Cykl życia bug-a Narzędzia

3 edycja grupowa w czasie rzeczywistym Jak to działa? Zespół (para?) programistów pracuje równocześnie nad tym samym fragmentem kodu Zmiany wprowadzone przez któregokolwiek z członków zespołu są natychmiast widzialne w każdej kopii w ten sam sposób co edycja w Google Docs Do czego to służy? Programowanie w (rozproszonych) parach na sposób XP - natychmiastowa komunikacja między członkami zespołu prowadzi do lepszego zrozumienia logiki kodu przez programistów (w tym piszącego), co skutkuje lepszą jakością kodu Przegląd kodu - jeden członek zespołu wykonuje przegląd kodu w tej samej chwili gdy inni piszą

4 narzędzia programowania ekstremalnego specjalne krzesło albo grupowy, rozproszony edytor

5 typowe cechy Cechy komunikatora internetowego: Roster (lista użytkowników) Chat (grupowy i jeden-dojednego) Współdzielona tablica Edytor kodu Podkreślanie/kolorowanie składni Kolorowanie autorów Wizualizacja obszaru edytowanego przez innych

6 narzędzia Historycznie pierwsze sensowne podejście SubEthaEdit na Macu (komercyjny) Gobby edytor grupowy OpenSource (Unix, Mac, Windows) Działa w trybach p2p i klient-serwer Protokół Obby używany również przez inne narzędzia, m.in.: GNU Emacs z wtyczką Rudel, kompatybilny z Gobby Wieloplatformowy

7 narzędzia Microsoft Visual Studio wtyczka VS Anywhere Komercyjna (darmowa dla studentów) Tylko tryb klient-serwer

8 narzędzia Eclipse wtyczka Saros Darmowa Opiera się na standardowym protokole komunikatorowym - XMPP

9 systemy kontroli wersji kodu (VCS: version control systems) Zarządzanie zmianami kodu na przestrzeni czasu Każda zmiana kodu jest przechowywana ( popełniana ) do repozytorium i jest powiązana z autorem, numerem wersji (rewizji) i datą Członkowie zespołu pobierają ( check out ) pliki projektu z repozytorium i pracują na kopii lokalnej ( kopii roboczej ) Po napisaniu porcji kodu zmiany są wysyłane do repozytorium Pozostali członkowie zespołu uaktualniają swoje kopie robocze, pobierając popełnione zmiany

10 do czego to służy? Pozwala cofnąć się do dowolnego punktu w historii projektu np. kiedy zmiany kodu powodują nowe błędy, można to łatwo wyśledzić Dodatkowa kopia bezpieczeństwa projektu Z każdą popełnioną zmianą można powiązać znaczący komentarz Umożliwia tworzenie równoległych gałęzi (branches) kodu, w których rozwijane są nowe cechy Umożliwia odnaleźć winnych błędów ;>

11 co należy przechowywać w repozytorium VCS Kod źródłowy (poza plikami generowanymi automatycznie) Pliki projektu (poza konfiguracją specyficzną dla maszyny/użytkownika) Zasoby projektu (grafiki, tablice napisów, tłumaczenia ) Skrypty służące do pielęgnacji i budowania projektu (np. skrypty tworzące bazę danych) Wszystko, co niezbędne do zbudowania projektu od zera, a nie jest automatycznie generowane lub dostępne z publicznej lokalizacji

12 czego nie należy przechowywać w repozytorium Plików źródłowych generowanych automatycznie podczas budowania projektu Plików intermediate i wyjściowych (np..obj,.o, binarnych, symboli debugowania, cache IDE ) Niczego, co jest tworzone automatycznie podczas budowania

13 architektury VCS Klient-serwer Tradycyjne podejście Repozytorium ulokowane na pojedynczym serwerze (master) VCS Każdy z członków zespołu używa klienta VCS żeby połączyć się z serwerem i pobrać/popełnić zmiany Implementacje: Subversion Visual SourceSave CVS Dużo dużo innych Rozproszona Nowoczesne podejście Jest wiele repozytoriów, każde zawiera pełną lub częściową kopię Repozytoria mogą być synchronizowane między sobą Kopie robocze członków zespołu są również rozproszonymi repozytoriami Implementacje: Git

14 graf rewizji Rewizje kodu w repozytorium tworzą graf Główna gałąź rozwijana przez cały czas życia projektu to trunk Możliwe dodatkowe gałęzie (branch), np. dla rozwijania eksperymentalnych funkcji Kiedy gałęzie rozwojowe osiągają dojrzałość, mogą być z powrotem włączone (merge) do gałęzi głównej (trunk) Kamienie milowe projektu mogą być oznaczone etykietami (tag), co umożliwia łatwe przełączanie się do wybranego kamienia milowego/wersji oprogramowania Kopia robocza użytkownika może być również postrzegana jako lokalna gałąź, która jest łączona z trunk w momencie kiedy użytkownik popełnia kod (tak to działa w Git)

15 podstawowe operacje w VCS checkout tworzy lokalną kopię roboczą repozytorium (svn checkout git checkout) commit wysyła zmiany z kopii roboczej do repo (svn commit git commit) merge łączy (synchronizuje) zmiany z dwóch gałęzi, być może powodując przy tym konflikt (svn merge git merge) update uaktualnia lokalną kopię roboczą o zmiany popełnione do repozytorium (svn update git pull) branch/tag tworzy gałąź kodu lub nadaje etykietę bazując na ostatniej rewizji pobranej z repozytorium (svn branch / tag git branch / tag) status status kopii roboczej (svn stat git stat) resolve oznacza konflikty jako rozwiązane (svn resolve git resolve) revert wycofuje zmiany wprowadzne w kopii roboczej (svn revert git revert)

16 prosty scenariusz użycia svn checkout <remote repository url> [local path] tworzy kopię roboczą z repo edycja kodu, dodawanie nowych plików svn commit m [project] added file test.c popełnia lokalne zmiany do zdalnego repo git clone <remote repository url> [local path] tworzy lokalną kopię repo, ustawia zdalne repo jako kopię źródłową edycja kodu, dodawanie nowych plików git commit m [project] added file test.c popełnia zmiany z kopii roboczej do lokalnego repo git push origin synchronizuje zmiany z lokalnego repo do zdalnego źródła

17 prosty scenariusz użycia svn stat svn update svn add test2.c sprawdź status kopii roboczej włącz zdalne zmiany do kopii roboczej dodaj nowy plik do kopii roboczej svn commit m [project] added file test2.c popełnij lokalne zmiany do zdalnego repo git stat git pull sprawdź status kopii roboczej włącz zdalne zmiany do do lokalnego repo i kopii roboczej git add test2.c dodaj nowy plik do kopii roboczej git commit m [project] added file test2.c git push origin

18 konflikty wersji Konflikt pojawia się kiedy więcej niż 1 użytkownik równocześnie edytuje to samo Konflikty świadczą o wadliwej komunikacji w zespole projektowym Rodzaje konfliktów Konflikt drzewa zmiana w strukturze plików/katalogów, zmiana nazwy Konflikt edycji wielokrotna edycja tego samego fragmentu plików Konflikt musi być rozwiązany przed możliwością popełnienia zmian do repo

19 narzędzia Narzędzia linii poleceń svn (Subversion); napisz svn --help git (Git); napisz git --help Narzędzia GUI TortoiseSVN (Windows) TortoiseGIT (Windows) GitHub (Windows/Mac) Git Shell Extensions (Windows)

20 narzędzia Integracja z IDE (Integrated Development Environment) AnkhSVN (Subversion for Visual Studio) Subclipse (Subversion for Eclipse) Git is integrated by default both in Visual Studio and Eclipse Dodatkowe narzędzia używane przez VCS diff narzędzie UNIX-owe do generowania plików różnic pomiędzy 2 plikami tekstowymi w formacie tzw. unified diff ; diff jest używany przez prawie wszystkie VCS do wymiany informacji o zmianach pomiędzy rewizjami patch UNIX-owe narzędzie do scalania plików diff z plikami źródłowymi

21 systemy VSC linki

22 narzędzia automatycznej generacji dokumentacji Pisanie kodu jest zbyt zabawne żeby dodatkowo się rozpraszać pisaniem dokumentacji ;) Narzędzia dokumentowania kodu służą do generowania dokumentacji automatycznie, bazując na kodzie wzbogaconym o dodatkowe tagi dokumentujące Tagi i tak trzeba niestety napisać (w formie komentarzy do kodu), ale przynajmniej nie trzeba przełączać się między edytorem dokumentacji a kodem, wszystko pozostaje w pamięci krótkotrwałej i nie powoduje to dekoncentracji W istocie pisanie dokumentacji API jest bardzo podobne do programowania parami i prowadzi do lepszej jakości kodu poprzez wczesne wyłapywanie usterek

23 metajęzyki dokumentacji kodu Niektóre języki mają wbudowany metajęzyk dokumentacji, opisany standardem i rozumiany przez kompilator i IDE Java JavaDoc C# - XML Docs Nie ma oficjalnego standardu dla C i C++ Ale jest de facto standard Doxygen Całe szczęście Doxygen rozumie również JavaDoc i XML Docs, więc jest to uniwersalne narzędzie do wszystkiego

24 cechy doxygen-a Generacja dokumentacji w formatach HTML, PDF, LaTeX, Windows Help, UNIX man i wiele, wiele innych Wsparcie dla wzorów matematycznych (LaTeX), bogatego formatowania i hyperlinkowania kodu Jeden język dokumentowania dla wszystkich sensownych języków programowania

25 doxygen w akcji

26 dodatkowe narzędzia GraphViz Graph Visualization Toolbox narzędzie wizualizacji grafów integrujące się z doxygen, pozwala m.in. automatycznie generować niektóre diagramy UML ( Manual doxygena:

27 systemy śledzenia błędzów Każde oprogramoania ma bugi Programiści starają się zapomnieć o wykrytych bugach jak tylko powrócą do pisania kodu (albo nawet szybciej) ;> Systemy śledzenia błędów (issue tracking systems) służą do zarządzania informacjami o błędach i nie pozwalają leniwym programistom o nich zapomnieć

28 cykl życia buga

29 cechy systemów śledzenia błędów Interfejs webowy dla zgłaszania bugów i zarządzania informacjami o nich Integracja z repozytoriami VCS Hyperlinkowanie raportów o błędach w komentarzach VCS (#3345) Hyperlinkowanie rewizji kodu (r109) w raportach o błędach Przeglądanie repozytorium VCS z poziomu systemu śledzenia błędów Wysyłanie powiadomień o zmianach statusu buga Integracja z IDE interfejsy zorientowane zadaniowo

30

31 narzędzia Bugzilla system śledzenia błędów oryginalnie stworzony dla przeglądarki Mozilla Trac system śledzenia błędów, zarządzania projektem i Wiki napisane w języku python (Open Source) JIRA system zarządzania wdrożeniami dużej skali i śledzenie błędów (komercyjny) Google Code Wiki projektu, repozytorium kodu i system śledzenia błędów dla projektów Open Source Mantis, Launchpad, GNATS i wiele wiele innych

32 Następny slajd jest prawdopodobnie najważniejszy w tej prezentacji

33 wymagania względem Waszego projektu Użycie systemu VCS do zarządzania repozytorium kodu zespołu projektowego Albo serwer dostarczony przez Katedrę, Albo Wasza własna instalacja Git lub SVN, Albo darmowy hosting projektu na GitHub, Google Code lub inny Wyznaczyć jednego z członków zespołu jako maintainer repozytorium odpowiedzialny za jego właściwą strukturę i zachowanie czystości Konsekwentne używanie sensownych komentarzy podczas popełniania zmian kodu Użycie tagów doxygena do dokumentowania Waszego kodu, plik konfiguracji doxygena (doxyfile) przechowywany w repozytorium VCS razem z projektem Użycie systemu śledzenia błędów do zarządzania raportami o bugach Albo serwer dostarczany przez Katedrę, Albo Wasza własna instalacja Trac-a lub Bugzilli (zintegrowana z repo VCS), Albo darmowy hosting projektu, jak wyżej. Integracja w/w narzędzi z wybranym przez Was lub Katedrę IDE