Hunt A. - Pragmatyczny programista. Od czeladnika do mistrza.pdf

(3267 KB) Pobierz
Spis treści
S
ŁOWO
WSTĘPNE
P
RZEDMOWA
1 F
ILOZOFIA PRAGMATYCZNA
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
9
13
21
Kot zjadł mój kod
źródłowy
............................................................ 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
45
Przekleństwo powielania ................................................................ 46
Ortogonalność ............................................................................... 53
Odwracalność ............................................................................... 63
Pociski smugowe ........................................................................... 67
Prototypy i karteczki samoprzylepne .............................................. 72
Języki dziedzinowe ........................................................................ 76
Szacowanie ................................................................................... 83
3 P
ODSTAWOWE NARZĘDZIA
89
Potęga zwykłego tekstu .................................................................. 91
Powłoki ......................................................................................... 95
Efektywna edycja ........................................................................ 100
Kontrola kodu
źródłowego
........................................................... 104
Diagnozowanie ............................................................................ 107
Operowanie na tekście ................................................................ 116
Generatory kodu ......................................................................... 120
4 P
RAGMATYCZNA PARANOJA
125
Projektowanie kontraktowe .......................................................... 126
Martwe programy nie kłamią ....................................................... 138
Programowanie asertywne ........................................................... 140
Kiedy używać wyjątków ............................................................... 143
Jak zrównoważyć zasoby ............................................................. 147
8
Spis treści
5 Z
EGNIJ LUB ZŁAM
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
155
Izolacja i prawo Demeter ............................................................. 156
Metaprogramowanie .................................................................... 162
Związki czasowe .......................................................................... 167
To tylko widok ............................................................................. 174
Tablice ........................................................................................ 181
6 K
IEDY KODUJEMY
…
187
Programowanie przez koincydencję .............................................. 188
Szybkość algorytmu .................................................................... 193
Refaktoryzacja ............................................................................. 200
Kod
łatwy
do testowania .............................................................. 205
Złe kreatory ................................................................................. 213
7 P
RZED PROJEKTEM
217
Kopalnia wymagań ...................................................................... 218
Rozwiązywanie niemożliwych do rozwiązania
łamigłówek
............. 227
Nie, dopóki nie jesteś gotowy ....................................................... 230
Pułapka specyfikacji .................................................................... 232
Okręgi i strzałki ........................................................................... 235
8 P
RAGMATYCZNE PROJEKTY
239
Pragmatyczne zespoły .................................................................. 240
Wszechobecna automatyzacja ...................................................... 246
Bezlitosne testy ........................................................................... 252
Pisanie przede wszystkim ............................................................ 262
Wielkie oczekiwania ..................................................................... 269
Duma i uprzedzenie .....................................................................272
A Z
ASOBY
275
Profesjonalne społeczności ................................................................ 276
Budowa biblioteki ............................................................................. 276
Zasoby internetowe ........................................................................... 279
Bibliografia ....................................................................................... 288
B O
DPOWIEDZI DO
ĆWICZEŃ
S
KOROWIDZ
293
317
Słowo wstępne
Jako recenzent bardzo wcześnie miałem możliwość przeczytania tej książki.
Była doskonała, mimo
że
trafiła do mnie wstępna wersja. Dave Thomas i Andy
Hunt nie tylko mają sporo do powiedzenia, ale też wiedzą, jak to wyrazić. Wi-
działem, co robili w przeszłości, zatem dobrze wiedziałem,
że
i tym razem im się
uda. Poprosiłem o możliwość napisania tej przedmowy po to, aby wyjaśnić, skąd
wzięło się to przekonanie.
Krótko mówiąc, ta książka opisuje, jak programować, w sposób zrozumiały dla
każdego. Nigdy nie pomyślelibyśmy,
że
ta czy inna czynność rodzi jakieś trud-
ności. Dlaczego? Okazuje się,
że
nie wszystkie książki o programowaniu są pi-
sane przez programistów. Wiele z nich jest dziełem projektantów języków lub
dziennikarzy, którzy współpracują z tymi projektantami przy promocji ich pro-
duktów. Z tamtych książek można dowiedzieć się, jak
rozmawiać
w prezento-
wanym języku programowania, co jest oczywiście ważne, ale stanowi tylko nie-
wielką część pracy programisty.
Co jeszcze robi programista oprócz wyrażania myśli w języku programowania?
Cóż, problem jest głębszy. Większość programistów ma spore trudności z wyja-
śnieniem
istoty swojej pracy. Programowanie to praca wymagająca dbałości
o mnóstwo szczegółów, a ich
śledzenie
nie jest możliwe bez pełnego skupienia.
Mija wiele godzin, zanim pojawia się gotowy kod. Dla ludzi z zewnątrz wszystkie
te wyrażenia pojawiają się jednak dość szybko. Nieuważni obserwatorzy nierzadko
postrzegają programowanie jako zwykłe wpisywanie rozmaitych wyrażeń w języ-
ku programowania. Takie postrzeganie pracy programistów jest oczywiście błędne,
ale trudno zdać sobie z tego sprawę na podstawie typowych książek poświęco-
nych programowaniu.
W książce
Pragmatyczny programista
Dave i Andy mówią nam, jak programo-
wać, i robią to w wyjątkowo przystępny sposób. Gdzie się tego nauczyli? Czy
sami nie koncentrują się na szczegółach, jak inni programiści? Odpowiedź jest
prosta — zwracają uwagę na szczegóły tam, gdzie to było konieczne, po czym
podjęli próby usprawnienia swojej pracy.
Wyobraźmy sobie,
że
jesteśmy na jakimś spotkaniu. Być może wydaje nam się,
że
spotkanie będzie trwało w nieskończoność i
że
wolelibyśmy poświęcić ten czas
na programowanie. Dave i Andy zastanawialiby się raczej nad tym, dlaczego
w ogóle uczestniczą w tym spotkaniu, próbowaliby wymyślić inny sposób osią-
gnięcia celu tego spotkania i wreszcie analizowaliby możliwość automatyzacji
pewnych czynności, tak aby w przyszłości w ogóle nie trzeba było organizować
podobnych spotkań. Zaraz potem przystąpiliby do działania.
10
Słowo wstępne
Właśnie w ten sposób myślą Dave i Andy. Wspomniane spotkanie nie odrywałoby
ich od programowania. To dla nich tylko inna forma programowania. Co więcej,
ta metoda programowania stwarzała szerokie pole do udoskonaleń. Wiem,
że
myślą w ten sposób, choćby po lekturze ich drugiej wskazówki: Należy myśleć
o tym, co się robi.
Wystarczy wyobrazić sobie,
że
ci goście myślą w ten sposób od kilku lat. Dość
szybko mogliby wypracować całkiem spory zbiór rozwiązań. Wyobraźmy sobie
teraz,
że
stosują te rozwiązania w swojej pracy przez kolejne kilka lat, eliminując
w tym czasie pomysły, które okazały się zbyt trudne w realizacji lub które nie
zawsze prowadzą do oczekiwanych rezultatów. Cóż, to dopiero wstęp do praw-
dziwie
pragmatycznej
postawy. Wyobraźmy sobie więc,
że
poświęcają rok czy
dwa na spisanie wszystkich wypracowanych rozwiązań.
Część czytelników za-
pewne myśli teraz: ich wnioski są bezcenne.
Święta
prawda.
Autorzy mówią nam, jak sami programują. Mówią, jak programować, i robią to
w zadziwiająco zrozumiały sposób. Ostatni wniosek wymaga jednak pewnego
uzupełnienia. Niech mi wolno będzie wyjaśnić.
Autorzy bardzo uważnie unikali proponowania jakichkolwiek teorii związanych
z wytwarzaniem oprogramowania. To dobrze — w przeciwnym razie w każdym
rozdziale musieliby zbaczać na tematy uzasadniające ich teorię. Takie odchodzenie
od tematu jest już tradycją w naukach
ścisłych,
gdzie teorie ostatecznie stają się
albo uznanymi prawami, albo są porzucane (zwykle bez rozgłosu). Okazuje się
jednak,
że
w
świecie
programowania istnieje bardzo niewiele (jeśli w ogóle) praw.
W tej sytuacji rady związane z programowaniem i prezentowane w formie aspi-
rującej do praw mogą co prawda wyglądać atrakcyjnie w książkach czy arty-
kułach, ale kompletnie nie sprawdzają się w praktyce. Właśnie ten błąd po-
pełniają autorzy tak wielu książek poświęconych metodykom.
Studiowałem ten problem przez dziesięć lat i odkryłem,
że
największy potencjał
drzemie w koncepcji określanej mianem
języka wzorców.
W największym
uproszczeniu wzorzec jest pewnym rozwiązaniem, a język wzorców to system
wzajemnie wspierających się rozwiązań. Wokół poszukiwania tych systemów
powstała cała społeczność programistów.
Ta książka jest czymś więcej niż tylko zbiorem wskazówek. To coś w rodzaju
języka wzorców w skórze owcy. Mówię to, ponieważ każda wskazówka wynika
z praktycznych doświadczeń, niesie ze sobą konkretną radę i jest powiązana
z pozostałymi wskazówkami, które razem z nią tworzą pewien system. Wymie-
nione cechy umożliwiają nam opanowanie i stosowanie pewnego języka wzor-
ców. W obu przypadkach mamy więc do czynienia z tym samym modelem.
Wskazówki zawarte w tej książce można z powodzeniem stosować, ponieważ są
wystarczająco konkretne. Nie znajdziemy tu niejasnych, wymijających abstrakcji.
Dave i Andy piszą bezpośrednio do nas, tak jakby każda ich wskazówka była
zasadniczą strategią nadającą impet naszej karierze w
świecie
programowania.
Robią to w prosty sposób, opowiadają wciągającą historię, rzucają
światło
na

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin