narzędzia pracy grupowej, kontroli wersji, dokumentowania i
TRANSCRIPT
Projektowanie
oprogramowania
systemów NARZĘDZIA PRACY GRUPOWEJ, KONTROLI WERSJI, DOKUMENTOWANIA
I ŚLEDZENIA BŁĘDÓW
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
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ą
narzędzia programowania
ekstremalnego
specjalne krzesło albo grupowy, rozproszony edytor
typowe cechy
Cechy komunikatora
internetowego:
Roster (lista użytkowników)
Chat (grupowy i jeden-do-
jednego)
Współdzielona tablica
Edytor kodu
Podkreślanie/kolorowanie składni
Kolorowanie autorów
Wizualizacja obszaru edytowanego
przez innych
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
narzędzia
Microsoft Visual Studio – wtyczka VS Anywhere
Komercyjna (darmowa dla studentów)
Tylko tryb klient-serwer
narzędzia
Eclipse – wtyczka Saros
Darmowa
Opiera się na standardowym
protokole komunikatorowym -
XMPP
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
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 ;>
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
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
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
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)
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)
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
prosty scenariusz użycia
svn stat
sprawdź status kopii roboczej
svn update
włącz zdalne zmiany do kopii
roboczej
svn add test2.c
dodaj nowy plik do kopii roboczej
svn commit –m „[project] added file test2.c”
popełnij lokalne zmiany do
zdalnego repo
git stat
sprawdź status kopii roboczej
git pull
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
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
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)
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
systemy VSC – linki
https://en.wikipedia.org/wiki/Revision_control
https://subversion.apache.org/
http://svnbook.red-bean.com/
http://git-scm.com/
http://git-scm.com/book/en/v2
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
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
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
doxygen w akcji
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 (www.graphviz.org)
Manual doxygena:
http://www.stack.nl/~dimitri/doxygen/manual/index.html
systemy śledzenia błędó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ć
cykl życia buga
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ń email o zmianach statusu buga
Integracja z IDE – interfejsy zorientowane zadaniowo
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…