Pragmatyczny programista Od czeladnika do mistrza pragpr

• Poznaj najlepsze praktyki i najczęstsze pułapki procesu wytwarzania oprogramowania
• Naucz się pisać elastyczny, dynamiczny i łatwy w dostosowywaniu kod
• Opanuj sprawdzone techniki efektywnego testowania oprogramowania

Twórcy rozmaitych narzędzi programistycznych nieustannie próbują nas przekonać o niewiary-
godnych możliwościach swoich produktów, a specjaliści od metodyk obiecują, że to właśnie ich
techniki zagwarantują nam największą wydajność. Każdy oczywiście twierdzi, że jego język
programowania jest najlepszy… A jak wszyscy doskonale wiemy, w naszej pracy nie istnieją
NAJLEPSZE rozwiązania – są tylko rozwiązania NAJLEPIEJ sprawdzające się w danym projekcie.
Większy wpływ na efektywność naszej pracy ma więc doświadczenie oraz znajomość różnych,
sprawdzonych praktyk wytwarzania oprogramowania. Zawodowcy, którym na sercu leży przede
wszystkim jakość realizowanych projektów, są zwykle zgodni – nigdy nie wiążą swojej zawodowej
kariery z jedną, konkretną technologią. To jedna z cech wyróżniających pragmatycznych programistów
– produktywnych speców, którzy w pełni wykorzystują swój potencjał i szybko osiągają
zawodowy sukces. A oto pierwsza książka, która w pełni odsłania system ich codziennej pracy!

Nie ma znaczenia, czy jesteś wolnym strzelcem, członkiem wielkiego zespołu projektowego, czy
konsultantem równocześnie współpracującym z wieloma klientami. Ta skoncentrowana na
przekazywaniu praktycznej wiedzy publikacja pokaże Ci, jak efektywnie wykorzystywać swoje
umiejętności i doświadczenie do sprawnej realizacji nawet najbardziej złożonych projektów.
Podręcznik ilustruje najlepsze praktyki i najczęstsze pułapki wielu różnych aspektów wytwarzania
oprogramowania. Znajdziesz w nim zarówno zagadnienia związane ze strategicznym
planowaniem swojego zawodowego rozwoju, jak i techniki takiego projektowania architektury,
aby przyszły kod był elastyczny, łatwy w dostosowywaniu do różnych okoliczności i przygotowany
do wielokrotnego użytku.

Z książki dowiesz się między innymi, jak:

• unikać pułapki powielania wiedzy
• pisać elastyczny, dynamiczny i łatwy w dostosowywaniu kod
• unikać programowania przez koincydencję
• zabezpieczać kod za pomocą kontraktów, asercji i wyjątków
• gromadzić rzeczywiste wymagania
• bezlitośnie i efektywnie testować oprogramowanie
• zachwycać swoich użytkowników
• budować zespoły pragmatycznych programistów
• automatyzować pracę w celu zapewnienia większej precyzji

Spis treci

OWO WSTPNE

RZEDMOWA

1 F

ILOZOFIA PRAGMATYCZNA

Kot zjad mój kod ródowy ............................................................ 22

Entropia oprogramowania ............................................................. 24

Zupa z kamieni i gotowane aby .................................................... 27

Odpowiednio dobre oprogramowanie ............................................. 29

Portfolio wiedzy ............................................................................. 32

Komunikuj si! .............................................................................. 38

2 P

OSTAWA PRAGMATYCZNA

Przeklestwo powielania ................................................................ 46

Ortogonalno ............................................................................... 53

Odwracalno ............................................................................... 63

10.

Pociski smugowe ........................................................................... 67

11.

Prototypy i karteczki samoprzylepne .............................................. 72

12.

Jzyki dziedzinowe ........................................................................ 76

13.

Szacowanie ................................................................................... 83

3 P

ODSTAWOWE NARZDZIA

14.

Potga zwykego tekstu .................................................................. 91

15.

Powoki ......................................................................................... 95

16.

Efektywna edycja ........................................................................ 100

17.

Kontrola kodu ródowego ........................................................... 104

18.

Diagnozowanie ............................................................................ 107

19.

Operowanie na tekcie ................................................................ 116

20.

Generatory kodu ......................................................................... 120

4 P

RAGMATYCZNA PARANOJA

125

21.

Projektowanie kontraktowe .......................................................... 126

22.

Martwe programy nie kami ....................................................... 138

23.

Programowanie asertywne ........................................................... 140

24.

Kiedy uywa wyjtków ............................................................... 143

25.

Jak zrównoway zasoby ............................................................. 147

X Spis treci

5 Z

EGNIJ LUB ZAM

155

26.

Izolacja i prawo Demeter ............................................................. 156

27.

Metaprogramowanie .................................................................... 162

28.

Zwizki czasowe .......................................................................... 167

29.

To tylko widok ............................................................................. 174

30.

Tablice ........................................................................................ 181

6 K

IEDY KODUJEMY

… 187

31.

Programowanie przez koincydencj .............................................. 188

32.

Szybko algorytmu .................................................................... 193

33.

Refaktoryzacja ............................................................................. 200

34.

Kod atwy do testowania .............................................................. 205

35.

Ze kreatory ................................................................................. 213

7 P

RZED PROJEKTEM

217

36.

Kopalnia wymaga ...................................................................... 218

37.

Rozwizywanie niemoliwych do rozwizania amigówek ............. 227

38.

Nie, dopóki nie jeste gotowy ....................................................... 230

39.

Puapka specyfikacji .................................................................... 232

40.

Okrgi i strzaki ........................................................................... 235

8 P

RAGMATYCZNE PROJEKTY

239

41.

Pragmatyczne zespoy .................................................................. 240

42.

Wszechobecna automatyzacja ...................................................... 246

43.

Bezlitosne testy ........................................................................... 252

44.

Pisanie przede wszystkim ............................................................ 262

45.

Wielkie oczekiwania ..................................................................... 269

46.

Duma i uprzedzenie .....................................................................272

A Z

ASOBY

275

Profesjonalne spoecznoci ................................................................ 276
Budowa biblioteki ............................................................................. 276
Zasoby internetowe ........................................................................... 279
Bibliografia ....................................................................................... 288

B O

DPOWIEDZI DO WICZE

293

KOROWIDZ

317

Rozdzia 7.

Przed projektem

Czy kiedykolwiek czue, e projekt jest nie do zrealizowania, zanim jeszcze
rozpocza si jego realizacja? Taka sytuacja moe mie miejsce, jeli prac nad
projektem nie poprzedzimy ustaleniem pewnych regu. W przeciwnym razie
równie dobrze mona od razu odmówi realizacji projektu i oszczdzi pienidze
jego sponsora.

Na samym pocztku projektu musimy okreli wymagania. Samo wsuchiwanie
si w gos uytkowników nie wystarczy — wicej informacji na ten temat mona
znale w podrozdziale „Kopalnia wymaga”.

Konwencjonaln wiedz i sposobami zarzdzania ograniczeniami zajmiemy si
w podrozdziale „Rozwizywanie niemoliwych do rozwizania amigówek”.
W zalenoci od tego, czy pracujemy nad wymaganiami, analiz, kodowaniem,
czy testami, moemy spodziewa si rónych problemów. W wikszoci przypad-
ków wspomniane problemy nie s takie trudne, na jakie pocztkowo wygldaj.

Nawet po rozwizaniu tych problemów wci moemy nie mie pewnoci, czy
projekt rzeczywicie ma szanse powodzenia. Czy jest to tylko jaki niepokojcy
nawyk, odruch, czy co wicej? W podrozdziale „Nie, dopóki nie jeste gotowy”
mona znale sytuacje, kiedy naley zachowa zdrowy rozsdek i powanie
traktowa te ostrzegajce gosy w naszych gowach.

Zbyt szybkie rozpoczcie projektu to jeden problem, ale zbyt dugie oczekiwanie
bywa jeszcze bardziej niebezpieczne. W podrozdziale „Puapka specyfikacji”
omówimy zalety specyfikacji na konkretnym przykadzie.

I wreszcie, w podrozdziale „Okrgi i strzaki” przeanalizujemy kilka typowych
puapek czyhajcych na programistów w ramach formalnych procesów i meto-
dyk wytwarzania. adna metoda nie zastpi mylenia, choby by najlepiej
zaplanowana i obejmowaa wszystkie znane „najlepsze praktyki”.

218

X Rozdzia 7. Przed projektem

Jeli uda si wyeliminowa te krytyczne problemy przed przystpieniem do wa-
ciwego projektu, bdziemy mogli duo skuteczniej unika paraliu analitycz-
nego i sprawnie rozpocz prace nad projektem.

Kopalnia wymaga

Doskonao osiga si nie wtedy, kiedy nie mona ju nic doda,
lecz gdy ju niczego nie mona uj…

Antoine de St. Exupéry, Ziemia, planeta ludzi, 1939

W wielu ksikach i podrcznikach zbieranie wymaga jest prezentowane jako
wczesna faza projektu. Samo sowo „zbieranie” sugeruje istnienie jakiej grupy
beztroskich analityków, którzy ywi si lecymi wokó orzeszkami wiedzy przy
pobrzmiewajcych cicho d wikach symfonii Pastoralnej. „Zbieranie” wskazuje
na to, e wymagania ju istniej, a nasza rola sprowadza si tylko do ich odna-
lezienia, umieszczenia w koszyku i radosnego podania naprzód.

Rzeczywisto jest nieco inna. Wymagania rzadko s dostpne od rki. Zwykle
s raczej dobrze ukryte pod warstwami zaoe, nieporozumie i decyzji poli-
tycznych.

SKAZÓWKA NR

Nie należy zbierać wymagań — należy je wydobywać z ukrycia.

Poszukiwanie wymaga

Jak rozpozna prawdziwe wymagania podczas przekopywania si przez ota-
czajcy je mu? Odpowied jest jednoczenie prosta i skomplikowana.

Prosta odpowied mówi, e wymaganie to stwierdzenie dotyczce celu, który musi
by osignity. Dobre wymagania mog obejmowa nastpujce elementy:

Rekord pracownika moe by przegldany tylko przez wyznaczon grup
osób.

Temperatura gowicy cylindra nie moe przekracza wartoci krytycznej,
której poziom zaley od rodzaju silnika.

Edytor bdzie wyrónia sowa kluczowe zalenie od typu edytowanego
pliku.

Okazuje si jednak, e bardzo niewiele wymaga jest formuowanych w tak ja-
snych sowach, co znacznie komplikuje proces analizy wymaga.

Kopalnia wymaga

W 219

Pierwsze zdanie z powyszej listy równie dobrze uytkownicy mogliby wyrazi
sowami: „Tylko przeoeni pracowników i pracownicy dziau personalnego mog
przeglda rekordy pracowników”. Czy takie stwierdzenie rzeczywicie jest wy-
maganiem? By moe dzisiaj takie odczytanie tego zdania jest moliwe, ale za-
warto w nim zdecydowanie zbyt duo elementów zalenych od polityki. Decyzje
polityczne stale podlegaj zmianom i jako takie nie powinny by trwale wpisy-
wane w nasze wymagania. Zachcamy do dokumentowania tych decyzji po-
litycznych poza wymaganiami i do ewentualnego wizania obu dokumentów za
pomoc hiperczy. Wymaganie powinno by ogólnym stwierdzeniem i przeka-
zywa programistom informacje polityczne w formie przykadu scenariusza, który
musi by realizowany przez przysz implementacj. Decyzje polityczne mona
te wyraa w formie metadanych sterujcych zachowaniem gotowej aplikacji.

To z pozoru nieistotne rozrónienie ma zasadniczy wpyw na sytuacj programi-
stów zaangaowanych w projekt. Jeli wymaganie jest wyraone w ten sposób:
„Tylko personel moe przeglda rekord pracownika”, programista moe by
zmuszony do kadorazowego kodowania stosownego testu, kiedy aplikacja uzy-
skuje dostp do odpowiednich plików. Jeli jednak to samo wyraenie zostanie
wyraone sowami: „Tylko uprawnieni uytkownicy maj dostp do rekordu pra-
cownika”, programista najprawdopodobniej zaprojektuje i zaimplementuje jaki
system kontroli dostpu. W razie zmiany polityki (co na pewno kiedy nastpi)
aktualizacji bd wymagay tylko metadane uywane przez ten system. W prak-
tyce gromadzenie wymaga w ten sposób naturalnie prowadzi do zaprojektowa-
nia systemu dziaajcego w oparciu o metadane.

Podzia na wymagania, polityk i implementacj bywa bardzo nieczytelny w przy-
padku rozwaa powiconych interfejsom uytkownika. „System musi umo-
liwia uytkownikowi wybór poyczki terminowej” — tak moe brzmie jasne
wymaganie. „Potrzebujemy listy wyboru z moliwoci wskazania poyczki
terminowej” — to moe, ale nie musi by wymaganie. Jeli uytkownicy ko-
niecznie musz dysponowa list wyboru, mamy do czynienia z wymaganiem.
Jeli jednak chodzi tylko o moliwo wyboru, a kontrolka listy wyboru jest tylko
przykadem, sytuacja nie jest ju taka oczywista. W ramce w dalszej czci tego
podrozdziau zostanie omówiony projekt, który zakoczy si fiaskiem tylko
dlatego, e ignorowano wymagania dotyczce interfejsu uytkownika.

Bardzo wane jest odkrycie powodów, dla których uytkownicy wykonuj okre-
lone czynnoci, nie tylko sposobu ich wykonywania. Waciwym celem two-
rzenia oprogramowania jest przecie rozwizywanie problemów biznesowych,
nie bezrefleksyjna realizacja wymaga. Dokumentowanie powodów uzasadnia-
jcych poszczególne wymagania jest dla zespou projektowego bezcennym ró-
dem informacji podczas podejmowania codziennych decyzji dotyczcych samej
implementacji.

Istnieje pewna prosta technika bliszego poznawania wymaga uytkowni-
ków, która o dziwo nie cieszy si zbyt du popularnoci — wystarczy na
chwil zosta uytkownikiem. Piszemy system dla pracowników dziau wsparcia
technicznego? Warto powici kilka dni na odbieranie telefonów od klientów

220

X Rozdzia 7. Przed projektem

(w towarzystwie dowiadczonego pracownika odpowiedniego dziau). Otrzy-
malimy zadanie automatyzacji systemu kontroli zasobów magazynowych? Mo-
e warto spdzi tydzie w magazynie

. Oprócz moliwoci zyskania gbszej

wiedzy o przyszych sposobach uywania naszego systemu ze zdziwieniem od-
kryjemy, jak pytanie: „Czy mog usi obok i przez tydzie przypatrywa si
twojej pracy?” moe pomóc w budowaniu zaufania i nawizywaniu komunikacji
z przyszymi uytkownikami. Musimy tylko pamita, aby nigdy nie przeszka-
dza przyszym uytkownikom!

SKAZÓWKA NR

Aby myśleć jak użytkownik, należy z nim popracować.

Proces gromadzenia i poznawania wymaga to take czas na nawizywanie
kontaktów z przyszymi uytkownikami, próby zrozumienia ich oczekiwa i na-
dziei wizanych z budowanym przez nas systemem. Wicej informacji na ten
temat mona znale w podrozdziale „Wielkie oczekiwania” w rozdziale 8.

Dokumentowanie wymaga

Zaómy, e usiedlimy ju przy jednym stole z uytkownikami i próbujemy
wycign od nich jakie ogólne wymagania. Wspólnie wypracowujemy kilka
prawdopodobnych scenariuszy, które do dobrze opisuj funkcje przyszej
aplikacji. Jako profesjonalici chcemy zapisa te wnioski i opublikowa gotowy
dokument, tak aby kady (programici, uytkownicy kocowi i sponsorzy pro-
jektu) móg go uywa jako podstawy do dalszych dyskusji.

Grupa odbiorców jest do szeroka.

Ivar Jacobson [Jac94] zaproponowa model, w którym do gromadzenia wyma-
ga wykorzystuje si przypadki uycia. W ten sposób mona opisywa kon-
kretne scenariusze pracy z systemem — nie przez pryzmat interfejsu uytkow-
nika, tylko w sposób bardziej abstrakcyjny. W pracy Jacobsona zabrako niestety
szczegóów, std tak wiele wspóczesnych, zupenie odmiennych koncepcji do-
tyczcych ksztatu samych przypadków uycia. Czy przypadki uycia powinny
mie formalny, czy nieformalny charakter; czy powinny mie posta opisowego
tekstu, czy raczej dokumentu z precyzyjnie okrelon struktur (na przykad
zblion do formularza)? Jaki poziom szczegóowoci bdzie waciwy (zwaywszy
na szerok grup odbiorców)?

Czy tydzie to zbyt dugo? Z pewnoci nie, szczególnie jeli w tym czasie mamy ob-

serwowa procesy, w których kierownictwo i szeregowi pracownicy dziaaj w zupe-
nie innych wiatach. W takim przypadku kierownictwo przedstawi nam jedn wizj
funkcjonowania przedsibiorstwa, ale kiedy zejdziemy pitro niej, odkryjemy zupe-
nie inn rzeczywisto, której zrozumienie z natury rzeczy wymaga czasu.

Kopalnia wymaga

W 221

Czasem to interfejs jest właściwym systemem

W artykule opublikowanym w magazynie „Wired” (styczeń 1999, strona 176.) produ-
cent i muzyk Brian Eno opisał niewiarygodny przykład technologii — nowoczesną
konsoletę mikserską. Taka konsoleta pozwala na dosłownie wszystko, co tylko można
zrobić z dźwiękiem. Mimo to, zamiast umożliwiać muzykom tworzenie lepszych
utworów oraz szybciej i taniej nagrywać kolejne dzieła, konsoleta staje na drodze
procesu twórczego i mocno go zakłóca.

Aby lepiej zrozumieć, dlaczego tak się dzieje, warto przyjrzeć się pracy inżynierów
dźwięku. Okazuje się, że ustawiają parametry dźwięku intuicyjnie. Przez lata wypraco-
wują swoistą pętlę zmysłów łączącą ich uszy i palce — na tej podstawie ustawiają
suwaki wyciszania, obracają gałki itp. Co ciekawe, interfejs nowego miksera w żaden
sposób nie wykorzystuje tych zdolności i przyzwyczajeń. Przeciwnie — zmusza
użytkowników do wydawania poleceń za pomocą klawiatury i myszy. Zestaw funkcji
oferowany przez nowy mikser był wystarczająco bogaty, jednak sposób ich opakowa-
nia odbiegał od standardów i był wręcz egzotyczny. Funkcje potrzebne inżynierom
dźwięku zostały ukryte za niezrozumiałymi nazwami lub są dostępne dopiero po
użyciu nieintuicyjnych kombinacji podstawowych elementów.

Podstawowym wymaganiem stawianym przed nowym środowiskiem jest efektywne
wykorzystanie istniejących umiejętności użytkownika. Bezmyślne powielanie tego,
co już istnieje, nie gwarantuje co prawda postępu, jednak musimy znaleźć sposób
płynnego przejścia do przyszłości.

Na przykład inżynierowie dźwięku najprawdopodobniej woleliby otrzymać interfejs
z ekranem dotykowym, aby nadal mieć pod ręką namacalne kontrolki przynajmniej
zbliżone do tych oferowanych przez tradycyjne konsolety mikserskie, a jednocześnie
zyskać szersze możliwości zapewniane przez oprogramowanie (większe niż w przy-
padku fizycznych gałek i przełączników). Warunkiem sukcesu jest zapewnienie płynnego,
komfortowego przejścia pomiędzy znanymi rozwiązaniami a nowymi mechanizmami.

Przytoczony przykład ilustruje też naszą tezę, zgodnie z którą najlepsze narzędzia
muszą dostosowywać się do rąk rzemieślnika, który ich używa. W tym przypadku to
narzędzia budowane przez nas dla innych muszą dostosowywać się do ich potrzeb
i możliwości.

Jednym ze sposobów odczytywania przypadków uycia jest zwracanie szcze-
gólnej uwagi na opisywane cele. Alistair Cockburn opracowa artyku opisujcy
ten model i zaproponowa szablony, które mona wykorzysta (w oryginalnej lub
zmienionej formie) jako punkt wyjcia ([Coc97a] oraz w internecie pod adresem
[URL 46]). Na rysunku 7.1 pokazano uproszczony przykad takiego szablonu. Na
rysunku 7.2 przedstawiono przykadowy przypadek uycia.

Stosowanie formalnego szablonu w roli przypomnienia daje nam pewno, e
nasze przypadki uycia zawsze bd obejmoway wszystkie niezbdne informa-
cje: parametry wydajnoci, informacje o innych zaangaowanych stronach,
priorytet, czstotliwo oraz rozmaite bdy i oczekiwane problemy, które mog
pojawi si w przyszoci (tzw. wymagania niefunkcjonalne). Przypadki uycia

222

X Rozdzia 7. Przed projektem

Rysunek 7.1. Szablon przypadku użycia autorstwa Cockburna

w tej formie stanowi te doskonae miejsce dla komentarzy uytkowników, jak:
„Nie, w razie wystpienia warunku X musimy raczej zrobi Y”. Szablon peni
funkcj gotowej agendy spotka z przyszymi uytkownikami naszych produktów.

Proponowana organizacja umoliwia atwe porzdkowanie przypadków uycia
w ramach struktur hierarchicznych, gdzie bardziej szczegóowe przypadki uycia
s zagniedane w ramach przypadków wyszego poziomu. Na przykad patno-
ci kart debetow i kart kredytow to wyspecjalizowane formy transakcji
kart p atnicz.

Diagramy przypadków uycia

Przepyw pracy mona wyraa na diagramach czynnoci UML, za diagramy
klas na poziomie pojciowym mog by z powodzeniem wykorzystywane do mo-
delowania interesujcych nas procesów biznesowych. Prawdziwe przypadki uy-
cia maj jednak posta tekstowych opisów z okrelon hierarchi i wzajemnymi
odwoaniami. Przypadki uycia mog zawiera hipercza do innych przypadków
uycia i mog by zagniedane w ramach pozostaych przypadków.

Wielu programistów nie moe uwierzy, e ktokolwiek moe powanie traktowa
pomys dokumentowania tak szczegóowych informacji, rysujc ludziki zoone
z kilku linii (patrz rysunek 7.3). Nie powinnimy jednak przywizywa si do ja-
kiejkolwiek notacji; powinnimy raczej wybiera t metod, która pozwala naj-
skuteczniej komunikowa wymagania naszym odbiorcom.

Kopalnia wymaga

W 223

Rysunek 7.2. Przykładowy przypadek użycia

Rysunek 7.3. Przypadki użycia w notacji UML — nawet dziecko to potrafi!

224

X Rozdzia 7. Przed projektem

Zbyt dua liczba szczegóów

Jednym z najwikszych zagroe podczas sporzdzania dokumentu z wymaga-
niami jest denie do zapisania zbyt wielu szczegóów. Dobre dokumenty o wy-
maganiach zachowuj swoj abstrakcyjno. W przypadku wymaga najprostsze
stwierdzenia, które moliwie precyzyjnie wyraaj potrzeby biznesowe, spraw-
dzaj si zdecydowanie najlepiej. Nie chodzi jednak o przesadn ogólnikowo
— w naszych wymaganiach musimy uwzgldni niezmienniki semantyczne,
a konkretne lub biece praktyki naley udokumentowa raczej w formie polityki.

Wymagania to nie architektura. Wymagania to nie projekt ani interfejs uyt-
kownika. Wymagania to konieczno.

Widzie dalej

Problem roku 2000 czsto kojarzy si z krótkowzrocznymi programistami, którzy
desperacko poszukiwali moliwoci oszczdzenia choby kilku bajtów pamici
w czasach, gdy najwiksze komputery dysponoway mniejsz iloci pamici ni
wspóczesny pilot do telewizora.

W rzeczywistoci nie bya to ani wina programistów, ani problem niedosta-
tecznej iloci pamici. Gdybymy mieli kogokolwiek wini za to niedopatrzenie,
za bd odpowiadaj raczej analitycy i projektanci systemów. Problem roku 2000
mia dwie przyczyny — nieumiejtno przewidywania sytuacji poza biec
praktyk biznesow oraz naruszanie zasady DRY.

Firmy posugiway si skróconym, dwucyfrowym formatem zapisu lat na dugo
przed pojawieniem si komputerów. Bya to powszechna praktyka. Dziaanie
wczesnych aplikacji przetwarzajcych dane ograniczao si do automatyzacji
istniejcych procesów biznesowych, std powielenie bdnego zapisu. Nawet
gdyby architektura narzucaa programistom stosowanie dwucyfrowych repre-
zentacji lat w danych wejciowych, raportach i bazie danych, powinna istnie
jaka abstrakcja DATA, która „wiedziaaby”, e te dwie cyfry to tylko skrócona
forma rzeczywistej daty.

SKAZÓWKA NR

Abstrakcje żyją dłużej niż szczegóły.

Czy „widzie dalej” wymaga od nas przewidywania przyszoci? Nie — chodzi
raczej o zapisywanie wymaga w nastpujcy sposób:

System czsto korzysta z abstrakcji DATA. System bdzie implementowa
usugi zwizane z t abstrakcj, jak formatowanie, zapisywanie czy
operacje matematyczne, w spójny i uniwersalny sposób.

Kopalnia wymaga

W 225

Wymagania w tej formie okrelaj tylko to, e system bdzie operowa na datach.
Mog te sugerowa, e na datach bd wykonywane jakie dziaania matema-
tyczne. Mog wskazywa, e daty bd dodatkowo przechowywane w rozmaitych
formatach. Mamy tutaj do czynienia z ogólnymi wymaganiami dotyczcymi mo-
duu lub klasy DATA.

Jeszcze tylko jedna malutka funkcja…

Wiele projektów koczy si niepowodzeniem wskutek niekontrolowanego roz-
szerzania zakresu prac, czyli zjawiska okrelanego mianem przerostu funkcji.
Mamy tutaj do czynienia z pewnym aspektem syndromu gotowanej aby z pod-
rozdziau „Zupa z kamieni i gotowane aby” w rozdziale 1. Co moemy zrobi,
aby zapobiec wpadniciu w puapk zbyt wielu wymaga?

W literaturze mona znale opisy wielu rónych miar, jak liczba zgoszonych
i usunitych bdów, gsto usterek, spójno, zwizki, punkty funkcyjne, wier-
sze kodu itp. Wartoci tych miar mona ledzi rcznie lub za pomoc odpo-
wiedniego oprogramowania.

Okazuje si jednak, e tylko w niewielkiej czci projektów aktywnemu ledze-
niu podlegaj wymagania. Oznacza to, e uczestnicy tych raportów nie maj
moliwoci raportowania o zmianach zakresu prac — tego, kto da poszczegól-
nych funkcji, kto zatwierdzi te wnioski, jaka jest czna liczba zaakceptowanych
wymaga itp.

Kluczem do zarzdzania wzrostem liczby wymaga jest jasne stwierdzenie, e
kada nowa funkcja wydua termin przekazania gotowego produktu sponsorom
projektu. Kiedy projekt jest opó niony o rok wzgldem pocztkowych szacunków
i kiedy wszyscy dookoa zaczynaj formuowa wzajemne oskarenia, warto dys-
ponowa precyzyjnym, kompletnym obrazem tego, jak i kiedy zanotowano wzrost
liczby wymaga.

Bardzo atwo wpa w wir „tylko jednej dodatkowej funkcji”, jednak uwane
ledzenie wymaga moe nam uatwi odkrycie, e ta tylko jedna dodatkowa
funkcja to tak naprawd ju pitnasty element dodany w tym miesicu.

Utrzymywanie glosariusza

W momencie przystpienia do rozmowy o wymaganiach uytkownicy i eksperci
z danej dziedziny zaczynaj uywa pewnych terminów, które maj dla nich
specyficzne znaczenie. Mog na przykad odrónia klienta od kupujcego. W ta-
kim przypadku zamienne stosowanie obu sów w systemie byoby niewaciwe.

Warto wic utworzy i utrzymywa glosariusz na potrzeby projektu, czyli jedno
miejsce, w którym bd definiowane wszystkie terminy i sownictwo uywane
w ramach projektu. Wszyscy uczestnicy projektu, od uytkowników kocowych
po pracowników dziau wsparcia, powinni posugiwa si tym glosariuszem, aby

226

X Rozdzia 7. Przed projektem

zachowywa spójno terminologii. Oznacza to, e glosariusz powinien by po-
wszechnie dostpny — to jeden z argumentów przemawiajcych za dokumenta-
cj udostpnian na stronach WWW (wrócimy do tego tematu w dalszej czci
tego podrozdziau).

SKAZÓWKA NR

Należy stosować glosariusz projektu.

Bardzo trudno pomylnie zakoczy projekt, w którym uytkownicy i programi-
ci stosuj odmienne nazwy dla tych samych elementów czy zdarze lub — co
gorsza — odwouj si do rónych aspektów, posugujc si t sam nazw.

Dokumenty s dla wszystkich

W podrozdziale „Pisanie przede wszystkim” w rozdziale 8. omówimy problem
publikowania dokumentów projektu w wewntrznych serwisach WWW, tak aby
zapewni atwy dostp do tych dokumentów wszystkim uczestnikom projektu.
Proponowana metoda dystrybucji dokumentacji jest szczególnie przydatna
w przypadku dokumentów powiconych wymaganiom.

Prezentujc wymagania w formie dokumentu hipertekstowego, moemy sku-
teczniej odpowiada na oczekiwania rónych odbiorców — kady czytelnik moe
znale w tego rodzaju dokumentach to, co go interesuje. Sponsorzy projektu
mog otrzymywa informacje na wysokim poziomie abstrakcji, które dadz im
pewno co do speniania celów biznesowych. Programici mog uywa hiper-
czy do wygodnego przechodzenia do coraz bardziej szczegóowych informa-
cji (nawet na poziomie odwoa do odpowiednich definicji lub specyfikacji in-
ynierskich).

Model, w którym dokumentacja jest umieszczana na stronach internetowych,
eliminuje te problem typowych, opasych tomów zatytuowanych Analiza wy-
maga, których nikt nigdy nie czyta i które staj si nieaktualne, zanim obe-
schnie tusz na papierze.

Jeli co jest internecie, jest szansa, e nawet programici to przeczytaj.

Pokrewne podrozdzia y

„Zupa z kamieni i gotowane aby” w rozdziale 1.

„Odpowiednio dobre oprogramowanie” w rozdziale 1.

„Okrgi i strzaki” w rozdziale 7.

„Pisanie przede wszystkim” w rozdziale 8.

„Wielkie oczekiwania” w rozdziale 8.

Rozwizywanie niemoliwych do rozwizania amigówek

W 227

Wyzwania

Czy uywasz oprogramowania, które piszesz? Czy mona dobrze zgroma-
dzi i zrozumie wymagania bez samodzielnego sprawdzenia oprogra-
mowania?

Wybierz jaki problem niezwizany z komputerami, który wanie musisz
rozwiza. Opracuj wymagania dla rozwizania tego problemu (bez uycia
komputera).

wiczenia

42.

Które z poniszych zda zasuguj na miano penowartociowych wyma-

ga? Spróbuj (jeli to moliwe) inaczej wyrazi zdania, które nie speniaj
warunków dobrych wymaga.

Patrz

odpowiedź 42.

w dodatku B.

Czas odpowiedzi musi by krótszy ni 500 ms.

Okna dialogowe bd miay szary kolor ta.

Aplikacja zostanie zorganizowana jako pewna liczba procesów frontowych

oraz jeden serwer wewntrzny.

Jeli uytkownik poda znaki nienumeryczne w polu numerycznym,

system odtworzy d wik ostrzegawczy i odrzuci wprowadzon warto.

Kod i dane aplikacje nie mog zajmowa wicej ni 256 kB.

Rozwizywanie niemoliwych
do rozwizania amigówek

Gordios, król Frygii, zawiza kiedy wze, którego nikt nie potrafi rozsupa.
Mówiono, e ten, kto rozwie zagadk wza gordyjskiego, zdobdzie wadz
nad Azj. Zagadk rozwiza dopiero Aleksander Wielki, który przeci wze
mieczem. Okazao si, e wystarczya tylko inna interpretacja wymaga — to
wszystko… i rzeczywicie Aleksander podbi znaczn cz Azji.

Od czasu do czasu odkrywamy gdzie w rodku projektu, e nie potrafimy zrobi
choby kroku naprzód. Trafiamy na przeszkod niemoliw do rozwizania, jak
nieumiejtno radzenia sobie z jak technologi czy fragment kodu, który
okazuje si duo trudniejszy do napisania, ni pocztkowo zakadalimy. By
moe problem rzeczywicie wydaje si niemoliwy do rozwizania. Czy jednak
rzeczywicie jest taki trudny, na jaki wyglda?

Przeanalizujmy tradycyjne ukadanki — wszystkie te kopotliwe ksztaty z drew-
na, stali lub plastiku, które tak czsto znajdujemy pod choink lub na wyprze-
daach niepotrzebnych rzeczy. Zwykle wystarczy przenie okrgy ksztat w inne
miejsce, umieci klocek w ksztacie T w okrelonym miejscu itp.

228

X Rozdzia 7. Przed projektem

Przenosimy wic okrgy ksztat lub próbujemy umieci klocek w ksztacie litery
T w okrelonym miejscu, aby szybko odkry, e to oczywiste rozwizanie nie zdaje
egzaminu. Ukadanek nie mona rozwizywa w ten sposób. To, e rozwizanie
nie jest oczywiste, nie powstrzymuje ludzi przed próbami wielokrotnego powta-
rzania tych samych czynnoci w przekonaniu, e amigówka musi mie jakie
rozwizanie.

To oczywiste, e w ten sposób nie mona doj do rozwizania. Rozwizanie ley
gdzie indziej. Sekretem ukadanki jest identyfikacja rzeczywistych (nie wyobra-
onych) ogranicze i znalezienie rozwizania w ich ramach. Niektóre ogranicze-
nia maj bezwzgl dny charakter; inne maj raczej posta nieuzasadnionych
uprzedze. Ograniczenia bezwzgldne musz by przestrzegane niezalenie od
tego, czy sprawiaj wraenie nielogicznych lub wrcz gupich. Istniej te pozorne
ograniczenia, które nie maj nic wspólnego z rzeczywistoci. Istnieje na przy-
kad stara sztuczka znana bywalcom barów, która polega na wziciu nowej,
zamknitej butelki szampana i przyjmowaniu zakadów, jakoby mona z niej
wypi piwo. Caa sztuka polega na odwróceniu butelki do góry nogami i wlaniu
niewielkiej iloci piwa do wgbienia na jej spodzie. Wiele problemów dotyczcych
oprogramowania mona rozwiza w równie przebiegy sposób.

Stopnie swobody

Popularne wyraenie „wykracza mylami poza schematy” (ang. thinking out-
side the box) zachca nas do identyfikacji ogranicze, które w naszym przypadku
nie znajduj zastosowania, i do ich ignorowania.

Przytoczona koncepcja nie jest jednak w peni suszna. Jeli tym „schematem”
jest warunek graniczny, problem polega raczej na znalezieniu schematu, który
co najwyej moe by istotnie szerszy, ni pocztkowo sdzimy.

Kluczem do rozwizania ukadanki jest zarówno rozpoznanie krpujcych nas
ogranicze, jak i stopni swobody, którymi dysponujemy — dopiero na tej pod-
stawie moemy znale wyjcie z sytuacji. Wanie dlatego ukadanki s takie
kopotliwe; czsto zbyt pochopnie rezygnujemy z potencjalnych rozwiza.

Czy potrafimy na przykad poczy wszystkie punkty na poniszym rysunku
i wróci do punktu wyjcia, rysujc zaledwie trzy proste odcinki (bez odrywania
dugopisu od papieru ani dwukrotnego rysowania odcinka czcego te same
punkty) [Hol78]?

Musimy zmierzy si ze wszystkimi przyjtymi z góry wyobraeniami i oceni,
czy rzeczywicie reprezentuj fizyczne ograniczenia.

Rozwizywanie niemoliwych do rozwizania amigówek

W 229

Problemem nie jest wic to, czy mylimy schematycznie, czy potrafimy wyj poza
schematy. Kluczem do rozwizania jest raczej znalezienie schematu — identyfi-
kacja faktycznych ogranicze.

SKAZÓWKA NR

Nie należy wykraczać myślami poza schemat — należy raczej znaleźć ten
schemat.

W razie napotkania szczególnie kopotliwego problemu warto zapisa sobie
wszystkie moliwe cieki rozwizania, które na tym etapie potrafimy dostrzec.
Nie naley niczego pomija, choby wydawao si zupenie niepraktyczne lub
wrcz gupie. Dopiero po sporzdzeniu tej listy warto j uwanie przejrze i wyja-
ni, dlaczego ta czy inna cieka nie doprowadzi do szczliwego koca. Czy na
pewno? Potrafimy to udowodni?

Przypomnijmy sobie histori konia trojaskiego — nowatorskiego rozwizania
problemu, który wydawa si niemoliwy do rozwizania. Jak niepostrzeenie
przerzuci wojsko do dobrze ufortyfikowanego miasta? Jestemy pewni, e kon-
cepcja „przez gówn bram” pocztkowo bya odrzucana jako samobójcza.

Warto przypisywa poszczególne ograniczenia do kategorii i nadawa im prio-
rytety. Kiedy stolarze przystpuj do projektu, zaczynaj od cicia najduszych
fragmentów drewna, by nastpnie odpowiednio poci pozostae fragmenty.
W ten sam sposób chcemy najpierw identyfikowa najbardziej krpujce ograni-
czenia i umieszcza pozostae ograniczenia w ich ramach.

Rozwizanie zagadki czterech punktów czonych trzema odcinkami mona
znale w dodatku B.

Musi istnie prostszy sposób!

Zdarza si, e pracujemy nad rozwizaniem problemu, który sprawia wraenie
duo trudniejszego, ni jest w rzeczywistoci. Czsto sdzimy, e obralimy
niewaciw drog — musi przecie istnie prostszy sposób osignicia celu! By
moe ju teraz nie jestemy w stanie dotrzyma harmonogramu lub wrcz popa-
damy w rozpacz, tracc wiar w moliwo prawidowego funkcjonowania sys-
temu, poniewa jaki problem wydaje si „niemoliwy do rozwizania”.

W takich przypadkach powinnimy zatrzyma si na chwil i zada sobie kilka
pyta:

Czy istnieje prostszy sposób?

Czy rozwizujemy waciwy problem, czy natrafilimy tylko na zewntrzn
przeszkod techniczn?

Dlaczego w ogóle analizowana kwestia jest problemem?

Co sprawia, e jego rozwizanie jest trudne?

230

X Rozdzia 7. Przed projektem

Czy nie ma innego rozwizania?

Czy w ogóle musimy to robi?

Próby odpowiedzenia sobie na te pytania nierzadko prowadz do zaskakujcych
odkry. W wielu przypadkach wystarczy ponowna interpretacja wymaga, aby
pozby si caego zbioru problemów (tak jak w przypadku wza gordyjskiego).

Wszystko, czego nam trzeba, to prawdziwe ograniczenia, nietrafione ograniczenia
oraz wiedza, jak je rozrónia.

Wyzwania

Spróbuj z dystansu spojrze na dowolny trudny problem, który wanie
próbujesz rozwiza. Czy moesz po prostu przeci ten wze gordyjski?
Zadaj sobie wymienione powyej pytania, w szczególnoci: „Czy nie ma
innego rozwizania?”.

Czy zbiór ogranicze by znany w momencie podpisywania kontraktu na
biecy projekt? Czy zdefiniowane wówczas ograniczenia wci s aktualne
i czy ich interpretacja zachowaa swoj warto?

Nie, dopóki nie jeste gotowy

Czasem chwila zawahania moe by wybawieniem.

James Thurber, The Glass in the Field

Najlepsi wykonawcy maj jedn wspóln cech: wiedz, kiedy zacz i kiedy
skoczy. Nurek stoi na trampolinie i czeka na idealny moment do skoku. Dyry-
gent nieruchomo stoi przed orkiestr z uniesionymi rkami a do momentu,
w którym uzna, e to najlepszy czas na rozpoczcie koncertu.

My take chcemy by wielkimi wykonawcami. Musimy wsuchiwa si w gos
podpowiadajcy: „Zaczekaj”. Jeli siadamy do pisania kodu i stale nachodz
nas jakie wtpliwoci, nie moemy ich lekceway.

SKAZÓWKA NR

Należy słuchać uporczywych wątpliwości — nie wolno zaczynać pracy,
dopóki nie jest się gotowym.

Istnia kiedy model trenowania tenisa okrelany mianem „gry wewntrznej”.
Trening polega na wielogodzinnym przebijaniu piek nad siatk bez zwracania
szczególnej uwagi na precyzj — chodzio raczej o ocen miejsca upadania piki
wzgldem jakiego celu (zwykle krzesa).Celem tych wicze byo trenowanie
podwiadomoci i refleksu, tak aby zawodnik potrafi bez zastanowienia wy-
biera waciwy sposób uderzenia piki.

Nie, dopóki nie jeste gotowy

W 231

Jako programici robimy mniej wicej to samo przez ca karier. Próbujemy
rozmaitych rozwiza i sprawdzamy, które z nich zdaj egzamin, a które oka-
zay si nietrafione. Z czasem gromadzimy rozmaite dowiadczenia i wiedz.
Kiedy zmagamy si z uporczywymi wtpliwociami lub nasze dowiadczenie
podpowiada nam, aby obra inn drog, warto z tych „podszeptów” skorzysta.
By moe nie jestemy w stanie dokadnie wskaza palcem, co nam si nie
podoba, ale wystarczy troch czasu, aby obecne wtpliwoci przerodziy si w co
bardziej namacalnego — konkretny problem do rozwizania. Wytwarzanie opro-
gramowania wci nie jest nauk. Moemy wic pozwoli sobie na udzia in-
stynktu w realizowanych przedsiwziciach.

Uzasadniona obawa czy niepotrzebna zwoka?

Kady boi si pustej kartki papieru. Rozpoczynanie nowego projektu (lub nawet
rozpoczynanie prac nad nowym moduem w ramach istniejcego projektu) bywa
bardzo irytujcym dowiadczeniem. Wielu programistów wolaoby jak najduej
odkada te szczególnie trudne, pocztkowe fazy projektu. Jak w takim razie
stwierdzi, czy mamy do czynienia z nieuzasadnion gr na zwok, czy odpo-
wiedzialnym oczekiwaniem na zgromadzenie wszystkich niezbdnych elementów?

W naszym przypadku najskuteczniejsz technik radzenia sobie w tych oko-
licznociach jest tworzenie prototypów. Naley wybra obszar, który wydaje nam
si szczególnie kopotliwy, i przystpi do tworzenia rozwiza potwierdzajcych
lub obalajcych te zaoenia. W wikszoci przypadków tworzenie prototypów
prowadzi do jednej z dwóch sytuacji. Z jednej strony, krótko po przystpieniu
do tych eksperymentów moemy uzna, e tracimy czas. To zniechcenie czsto
pokazuje, e pocztkowe obawy byy spowodowane tylko niechci do pierw-
szych faz projektu. Warto wówczas przerwa prace nad prototypami i przej
do waciwego wytwarzania.

Z drugiej strony, podczas tworzenia prototypów moemy nagle odkry, e które
z podstawowych zaoe dotyczcych danego projektu byo bdne. Co wicej,
bdziemy potrafili jasno okreli, jak zmieni i wyrazi na nowo to zaoenie.
W takim przypadku moemy w poczuciu komfortu przerwa prace nad prototy-
pami i przystpi do realizacji waciwego projektu (z uwzgldnieniem skorygo-
wanej wiedzy). Instynkt nas nie zawiód — wanie oszczdzilimy sobie i nasze-
mu zespoowi mnóstwo wysiku, który w przeciwnym razie poszedby na marne.

Jeli decydujemy si na przygotowanie prototypu jako sposobu lepszego zba-
dania róde swojego niepokoju, koniecznie musimy pamita o pierwotnych
przyczynach tej decyzji. Ostatni rzecz, której nam potrzeba, jest powicenie
wielu tygodni na powane prace programistyczne tylko po to, aby wreszcie
przypomnie sobie, e pracujemy tylko nad prototypem.

Proponowany model jest te przejawem cynizmu — atwiej zyska polityczn
akceptacj dla eksperymentu z prototypem ni prostego stwierdzenia: „Mam
obawy co do tego projektu” i ostentacyjnego rozpoczcia ukadania pasjansa.

232

X Rozdzia 7. Przed projektem

Wyzwania

Omów syndrom obaw przed pocztkiem projektu ze swoimi wspópra-
cownikami. Czy inni dowiadczaj tego samego? Czy gono wyraaj
swoje obawy? Jakich sztuczek uywaj do radzenia sobie z tym proble-
mem? Czy caa grupa jest zaangaowana w rozwiewanie obaw poszcze-
gólnych czonków zespou, czy raczej wywiera dodatkow presj?

Puapka specyfikacji

Pilot ldujcy zachowuje status pilota prowadzcego do momentu zejcia
na wysoko decyzyjn, kiedy prowadzcy pilot nieldujcy przejmuje zadania
nieprowadzcego pilota ldujcego, chyba e ten drugi wyda komend „odejcie”.
W takim przypadku nieldujcy pilot prowadzcy dalej prowadzi, a ldujcy
pilot nieprowadzcy dalej nie prowadzi a do nastpnej komendy „lduj”
lub „odejcie”. W zwizku z ostatnimi nieporozumieniami dotyczcymi tych
przepisów, uznaem, e naley je doprecyzowa.

Memorandum linii British Airways

cytowane w pimie „Pilot Magazine”, grudzie 1996

Specyfikacja programu to proces przetwarzania wymaga i ich redukowania do
punktu, w którym programista moe efektywnie korzysta ze swoich umiejtno-
ci. Tworzenie specyfikacji to akt komunikacji, wyjaniania i precyzowania fak-
tów w sposób pozwalajcy wyeliminowa najwaniejsze niejasnoci. Oprócz
przesania dla programisty, który bdzie pracowa nad pocztkow implementa-
cj, specyfikacja jest te zapisem dla przyszych pokole programistów, którzy
bd konserwowali i rozszerzali ten kod. Specyfikacja jest te swoist umow
z uytkownikiem — zapisem jego potrzeb i nieformalnym kontraktem potwier-
dzajcym, e system w swojej ostatecznej formie bdzie spenia konkretne
wymaganie.

Pisanie specyfikacji to dua odpowiedzialno.

Problem w tym, e wielu projektantów nie wie, kiedy przesta. Pracuj w po-
czuciu, e zadanie jest wykonane dopiero po zapisaniu kadego, choby naj-
drobniejszego szczegóu.

Taka metoda jest bdna z kilku powodów. Po pierwsze, wiara w to, e jakakol-
wiek specyfikacja moe uwzgldnia wszystkie szczegóy i niuanse systemu bd
jego wymaga, jest przejawem naiwnoci. W ograniczonych dziedzinach proble-
mów istniej zwykle formalne metody opisywania systemów, co jednak nie zwal-
nia projektanta z obowizku wyjanienia znaczenia stosowanej notacji uyt-
kownikom kocowym — adna notacja nie eliminuje problemu interpretacji przez
czowieka. Nawet bez problemów zwizanych z t interpretacj trudno oczeki-
wa, aby przecitny uytkownik potrafi precyzyjnie okreli, czego oczekuje od
nowego systemu. Nawet jeli uytkownicy twierdz, e rozumiej wymagania,

Puapka specyfikacji

W 233

i podpisuj przygotowany przez nas 200-stronicowy dokument, moemy by
pewni, e kiedy zobacz dziaajcy system, zasypi nas daniami zmian.

Po drugie, pewnym problemem jest ograniczony potencja wyraania myli w na-
szym jzyku. Wszystkie techniki prezentowania informacji w formie diagramów
oraz metody formalne opieraj si na zapisach dotyczcych wykonywanych ope-
racji wyraonych w konkretnym jzyku

. Praktyka pokazuje, e jzyki naturalne

nie najlepiej sprawdzaj si w tej roli. Wystarczy spojrze na sownictwo stoso-
wane w dowolnej umowie — prawnicy dcy do maksymalnej precyzji posu-
guj si wyjtkowo nienaturalnym jzykiem.

Zachcamy do prostego eksperymentu. Spróbujmy napisa krótki tekst, który
wyjani odbiorcy, jak wiza sznurowada. Do dziea!

Kady, kto ma z tym zadaniem podobne problemy do nas, napisze: „Owi teraz
kciuk i palec wskazujcy, tak aby wolny koniec wszed pod lewe sznurowado…”
lub co równie niezrozumiaego. To zadziwiajco trudne zadanie. Co ciekawe,
wikszo z nas wie buty, w ogóle nie mylc o tej czynnoci.

SKAZÓWKA NR

Niektóre rzeczy lepiej robić, niż o nich mówić.

I wreszcie po trzecie, istnieje problem kaftana bezpieczestwa. Projekt, który nie
pozostawia kodujcemu adnego pola do implementacji, uniemoliwia mu pene
pokazanie swoich umiejtnoci. Niektórzy twierdz, e wanie takie rozwizanie
jest najlepsze, ale nie maj racji. Czsto wanie podczas kodowania ujawniaj
si pewne potencjalne opcje. Nierzadko podczas kodowania mylimy sobie:
„Ciekawe, poniewa zakodowa em t funkcj w ten sposób, móg bym uzu-
pe ni j o pewne dodatkowe rozwizanie dos ownie w pi minut” lub
„Specyfikacja mówi, e mam zrobi to i to, ale niemal identyczne rezultaty
mog osign w inny sposób, powi cajc na to dwa razy mniej czasu”.
Nie powinnimy, oczywicie, zbyt pochopnie wprowadza zmian w projekcie, ale
warto pamita, e nawet nie dostrzeglibymy wspomnianych okazji, gdy ten
projekt by zbyt precyzyjny.

Jako pragmatyczni programici powinnimy postrzega gromadzenie wymaga,
projektowanie i implementacje jako odmienne aspekty tego samego procesu
— procesu dostarczania systemu wysokiej jakoci. Nie warto inwestowa w ro-
dowiska, gdzie zbieranie wymaga, pisanie specyfikacji i samo kodowanie ma
posta odrbnych, odizolowanych czynnoci. Powinnimy raczej wdraa modele
czce te elementy, gdzie specyfikacja i implementacja stanowi tylko róne
aspekty jednego procesu identyfikacji i kodowania wymaga. Kada z tych czyn-
noci powinna prowadzi wprost do nastpnej bez sztucznych granic. Szybko

Istniej co prawda formalne metody algebraicznego wyraania operacji, jednak rzadko

s stosowane w praktyce. Tego rodzaju techniki wci wymagaj od analityka tumacze-
nia poszczególnych zapisów uytkownikom kocowym.

234

X Rozdzia 7. Przed projektem

odkryjemy, e waciwy proces wytwarzania oprogramowania zachca jego
uczestników do uwzgldniania wniosków pyncych z implementacji i testów
w procesie przygotowywania specyfikacji.

Dla jasnoci podkrelamy, e nie jestemy przeciwnikami generowania specyfi-
kacji. Przeciwnie — zdajemy sobie spraw z tego, e w pewnych przypadkach na-
wet najbardziej szczegóowe specyfikacje s niezbdne (na przykad dla jasnoci
kontraktu, z uwagi na specyficzne rodowisko, w którym pracujemy, lub z powo-
du nietypowego charakteru tworzonego produktu)

. Musimy przy tym mie

wiadomo, e zapisujc coraz bardziej szczegóowe specyfikacje, prdzej czy
pó niej osigniemy punkt, od którego dalsze uszczegóawianie tych zapisów nie
bdzie przynosio adnych korzyci lub wrcz bdzie powodowao straty. Powinni-
my te unika budowy specyfikacji ponad innymi specyfikacjami bez uprzedniego
opracowywania implementacji czy choby prototypów — bardzo atwo zapisa
w specyfikacji rozwizania, których w praktyce nie bdzie mona zbudowa.

Im duej trwa tworzenie specyfikacji i im bardziej ten proces jest wykorzysty-
wany w roli tarczy chronicej programistów przed przeraajcym zadaniem
pisania kodu, tym trudniej przystpi do waciwego kodowania. Nie moemy
wpada w spiral specyfikacji — w pewnym momencie musimy zacz kodowa!
Jeli odkrywamy, e nasz zespó przyj wygodn postaw pisania specyfikacji
w nieskoczono, musimy to przerwa. Warto wówczas rozway opracowanie
prototypów lub zastosowanie modelu pocisków smugowych.

Pokrewne podrozdzia y

„Pociski smugowe” w rozdziale 2.

Wyzwania

Przytoczony wczeniej przykad sznurowade jest interesujc ilustracj
problemu wyraania prostych czynnoci sowami. Czy nie warto byoby
opisa ten proces za pomoc diagramów zamiast sów? A moe zastoso-
wa zdjcia? Moe warto skorzysta z jakiej formalnej notacji zaczerp-
nitej z topologii? Moe sprawdziyby si modele z drucianymi sznuro-
wadami? Jak nauczyby tej czynnoci mae dziecko?

Obraz jest czasem wart wicej ni dowolna liczba sów. Innym razem ob-
raz jest bezwartociowy. Czy w razie stwierdzenia, e budowana specy-
fikacja jest zbyt szczegóowa, obrazy lub specjalne notacje mog w czym
pomóc? Jak szczegóowe powinny by same obrazy lub notacje? Czy
narzdzie graficzne byoby lepsze od fizycznej tablicy?

Zapisywanie szczegóowych specyfikacji jest, oczywicie, uzasadnione w przypadku

systemów, od których zaley ludzkie ycie. Wydaje si, e podobne zasady powinny
dotyczy take interfejsów i bibliotek tworzonych z myl o innych programistach.
Jeli jedynym efektem naszej pracy ma by zbiór wywoa funkcji, powinnimy zro-
bi wszystko, aby te wywoania byy precyzyjnie zdefiniowane.

Okrgi i strzaki

W 235

Okrgi i strzaki

[zdjcia] z okrgami i strzakami oraz jednym zdaniem wyjanienia
na drugiej stronie bd wiadczy przeciwko nam…

Arlo Guthrie, Alice’s Restaurant

Od czasów programowania strukturalnego, przez koncepcje zespoów pod wodz
gównego programisty, narzdzia CASE, wytwarzanie kaskadowe, model spirali,
propozycje Jacksona, diagramy ER, chmury Boocha, technik OMT, obiekto-
wo, metod Coada-Yourdona, a po wspóczesne diagramy UML informatycy
nigdy nie mogli narzeka na brak metod tworzonych z myl o upodabnianiu ich
pracy do przedsiwzi inynierskich. Kada metoda znalaza wiernych wyznaw-
ców i cieszya si popularnoci w pewnym okresie. Niedugo potem kada bya
zastpowana przez nastpn. Sporód wszystkich wymienionych metod chyba
tylko pierwsza — programowanie strukturalne — istniaa naprawd dugo.

Mimo to niektórzy programici, dryfujc po morzu zatopionych projektów, kur-
czowo trzymaj si najnowszych odkry i metodyk. Przypominaj przeraonych
marynarzy apicych pywajce deski. Kady nowy element pojawiajcy si na
powierzchni traktuj jako szans na popraw swojej sytuacji. Ostatecznie jednak
okazuje si, e niezalenie od jakoci pywajcych szcztków statku programici
wci dryfuj bez celu.

Nie chcemy by le zrozumiani. Lubimy (niektóre) formalne techniki i metody.
Uwaamy jednak, e bezmylne wdraanie kadej nowej techniki bez analizy jej
przydatnoci w kontekcie praktyk wytwarzania i wasnych moliwoci jest
najkrótsz drog do rozczarowania.

SKAZÓWKA NR

Nie możemy być niewolnikami formalnych metod.

Formalne metody maj pewne powane ograniczenia.

Wikszo formalnych metod wymusza zbieranie wymaga przy uyciu
kombinacji diagramów i jakich form dodatkowych opisów. Tworzone
w ten sposób obrazy reprezentuj wymagania, tak jak rozumiej je pro-
gramici. Okazuje si jednak, e w wielu przypadkach takie diagramy s
zupenie niezrozumiae dla uytkowników kocowych, zatem projektanci
musz je dodatkowo interpretowa. Wanie dlatego nie istniej rzeczy-
wiste, formalne techniki weryfikacji wymaga przez docelowych uyt-
kowników przyszego systemu — wszystko opiera si na wyjanieniach
projektantów, a wic dokadnie tak jak w tradycyjnych dokumentach
z wymaganiami. Dostrzegamy pewne zalety takiego sposobu gromadzenia
wymaga, jednak zdecydowanie wolimy (o ile to moliwe) przekazywanie
uytkownikowi prototypu, z którym sam bdzie móg eksperymentowa.

236

X Rozdzia 7. Przed projektem

Metody formalne pozornie zachcaj do specjalizacji. Jedna grupa ludzi
pracuje nad modelem danych, inna dba o architektur, a pracownicy
odpowiedzialni za gromadzenie wymaga przygotowuj przypadki uycia
(lub ich odpowiedniki). Z dowiadczenia wiemy, e taki model pracy
utrudnia komunikacj i prowadzi do straty czasu. Co wicej, przytoczony
podzia ról wie si z ryzykiem postawy „my kontra oni” na linii projek-
tanci – programici. Wolimy model, w którym kady rozumie cay system,
nad którym pracuje. Zgromadzenie szczegóowej wiedzy na temat kadego
aspektu systemu nie zawsze jest moliwe, ale powinnimy przynajmniej
wiedzie, jak przebiega interakcja poszczególnych komponentów, gdzie s
przechowywane dane i jakie s wymagania.

Wszyscy lubimy pisa systemy dynamiczne, które dostosowuj si do
warunków i które pozwalaj zmienia charakter aplikacji w czasie wyko-
nywania (za pomoc metadanych). Wikszo wspóczesnych metod for-
malnych czy obiekty statyczne lub modele danych z rozmaitymi mecha-
nizmami zdarze lub czynnoci. Nie znale limy jednak adnej metody
umoliwiajcej ilustrowanie dynamiki, której oczekujemy od naszych
systemów. W praktyce wikszo formalnych metod wyznacza zupenie
przeciwny kierunek, zachcajc nas do definiowania statycznych relacji
czcych obiekty, których interakcja powinna mie charakter duo bar-
dziej dynamiczny.

Czy te metody si opacaj?

W 1999 roku w swoim artykule dla miesicznika CACM [Gla99b] Robert Glass
dokona przegldu bada nad wzrostem produktywnoci i jakoci oferowanym
przez siedem rónych technologii wytwarzania oprogramowania (jzyki progra-
mowania czwartej generacji, technologie strukturalne, narzdzia CASE, metody
formalne, metodyki tzw. czystego pokoju, modele procesów oraz techniki obiek-
towe). Wykaza, e pocztkowy zachwyt towarzyszcy wszystkim wymienionym
metodom by nieuzasadniony. Stosowanie niektórych sporód tych metod przy-
nosi co prawda pewne korzyci, jednak zwykle mona je dostrzec dopiero po po-
cztkowym okresie spadku produktywnoci i jakoci, kiedy nowa technika jest
wdraana i poznawana przez uytkowników. Nigdy nie naley lekceway kosz-
tów wdraania nowych narzdzi i metod. Musimy by przygotowani na trakto-
wanie pierwszych projektów realizowanych przy uyciu tych technik jako proce-
sów poznawczych.

Czy powinnimy stosowa formalne metody?

Oczywicie. Zawsze powinnimy pamita, e formalne metody wytwarzania to
tylko kolejne narzdzia w naszym zestawie. Jeli po uwanej analizie czujemy
potrzeb zastosowania jakiej formalnej metody, moemy i t drog — mu-
simy jednak pamita, kto podejmuje decyzje. Nie moemy dopuci do sytuacji,
w której bdziemy niewolnikami tej czy innej metodyki. Okrgi i strzaki kiepsko

Okrgi i strzaki

W 237

sprawdzaj si w roli przeoonych. Pragmatyczni programici krytycznym okiem
patrz na metodyki, po czym wycigaj z kadej z nich to, co najlepsze, prze-
ksztacajc je w zbiór sprawdzonych praktyk, które z kadym miesicem zyskuj
na jakoci. To klucz do sukcesu. Powinnimy ustawicznie poprawia i doskonali
swoje procesy. Nigdy nie powinnimy akceptowa skostniaych ogranicze na-
rzucanych przez metody jako ograniczenia wasnego wiata.

Nie moemy bezmylnie przyjmowa faszywych opinii o poszczególnych me-
todach. Nawet jeli ludzie przynosz na spotkania wielkie pachty z diagramami
klas i po 150 przypadków uycia, caa ta masa papieru wci jest tylko zawodn
interpretacj wymaga i projektu. Kiedy analizujemy efekt pracy jakiego narz-
dzia, powinnimy przynajmniej spróbowa zapomnie, ile to narzdzie kosztowao.

SKAZÓWKA NR

Drogie narzędzia nie generują lepszych projektów.

Formalne metody z pewnoci maj swoje miejsce w wiecie wytwarzania
oprogramowania. Jeli jednak obserwujemy projekt realizowany wedug filozofii
„diagram klas to aplikacja, reszta to tylko mechaniczne kodowanie”, moemy by
pewni, e mamy do czynienia zespoem zmierzajcym wprost ku klsce.

Pokrewne podrozdzia y

„Kopalnia wymaga” w rozdziale 7.

Wyzwania

Diagramy przypadków uycia UML wchodz w skad procesu gromadze-
nia wymaga (patrz podrozdzia „Kopalnia wymaga” w rozdziale 7.). Czy
takie diagramy s efektywnym sposobem komunikacji z uytkownikami?
Jeli nie, dlaczego ich uywasz?

Jak stwierdzi, czy jaka formalna metoda przynosi korzyci Twojemu ze-
spoowi? Co mona mierzy? Co jest traktowane jako poprawa? Czy po-
trafisz odróni korzyci wynikajce ze stosowania tego narzdzia od zwy-
kych skutków rosncego dowiadczenia czonków zespou?

Gdzie ley punkt rentownoci dla wprowadzania nowych metod w Twoim
zespole? Jak szacujesz przysze korzyci wzgldem biecych spadków
produktywnoci (na etapie wprowadzania nowego narzdzia)?

Czy narzdzia, które sprawdzaj si w przypadku wielkich projektów,
okazuj si równie dobre w mniejszej skali? Czy w przypadku odwrotnej
relacji jest podobnie?

Skorowidz

Abstract Data Type, 137
abstrakcyjny typ danych, 137
ACM, 276
ADT, 137
Aegis, 285
agent, 135
akrostych, wiedza, 39
aktywny generator kodu, 120, 121
algorytm,

szacowanie zasobów, 193
szybko, 193

analiza pokrycia, 260
anonimowo, 273
aplikacja, wdroenie, 174
architektura, 170
asercja, 131, 141
asertywne programowanie, 140
Association for Computing Machinery,

276

automatyczne

kompilowanie, 106
refaktoryzacja, 203

automatyzacja, 245, 246, 249

czynnoci, 96

awaria, 138

baza danych, konserwacja, 117
bean, 165
Beck Kent, 3

Beowulf, 282
bibliotekarz projektu, 242
binarny format, 91
bison, 284
bdne zaoenia, 115
Bossuet J. B., 22
budowa, 249
bug, 107

C, 281
C++, 278, 281
cel tworzenia oprogramowania, 219
celowe programowanie, 191
Cetus Links, 279
ClearCase, 285
Cleeland Chris, 3
Cockburn Alistair, 287
Communications of the ACM, 277
comp.object, 286
CORBA, 284

Event Service, 176, 177

Cunningham Ward, 11
CVS, 285
Cygwin, 98, 284
czasopisma branowe, 35
czasowe zwizki, 167
czynnoci UML, 168

318

X Skorowidz

dane,

diagnozowanie, 110
generowanie, 118
interfejs, 172
kocowe, 249
mechanizm obsugi, 145
reguy, 164
rzeczywiste, 258
strategia biznesowa, 164
syntetyczne, 258
testowe, 93,258
trwae bezpieczestwo, 92
typ abstrakcyjny, 137
wczesne wykrywanie usterek, 132

DBC, 127
DDD, 282
dead line, 261
debuger, 112
decyzja odwracalna, 155
Demeter, 158, 159, 288
deployment descriptor, 166
design by contract, 127
deskryptor wdroenia, 166
dezaktualizacja wiedzy, 32
diagnostyczne

okno, 212
widok, 180

diagnozowanie,

bdów, 110
lista kontrolna, 115
oprogramowania, 108
problemów, 109

diagram

czynnoci UML, 168
sekwencji, 175

DOC++, 283
DocBook, 268
dokumentacja, 226

autor, 267
dezaktualizacja, 267
doskonaa, 41
posta, 267
rola, 262
schemat oznaczania, 268
wewntrzna, 263
zaangaowanie czytelników

w tworzenie, 41

zewntrzna, 263

doskonae oprogramowanie, 125
doskonay warsztat, 89
dostp do waciwoci Javy, 118
Dr. Dobbs Journal, 277
drzewo Javy, 178
Dynamics of Software Development,

278

dynamiczna

konfiguracja, 162
zmiana wiedzy, 34

dziennik , 212

edycja efektywna, 100
edytor, 101, 280

funkcje, 101
wybór, 104

efekt Stroopa, 264
efektywne przekazywanie

informacji, 39

EJB, 165
elegancja, 181
eliminacji proces, 113
elvis, 280
Emacs, 280
Enterprise Java Beans, 165
entropia, 24
entuzjazm zwizany z projektem, 40
Expect, 283

filozofia pragmatyczna, 22
formalne metody, 235, 236
Fowler Martin, 3, 287
funkcje edytora, 101

generator kodu, 120, 248

aktywny, 120, 121
pasywny, 120

generowanie

danych testowych, 118
dokumentacji WWW, 118

Gimp, 288
glosariusz, 225
godny konsument, 171

Skorowidz

W 319

gówny tester, 241
GNU, 288
graficzny interfejs uytkownika, 96
grupa dyskusyjna, 25, 37
GUI, 96
guru, 37

Hopper Grace, 107
hungry consumer, 171

iContract, 282
IDE, 90, 96
identyfikacja ogranicze, 228, 229
IEEE, 276
ignorowanie wiadomoci, 41
IIOP, 284
implementacja przypadkowa, 189
inspirowanie zmian, 21
interfejs

czytelny, 172
czcy jzyki, 118

Internet Inter-ORB Protocol, 284
inwestowanie w wiedz, 33
ISE Eiffel, 281
izolacja obiektów, 175

jako, 240

kontrola, 30
nienazwana, 11
oprogramowania, 30
projektu, 26

Java, 281

CC, 283
dostp do waciwoci, 118
drzewo, 178
równowaenie zasobów, 152
Spaces, 183, 287

jednostkowy test, 205, 208
jzyk,

interfejs czcy, 118
programowania, 34
wzorców, 10

K Desktop, 288
kana zdarze, 177
katalizator zmian, 28
katastrofa oprogramowania, 28
KDE, 288
kod,

generator, 120, 121
generowanie, 248
atwiejszy w konserwacji, 159
poprawianie, 200
system kontroli, 104
zabezpieczajcy, 92
ródowy, 104

kodowanie, 187
koincydencja programowania, 171,

188

kolejno, 167
komentarz, 263

lista elementów, 265
nagówki, 264
tre, 264

komercjalizacja, 36
komórki, 156
kompilacja, 247
kompilator, 281
kompilowanie

automatyczne, 106
powtarzalne, 106

komponent, 165
komunikacja, 42

oczekiwa, 270
rola, 241
w ramach projektu, 250
z lud mi, 38

konfiguracja

dynamiczna, 162
edytora, 101

konserwacja schematu bazy danych,

117

konstrukcja oprogramowania, 200
konsument godny, 171
kontekst przypadkowy, 190
kontener komponentów, 165
kontrakt, 126

dynamiczny, 135
test zgodnoci, 206

320

X Skorowidz

kontraktowe projektowanie, 127

zalety, 130

kontrola jakoci, 30
kontroler, 177, 179
kreator, 214
krytyczne mylenie, 36
ksika

jak czsto czyta, 34
pisanie, 118

kultura testowania, 212

Lakos John, 3, 29
lepsza reputacja, 271
linia krytyczna, 261
lista kontrolna diagnozowania, 115

atwe testowanie, 94

maksymalna produktywno, 30
maa stabilno systemu, 158
Martin Robert, 287
McBreen Pete, 3
mechanizm,

obsugi bdów, 145
testowy, 210

metadane, 162, 163, 166
metoda,

kaskadowa tworzenia

oprogramowania, 243

formalna, 235, 236

MKS Source Integrity, 285
model, 177, 179

godnego konsumenta, 171

modularyzacja procesu dostarczania

oprogramowania, 32

moduy, 156
MVC, 177
mylenie krytyczne, 36

Nana, 282
narzdzia, 89, 100, 245, 281

do pracy z tekstem, 116

nauka,

okazje, 36
nowych technologii, 34

Netscape, 287
niedoskonae oprogramowanie, 32
nienazwana jako, 11
niezmiennik, 133

ptla, 134
semantyczny, 134

niszczenie dobrego programu, 31
notacja O(), 194
Notatnik, 102

O() notacja, 194
obiekt, 150

izolacja, 175

obsugi bdów, mechanizm, 145
odwracalna decyzja, 155
ograniczenia

identyfikacja, 228, 229
metody formalne, 235

okno diagnostyczne, 212
OMG, 284
oprogramowanie,

cel tworzenia, 219
diagnozowanie, 108
doskonae, 125
jako, 30
kaskadowa metoda tworzenia, 243
katastrofa, 28
konstrukcja, 200
modularyzacja procesu

dostarczania, 32

niedoskonae, 32
rozkad, 24, 25

Skorowidz

W 321

panikowanie, 109
pasywny generator kodu, 120
Perforce, 285
Perl, 281
Perl Power Tools, 284
ptli niezmiennik, 134
pisanie ksiki, 118
pisownia, 41
planowanie wypowiedzi, 39
plik dziennika, 212
pocztek dziaalnoci, 28
poczta elektroniczna, 42

ignorowanie wiadomoci, 41

poprawianie kodu, 200
poprawna pisownia, 41
portfolio,

powikszanie, 36
wiedzy, 33

potencja rodowiska, 96
powoka,

rola, 95
Z, 286
zalety, 98

powtarzalne kompilowanie, 106
praca,

jak zacz, 231
przepyw, 168
z lud mi, 126

pragmatyczny programista, 21, 22
prawo Demeter, 158, 159

dla funkcji, 158

problem

diagnozowanie, 109
roku 2000, 224

procedury zatwierdzania, 251
proces eliminacji, 113
produktywno, 102

maksymalna, 30

profil rozmówców, 39
program

niszczenie, 31
specyfikacja, 232

programista pragmatyczny, 21, 22
programowanie, 31

asertywne, 140
aspektowe, 287
celowe, 191

edytor, 101
ekstremalne, 286
przemylane, 188
przez koincydencj, 171, 188
wielowtkowe, 171

projekt

bibliotekarz, 242
Demeter, 288
jako, 26
sukces, 270
udany, 28

projektowanie kontraktowe, 127

zalety, 130

prototyp, 231
próby si na pocztku dziaalnoci, 28
przekazywanie informacji, 39
przemylane programowanie, 188
przepyw pracy, 168
przestrze krotek, 183
przetwarzanie wiedzy, 91
przydzielanie zagniedania, 149
przypadki uycia, 220, 222, 223
przypadkowa

implementacja, 189
kontekst, 190

publikowanie, 175
PVC, 285
Python, 281

quality without a name, 11
QWAN , 11

Raymond Eric, 287
RCS, 285
reakcja na wymówki, 24
refaktoryzacja, 201, 202

automatyczna, 203
istota, 202

regularne inwestowanie w wiedz, 33
reguy biznesowe, 164
Remote Method Invocation, 146
repozytorium, 106
reputacja, 271
Richardson Jared, 3
RMI, 146

322

X Skorowidz

roku 2000 problem, 224
rola sabotaysty, 260
rozkad oprogramowania, 24, 25
rozmówcy priorytety, 40
rozszerzalno edytora, 101
rozwijanie talentu, 89
równowaenie zasobów, 150

Java, 152

rónorodno wiedzy, 33
Ruland Kevin, 3
rzemielnik, 89
rzemioso, 31

sabotaysta, 260
Sather, 281
SCCS, 105
schemat bazy danych, konserwacja, 117
sekwencja, diagram, 175
semantyczny niezmiennik, 134
SIGPLAN, 277
Slashdot, 279
suchajcy s suchani, 41
SmallEiffel, 281
Smalltalk, 203
SMB, 286
Software Development Magazine, 277
software rot, 24
source code control system, 105
specyfikacja programu, 232
Squeak, 282
SSN, 93
strategia,

biznesowa, 164
diagnozowania bdów, 110

Stroopa efekt, 264
styl przekazu, 40
subskrypcja, 175
sukces projektu, 270
Surviving Object-Oriented Projects:

A Manager’s Guide, 278

SWIG, 284
synergia, 27
system

kontroli kodu ródowego, 104
tablic, 183
trudny w konserwacji, 158
wymagania, 31

szacowanie,

algorytmu, 193
zasobów, 193
zdroworozsdkowe, 196

szczegóowo specyfikacji, 232
szkolenia, 35
sztuka komunikacji, 42
szybko algorytmu, 193

ledzenie, 112
rodowisko,

jakie warto zna, 35
potencja, 96

T Spaces, 183, 283
tablica, 181

systemy, 183

talent, 89
Tcl, 283
tekst, 91

czytelny, 93
narzdzie, 116
wady, 92
zalety, 92
zrozumiay, 93

teoria wybitej szyby, 25
test,

ad hoc, 211
gruntowny, 260
GUI, 258
integracyjny, 254
jednostkowy, 205, 208, 254
kiedy wykona, 261
mechanizm, 210
metodyka, 257
obcienia, 256
projektu, 257
testu, 259
typ, 254
uyteczno, 256
warunki rzeczywiste, 255
wydajno, 256
zgodnoci z kontraktem, 206

tester gówny, 241

Skorowidz

W 323

testowanie, 205, 252

kultura, 212
atwe, 94
testów, 259

The Jargon File, 287
The Mythical Man Month, 278
The Object Management Group, Inc,

284

The Perl Journal, 277
thinking outside the box, 228
to, co widzisz, to to, co otrzymasz, 96
TOM, 282
TreeModel, 178
tuple space, 183
tworzenia oprogramowania,

cel, 219
metoda kaskadowa, 243

twórca narzdzi, 245

udany projekt, 28
UML, 168
uniwersalne narzdzie do pracy

z tekstem, 116

Unix, 94, 99, 278
usuga, 171
UWIN, 99, 284

vi, 280
Vim, 280
Visual SourceSafe, 285
VisualWorks, 282
Vought Eric, 3

warsztat, doskonalenie, 89
warunki rzeczywiste, 255
wczesne wykrywanie bdów, 132
wdroenie

aplikacji, 174
deskryptora, 166

Web Server Survey, 288
wze gordyjski, 227

what you see is what you get, 96
widok, 177, 179

diagnostyczny, 180

wiedza, 33, 35

akrostych, 39
dezaktualizacja, 32
pogbianie, 35
portfolio, 33
prawidowa, 36
przetwarzanie, 91

wielowtkowe programowanie, 171
wiersz polece, 96
WikiWikiWeb, 279
Windows, 99, 278
WinZip, 286
wpyw na rzeczywisto, 42
wspóbieno, 167, 171
WWW, generowanie dokumentacji, 118
wybita szyba, 25, 26
wybór edytora, 104
wydawca, 176
wyjtek, 143, 145, 150
wykraczanie mylami

poza schematy, 228

wykrywanie bdów, 132
wymagania, 218

dokumentowanie, 220
prawdziwe, 218
systemu, 31
zarzdzanie wzrostem liczby, 225

wymówki, 24
wypowied , planowanie, 39
wyraenia ledzce, 112
WYSIWYG, 96
wzorzec jzyka, 10

XEmacs, 280
xUnit, 283

Yourdon Ed, 30

324

X Skorowidz

zaangaowanie czytelników w prace

nad dokumentem, 41

zagniedanie przydziele, 149
zagroenie dla kariery, 35
zaoenia,

bdne, 115
weryfikacja, 231

zapisy zrozumiae dla ludzi, 91
zarzdzanie,

oczekiwaniami, 270
wiedz, 33
wzrostem liczby wymaga, 225
zasobami, 147

zasada izolacji obiektów, 175
zasoby

deficytowy czas, 36
szacowanie, 193
zarzdzanie, 147

zatwierdzanie procedury, 251
zdarzenie, 175

kana, 177

zdroworozsdkowe szacowanie, 196
zintegrowane rodowisko

wytwarzania, 96

zmiana

inspirowanie, 21
katalizator, 28

zmienna, 112
zrozumiay tekst, 93
zupa z

kamieni, 27, 29
aby, 29

zwizki czasowe, 167
zwyky tekst, 91

Wyszukiwarka

Podobne podstrony:
Pragmatyczny programista Od czeladnika do mistrza pragpr
Pragmatyczny programista Od czeladnika do mistrza pragpr
Pragmatyczny programista Od czeladnika do mistrza
Pragmatyczny programista Od czeladnika do mistrza
Pragmatyczny programista Od czeladnika do mistrza 2
RS 232C praktyczne programowanie Od Pascala i C do Delphi i Buildera Wydanie II
RS 232C praktyczne programowanie Od Pascala i C do Delphi i Buildera Wydanie II 2
RS 232C praktyczne programowanie Od Pascala i C do Delphi i Buildera Wydanie II
RS 232C praktyczne programowanie Od Pascala i C do Delphi i Buildera Wydanie II rs2322
RS 232C praktyczne programowanie Od Pascala i C do Delphi i Buildera Wydanie II rs2322
RS 232C praktyczne programowanie Od Pascala i C do Delphi i Buildera Wydanie II rs2322 2
RS 232C praktyczne programowanie Od Pascala i C do Delphi i Buildera Wydanie III rs2323

więcej podobnych podstron