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…