[ Pobierz całość w formacie PDF ]

tańsze niż wówczas, gdy program jest już u odbiorcy. Stopa zwrotu z tej
niewielkiej inwestycji jest naprawdę duża.
Przegląd kodu jest znakomitym narzędziem promującym dzielenie się wiedzą
w firmie. Współpraca przy przeglądzie kodu spowoduje, że osoba prze-
glądająca ma przynajmniej ogólną ideę działania Twojego programu, a być
może także jego głębsze rozumienie. Ma to ogromne znaczenie edukacyjne
i pomaga również w utrzymaniu poprawności kodu.
Przeglądy stanowią znakomitą okazję dla doświadczonych programistów do
przekazywania poprawnego stylu programowania i projektowania młodszym
kolegom. Poza trywialnymi zaleceniami (na przykład dotyczącymi sposobu
stawiania nawiasów) doświadczeni programiści mogą powiedzieć, dlaczego
jedna struktura danych może w danej sytuacji pasować bardziej niż inna,
Rozdział 3. " Pragmatyczne techniki projektowe 119
Wzorce
Wzorzec odnosi siÄ™ do praktyki dokumentowania i nazywania
wspólnych problemów (i ich rozwiązań), które występują w pro-
jektach. Istnieje kilka powodów, aby zdobyć wiedzę na temat
wzorców. Jednym jest wprowadzenie wśród programistów wspól-
nego słownictwa. Pracując ze sobą, programiści rozwijają wspólny
zbiór pojęć, który pozwala im się komunikować szybko i jedno-
znacznie. Wzorce mogą przyspieszyć ten proces i pozwolić komu-
nikować się jasno z kimś dopiero co spotkanym (pod warunkiem
że osoba ta zna te same wzorce).
Innym powodem, dla którego warto znać wzorce, jest łatwość
rozwiązywania problemów do tej pory niespotkanych. Poprzez czy-
tanie i omawianie różnych wzorców uczysz się sposobów rozwią-
zywania wielu popularnych problemów. Pytanie brzmi, czy uda Ci
się rozpoznać wzorce, kiedy się na nie natkniesz, a nie, czy uda Ci
się spotkać z większością z nich*. Czy będziesz wiedział, jak eleganc-
ko rozwiązać problem opisywany przez wzorzec, czy też będziesz
kilkakrotnie podchodził do rozwiązania, zanim znajdziesz właściwe?
Wzorce projektowe. Elementy oprogramowania obiektowego wie-
lokrotnego użytku autorstwa Erica Gammy, Richarda Helmsa,
Ralpha Johnsona i Johna Vlissidesa można polecić jako dobry punkt
wyjścia do studiowania tematu.
*
Artykuł  Humble Programmer (Pokorny programista) autorstwa Edsgera W. Dijkstry
przedstawia klasyczne spojrzenie na stan informatyki (i wzorców), które pozo-
staje w dalszym ciągu aktualne. Został on napisany w 1972 r. (patrz: http://
www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF).
lub wskazać istnienie jakiegoś wzorca. Często osoba przeglądająca zauwa-
ży powtarzające się fragmenty kodu lub fragmenty programu, które można
przenieść do wspólnych klas bazowych lub użytkowych. Dokonuje się re-
faktoringu kodu, zanim zostanie on zapisany w systemie zarzÄ…dzania kodem
z
ródłowym.
Przeglądy kodu ułatwiają także wspólne uczenie się, zarówno na małych
obszarach kodu, jak i na ogólnych koncepcjach. Poza  stylem programo-
wania uczysz się także  programować ze stylem .
120 Sprzedaj swój program
Oto kilka sugestii pomagających przeprowadzać przeglądy kodu.
Przegląd kodu musi angażować przynajmniej jednego dodatkowego pro-
gramistÄ™. W praktyce niemal zawsze wystarczy jeden dodatkowy progra-
mista, chyba że tworzysz coś na tyle interesującego, że inni pracownicy
chcą się o tym dowiedzieć. Wówczas możesz śmiało zaangażować więcej
programistów. Nie przesadzaj jednak (nie więcej niż trzech lub czterech)
 zbyt wielu programistów spowolni przegląd.
Nie udostępniaj kodu publicznie bez przeglądu. Nie dodawaj swoich zmian
do kodu z
ródłowego całego projektu, zanim nie zostanie dokonany prze-
gląd. Częścią komentarza dostarczanego z kodem powinno być nazwisko
osoby dokonującej przeglądu. Wówczas, jeśli pojawiają się pytania o przy-
czyny zmiany kodu, a Ciebie nie ma w pobliżu, jest inna osoba, która po-
winna być w stanie to wyjaśnić (przynajmniej na podstawowym poziomie).
Refaktoring
Najlepszą definicję tego pojęcia podaje Martin Fowler:
 Refaktoring jest sformalizowaną procedurą zmiany wewnętrznej
struktury istniejącego kodu bez zmiany jego zewnętrznego zacho-
wania. Jego istotÄ… jest szereg transformacji zachowujÄ…cych dotych-
czasowe działanie programu. Pojedyncza transformacja (refakto-
ring) nie zmienia wiele, ale szereg transformacji może przynieść
znaczące zmiany struktury. Dzięki temu, że pojedynczy refaktoring
jest niewielki, istnieje mniejsza szansa, że spowoduje błędy. Utrzy-
muje się również pełne działanie systemu po każdym refaktoringu,
co zmniejsza prawdopodobieństwo poważnej awarii podczas zmia-
ny struktury *.
*
Patrz: http://www.refactoring.com/.
Nigdy nie wykorzystuj przeglądu jako wymówki do niezatwierdzania kodu
w projekcie. Jeśli w Twojej firmie jest system zarządzania kodem z
ródło-
wym, który przechowuje tylko kod produkcyjny, wówczas umieść swój kod
w części prywatnej, dopóki nie będzie gotowy. Wymieniona prywatna część
może być oddzielnym repozytorium kodu lub oddzielną instalacją systemu
Rozdział 3. " Pragmatyczne techniki projektowe 121
zarzÄ…dzania kodem z
ródłowym. Korzystaj z wszelkich narzędzi, aby prze-
nieść kod ze swojego komputera, tak aby w przypadku jego awarii kod nie
został utracony. [ Pobierz całość w formacie PDF ]

zanotowane.pl

doc.pisz.pl

pdf.pisz.pl

kajaszek.htw.pl