Mistrz programowania.
Zwiększ efektywnoS
ć
i zrób karierę
Autor: Neal Ford, David Bock
ISBN: 978-83-246-2650-2
Tytuł oryginału: The Productive Programmer
Format: 168×237, stron: 216
Poznaj efektywne narzędzia oraz mistrzowskie techniki pracy!
" Jak efektywnie zarządzać cyklem życia obiektów?
" Jak upraszczać trudne zadania przy użyciu technik metaprogramowania?
" Jak wykorzystać mądroS
ć starożytnych filozofów w programowaniu?
Każdy profesjonalista marzy o tym, aby w jak najkrótszym czasie zrobić i zarobić
jak najwięcej  dotyczy to również programistów. Autor niniejszej książki, Neal Ford,
wychodzi naprzeciw tym marzeniom i stawia tezę, że kluczem do sukcesu jest
mistrzostwo w posługiwaniu się dostępnymi narzędziami& w połączeniu z okreS
lonÄ…
metodologiÄ… pracy, opartÄ… na mÄ…droS
ci starożytnych myS
licieli. Jak uzyskać tę
wyrafinowanÄ… efektywnoS
ć i tworzyć wydajne programy, dowiesz się podręcznika,
który trzymasz w rękach.
Książka  Mistrz programowania. Zwiększ efektywnoS
ć i zrób karierę zawiera mnóstwo
bezcennych porad, dotyczących korzystania z narzędzi zwiększających produktywnoS
ć,
które możesz zastosować natychmiast! Dowiesz się z niej, jak unikać najczęstszych
pułapek oraz w jaki sposób pozbyć się czynników dekoncentrujących, zdążając
w kierunku wydajnej i efektywnej pracy. Nauczysz się tworzyć kod o jednolitym
poziomie abstrakcji, pisać testy przed napisaniem testowanego kodu, zarządzać cyklem
życia obiektów i stosować techniki metaprogramowania. Dzięki temu podręcznikowi
zdobędziesz potrzebną wiedzę i przyswoisz sobie najlepszą metodologię pracy
 a to szybko doprowadzi CiÄ™ do mistrzostwa w Twoim zawodzie.
" Tworzenie płyty startowej
" Rejestrator makr
" Makra klawiszowe
" Wyszukiwanie zaawansowane
" Widoki zakorzenione
" Automatyzacja interakcji ze stronami WWW
" Mapy danych
" Projektowanie oparte na testowaniu
" Generowanie metryk kodu
" Metaprogramowanie
Zostań najbardziej poszukiwanym i najlepiej opłacanym programistą!
Spis tre ci
Przedmowa .................................................................................................................... 7
Wst p .............................................................................................................................9
1. Wprowadzenie ............................................................................................................ 13
Dlaczego ksi ka o produktywno ci programistów 14
O czym jest ta ksi ka 15
Co dalej 17
I Mechanika ..............................................................................................19
2. Przyspieszenie ............................................................................................................. 21
Plyta startowa 22
Akceleratory 31
Makra 44
Podsumowanie 46
3. Skupienie ...................................................................................................................... 47
Pozb d si czynników rozpraszaj cych 48
Wyszukiwanie przebija nawigowanie 50
Wyszukiwanie zaawansowane 52
Widoki zakorzenione 54
Ustawianie atrybutów trwalych 56
Skróty do wszystkich zasobów projektu 57
U ywaj kilku monitorów 57
Porz dkowanie miejsca pracy na wirtualnych pulpitach 57
Podsumowanie 59
3
4. Automatyzacja ............................................................................................................ 61
Nie wynajduj ponownie kola 63
Zapisuj zasoby na dysku 63
Automatyzacja interakcji ze stronami internetowymi 64
Kanaly RSS 64
Wykorzystanie Ant do zada niezwi zanych z kompilacj 66
Wykorzystanie narz dzia Rake do codziennych zada 67
Wykorzystanie Selenium do odwiedzania stron internetowych 68
U yj basha do zliczania wyj tków 70
Zast p pliki wsadowe interpreterem Windows Power Shell 71
U ywaj Automatora z Mac OS X do usuwania starych plików 72
Oswajanie wiersza polece Subversion 73
Pisanie rozdzielacza plików SQL w j zyku Ruby 74
Argumenty za automatyzacj 75
Nie strzy jaka 76
Podsumowanie 77
5. Kanoniczno ............................................................................................................... 79
Kontrolowanie wersji 80
Kanoniczny komputer kompiluj cy 82
Po rednio 83
Niedopasowanie falowe 90
Podsumowanie 102
II Praktyka ................................................................................................105
6. Projektowanie oparte na testowaniu ....................................................................... 107
Ewolucja testów 109
7. Analiza statyczna ....................................................................................................... 117
Analiza kodu bajtowego 118
Analiza kodu ródlowego 120
Generowanie metryk kodu za pomoc programu Panopticode 122
Analiza j zyków dynamicznych 124
8. Dobry obywatel ..........................................................................................................127
amanie zasady hermetyzacji 128
Konstruktory 129
Metody statyczne 129
Zachowania patologiczne 134
4 | Spis tre ci
9. Nie b dziesz tego potrzebowa ............................................................................... 135
10. Staro ytni filozofowie ...............................................................................................141
Arystotelesowskie wlasno ci akcydentalne i istotne 142
Brzytwa Ockhama 143
Prawo Demeter 146
Tradycje programistyczne 147
11. Kwestionuj autorytety .............................................................................................. 149
W ciekle malpy 150
Plynne interfejsy 151
Antyobiekty 153
12. Metaprogramowanie ................................................................................................ 155
Java i refleksja 156
Testowanie Javy za pomoc j zyka Groovy 157
Pisanie plynnych interfejsów 158
Dok d zmierza metaprogramowanie 160
13. Metody i SLAP .............................................................................................................161
Wzorzec composed method w praktyce 162
SLAP 166
14. J zykoznawstwo ........................................................................................................ 171
Jak do tego doszlo 172
Dok d zmierzamy 175
Piramida Oli 179
15. Dobór odpowiednich narz dzi ...................................................................................181
Poszukiwanie idealnego edytora tekstu 182
Wybór wla ciwego narz dzia 186
Pozbywanie si niechcianych narz dzi 192
16. Podsumowanie  kontynuujmy dyskusj ............................................................... 195
Dodatki .................................................................................................. 197
A Elementy sk adowe ................................................................................................... 199
Skorowidz .................................................................................................................. 207
Spis tre ci | 5
ROZDZIA 7.
Analiza statyczna
117
Je li u ywasz języka programowania o statycznej kontroli typów (jak Java lub C#), masz
do dyspozycji doskonale narzędzie umo liwiaj ce znalezienie takich rodzajów blędów,
które bardzo trudno wykry za pomoc przegl dów kodu i innych standardowych technik.
Mowa o analizie statycznej  metodzie wyszukiwania w kodzie okre lonych oznak wyst -
powania nieprawidlowo ci.
Narz dzia do analizy statycznej mo na podzieli na dwie kategorie: narz dzia przeszukuj ce
skompilowane artefakty (tzn. pliki klas lub kod bajtowy) i narz dzia analizuj ce pliki ró-
dlowe. W rozdziale tym opisz przykladowe aplikacje ka dego z tych rodzajów, a jako przy-
kladowego j zyka u yj Javy, poniewa zestaw dost pnych narz dzi jest w tym przypadku
bardzo bogaty. Nale y jednak pami ta , e nie jest to technika przeznaczona wyl cznie do
stosowania w Javie. Z podobnych narz dzi mo na korzysta we wszystkich najwa niejszych
j zykach programowania o statycznej kontroli typów.
Analiza kodu bajtowego
Analizatory kodu bajtowego szukaj w kodzie ródlowym okre lonych oznak wyst powania
bl dów. Wynikaj z tego dwa wnioski: po pierwsze, niektóre j zyki programowania zostaly
ju na tyle dobrze poznane, e w ich skompilowanym kodzie bajtowym mo na wyszukiwa
cz sto wyst puj ce wzorce oznaczaj ce bl dy, a po drugie, narz dzia te nie znajduj wszyst-
kich bl dów, lecz tylko takie, których wzorce zostaly zdefiniowane. To nie oznacza, e na-
rz dzia te s malo przydatne. Niektóre znajdowane przez nie bl dy s niezwykle trudne do
wykrycia innymi metodami (tzn. przez wielogodzinne bezproduktywne wlepianie wzroku
w ekran programu diagnostycznego).
Jednym z tego typu narz dzi jest otwarty program FindBugs, b d cy projektem przygotowanym
na Uniwersytecie Maryland. Program ten mo e dziala w kilku trybach: z poziomu wiersza
polece , zadania Ant lub rodowiska graficznego. Graficzny interfejs u ytkownika aplikacji
FindBugs przedstawiono na rysunku 7.1.
FindBugs dziala w kilku obszarach, do których nale :
Poprawno
Program okre la prawdopodobie stwo wyst pienia bl du.
Zla praktyka
Wykrywa przypadki zlamania jednego z podstawowych zalece dotycz cych pisania
kodu (na przyklad przesloni cia metody equals() i jednoczesnego nieprzesloni cia
metody hashCode()).
Podejrzane elementy
Znajduje niejasne fragmenty kodu, przypadki dziwnych zastosowa , anomalie, kod slabej
jako ci.
W celu zilustrowania sposobu dzialania programu musialem znale ofiar . Padlo na otwarty
szkielet sieciowy Struts. Odkrylem kilka prawdopodobnie falszywych alarmów z kategorii
zlych praktyk, które zostaly opisane nast puj co:  W metodzie equals nie powinno przyj-
mowa si adnych zalo e dotycz cych typu jej argumentów . Zalecan praktyk definio-
wania metody equals() w Javie jest sprawdzenie rodowodu przekazywanego do niej obiektu
w celu upewnienia si , e operacja porównywania ma sens. Oto fragment kodu Struts, który
sprawia te problemy. Znajduje si on w pliku ApplicationMap.java:
118 | Rozdzia 7. Analiza statyczna
Rysunek 7.1. Graficzny klient aplikacji FindBugs
entries.add(new Map.Entry() {
public boolean equals(Object obj) {
Map.Entry entry = (Map.Entry) obj;
return ((key == null) ? (entry.getKey() == null) :
key.equals(entry.getKey())) && ((value == null) ?
(entry.getValue() == null) :
value.equals(entry.getValue()));
}
Uwa am, e to mo e by falszywy alarm, poniewa mamy tu do czynienia z definicj ano-
nimowej klasy wewn trznej, wi c autor prawdopodobnie zawsze zna typy argumentów.
Mimo wszystko co tu jest nie tak.
Poni ej przedstawiono oczywisty bl d znaleziony przez FindBugs. Ten fragment kodu znaj-
duje si w pliku IteratorGeneratorTag.java:
if (countAttr != null && countAttr.length() > 0) {
Object countObj = findValue(countAttr);
if (countObj instanceof Integer) {
count = ((Integer)countObj).intValue();
}
else if (countObj instanceof Float) {
count = ((Float)countObj).intValue();
}
else if (countObj instanceof Long) {
count = ((Long)countObj).intValue();
}
else if (countObj instanceof Double) {
count = ((Long)countObj).intValue();
}
Analiza kodu bajtowego | 119
Przyjrzyj si uwa nie ostatniemu wierszowi tego kodu. Znajduj cy si tam bl d, nale cy do
kategorii poprawno ci programu FindBugs, zostal okre lony jako  niemo liwe rzutowanie .
Ostatni wiersz powy szego listingu zawsze b dzie powodowal wyj tek rzutowania klas.
W istocie nie ma takiej sytuacji, w której uruchomienie tego kodu nie wywola problemu.
Programista sprawdza, czy obiekt o nazwie countObj jest typu Double, i od razu rzutuje go
na typ Long. Aby dowiedzie si , jak to si stalo, wystarczy spojrze na znajduj c si wy ej
instrukcj if: to jest bl d kopiowania i wklejania. Tego typu bl d trudno jest znale metod
przegl dania kodu  bardzo latwo go przeoczy . Najwyra niej w bazie kodu Struts nie ma
testu jednostkowego pokrywaj cego ten wiersz kodu, poniewa w przeciwnym razie na-
tychmiast by go wykryto. Co gorsza, ten bl d wyst puje w trzech miejscach kodu Struts: we
wspomnianym pliku IteratorGeneratorTag.java i dwa razy w pliku SubsetIteratorTag.java. Powód?
Nietrudno zgadn . Kod ten zostal skopiowany i wklejony we wszystkich tych trzech miejscach
(FindBugs tego nie wykryl, sam zauwa ylem, e te fragmenty s do siebie podejrzanie podobne).
Dzi ki mo liwo ci zautomatyzowania uruchamiania programu FindBugs przez Ant lub Maven
jako cz ci procesu kompilacji aplikacja ta pelni funkcj bardzo taniej polisy ubezpieczenio-
wej na wypadek wyst pienia rozpoznawanych przez ni bl dów. Oczywi cie nie mo na za-
gwarantowa w ten sposób, e kod b dzie calkowicie wolny od bl dów (i nie zwalnia to z obo-
wi zku pisania testów jednostkowych), ale program ten mo e Ci uratowa przed paroma
nieprzyjemnymi wpadkami. Potrafi on nawet znale takie bl dy, które trudno wykry w testach
jednostkowych, na przyklad problemy z synchronizacj w tków.
Narz dzia do analizy statycznej stanowi latwy sposób weryfikacji.
Analiza kodu ród owego
Narz dzia do analizy kodu ródlowego przeszukuj kod ródlowy w celu znalezienia okre-
lonych oznak wyst powania bl dów. W zaprezentowanym przykladzie u ylem otwartego
narz dzia Javy o nazwie PMD. Program ten dziala z poziomu wiersza polece , Ant oraz ma
wtyczki do wszystkich najwa niejszych rodowisk programistycznych. Aplikacja ta znajduje
nast puj ce typy nieprawidlowo ci:
Potencjalne blędy
Na przyklad puste bloki try& catch.
Martwy kod
Nieu ywane zmienne lokalne, parametry i zmienne prywatne.
Nieoptymalny kod
Marnotrawne u ycie la cuchów.
Nadmiernie skomplikowane wyra enia
Wielokrotne u ycie kodu spowodowane kopiowaniem i wklejaniem.
Duplikaty kodu (obslugiwane przez pomocnicze narzędzie o nazwie CPD)
Wielokrotne u ycie kodu spowodowane kopiowaniem i wklejaniem.
120 | Rozdzia 7. Analiza statyczna
PMD mo na okre li jako co pomi dzy zwyklym narz dziem do sprawdzania stylu (takim
jak CheckStyle, które weryfikuje, czy kod zostal napisany zgodnie z wytycznymi dotycz cymi
stylu, na przyklad czy zostaly zastosowane odpowiednie wci cia) a programem FindBugs,
który analizuje kod bajtowy. Rodzaje bl dów, w wykrywaniu których specjalizuje si PMD,
poka na przykladzie metody napisanej w j zyku Java:
private void insertLineItems(ShoppingCart cart, int orderKey) {
Iterator it = cart.getItemList().iterator();
while (it.hasNext()) {
CartItem ci = (CartItem) it.next();
addLineItem(connection, orderKey, ci.getProduct().getId(),
ci.getQuantity());
}
}
PMD poinformuje, e metod t mo na zoptymalizowa przez dodanie do pierwszego
parametru (ShoppingCart cart) modyfikatora final. Dzi ki zastosowaniu si do tej rady
mo na zmusi kompilator do wykonania za nas wi kszej ilo ci pracy. Poniewa w Javie
wszystkie obiekty s przekazywane przez warto , nie mo na zmiennej cart przypisa refe-
rencji do nowego obiektu wewn trz tej metody, a próba zrobienia tego spowoduje wyst pienie
bl du. PMD oferuje kilka tego typu wskazówek, które pomagaj zoptymalizowa dzialanie
ró nych narz dzi (na przyklad kompilatora).
Program PMD ma równie funkcj wykrywania podejrzanie wygl daj cych skopiowanych
i wklejonych fragmentów kodu (jak wcze niej pokazany kod Struts) o nazwie CPD (ang. Cut-Paste
Detector). Interfejs u ytkownika CPD zostal zbudowany przy u yciu biblioteki Swing. S w nim
wy wietlane stan i problematyczny fragment kodu (rysunek 7.2). Sposób jego dzialania oczy-
wi cie równie jest zwi zany z zasad DRY, któr opisalem w rozdziale 5.
Rysunek 7.2. Narz dzie Cut and Paste Detector programu PMD
Analiza kodu ród owego | 121
Wi kszo podobnych narz dzi do analizy kodu ródlowego ma API daj ce si dostosowa
do indywidualnych potrzeb, w którym mo na utworzy wlasne zestawy regul (takie API ma
zarówno FindBugs, jak i PMD). Wi kszo z nich oferuje ponadto tryb interaktywny i, co
jeszcze wa niejsze, pozwala uruchamia si jako cz zautomatyzowanych procesów, na
przyklad ci glej integracji. Uruchamianie tych narz dzi przed ka dym wyslaniem plików do
repozytorium jest bardzo prostym sposobem na unikni cie typowych bl dów. Kto zadal
sobie trud zidentyfikowania bl dów, a Ty mo esz z tego skorzysta .
Generowanie metryk kodu
za pomoc programu Panopticode
Zagadnienia zwi zane z metrykami kodu wykraczaj poza zakres tematyczny tej ksi ki, ale
produktywno w ich generowaniu nie. Je li chodzi o j zyki o statycznej kontroli typów (jak
Java i C#) jestem wielkim zwolennikiem ci glego gromadzenia metryk, aby mie pewno , e
problem zostanie rozwi zany mo liwie jak najszybciej. Oznacza to, e zwykle mam caly ze-
staw narz dzi do mierzenia jako ci kodu (wl cznie z programami FindBugs i PMD/CPD),
które uruchamiam w ramach procesu ci glej integracji.
Konfigurowanie tych wszystkich programów w ka dym projekcie jest klopotliwe. Podobnie
jak w przypadku programu Buildix (zobacz podrozdzial  Nie wynajduj ponownie kola w roz-
dziale 4.) chcialbym mie wst pnie skonfigurowan cal infrastruktur . W tym wla nie naj-
lepszy jest Panopticode.
Podobny problem mial kiedy jeden z moich kolegów (Julias Shaw), ale on zamiast narzeka
jak ja, wzi l si do roboty. Panopticode1 to program typu open source zawieraj cy mnóstwo
wst pnie skonfigurowanych narz dzi do generowania metryk kodu. Jego j dro stanowi plik
kompilacji Ant, zawieraj cy wiele projektów open source i ich wst pnie skonfigurowanych
plików JAR. Wystarczy poda cie k do swoich plików ródlowych, cie k do bibliotek
(innymi slowy, cie k do wszystkich plików JAR potrzebnych do skompilowania projektu)
oraz katalog testów, a nast pnie uruchomi plik kompilacyjny Panopticode. Program zajmie
si reszt .
Emma
Narz dzie typu open source do mierzenia pokrycia kodu testami (zobacz podrozdzial
 Pokrycie kodu w rozdziale 6.). Zmieniaj c jeden wiersz w pliku kompilacji Panoptico-
de, mo na z tego narz dzia przel czy si na narz dzie Cobertura (kolejny program open
source do mierzenia pokrycia kodu ródlowego Javy).
CheckStyle
Otwarty weryfikator stylu kodu. Mo na utworzy dostosowane do wlasnych potrzeb
zestawy regul za pomoc jednego wpisu w pliku kompilacji Panopticode.
JDepend
Otwarte narz dzie zbieraj ce metryki numeryczne na poziomie pakietów.
1
Do pobrania pod adresem http://www.panopticode.org.
122 | Rozdzia 7. Analiza statyczna
JavaNCSS
Otwarte narz dzie do mierzenia zlo ono ci cyklomatycznej (zobacz podrozdzial  Zlo o-
no cyklomatyczna w rozdziale 6.).
Simian
Komercyjny program slu cy do znajdowania powtarzaj cych si fragmentów kodu.
Wersj dost pn w Panopticode mo na bezplatnie testowa przez 15 dni. Po uplywie tego
czasu nale y usun program lub za niego zaplaci . Planowane jest umo liwienie jego
wymiany na CPD.
Panopticode Aggregator
Narz dzie przedstawiaj ce raporty wszystkich narz dzi Panopticode w formie tekstowej
i graficznej (w postaci schematów).
Po uruchomieniu Panopticode przez jaki czas prze uwa kod ródlowy, a nast pnie wypluwa
raport zawieraj cy informacje o jego jako ci. Program ten tworzy tak e bardzo ladne sche-
maty w postaci zaawansowanych obrazów w formacie SVG (wi kszo przegl darek potrafi
wy wietla tego typu grafik ). Schematy te maj dwie zalety. Pierwsz z nich jest to, e sta-
nowi graficzny obraz warto ci okre lonej metryki. Na przyklad na rysunku 7.3 zostala
przedstawiona zlo ono cyklomatyczna projektu CruiseControl. Zacienione obszary repre-
zentuj ró ne przedzialy warto ci dla okre lonej metody. Grube biale linie oznaczaj granice
pakietów, a cienkie linie  granice klas. Ka de pole odpowiada jednej metodzie.
Drug zalet schematów jest ich interaktywno . To nie jest tylko ladny obrazek  to obra-
zek interaktywny. Je li rysunek ten zostanie wy wietlony w przegl darce internetowej, klik-
ni cie dowolnego pola spowoduje wy wietlenie po prawej stronie metryk odpowiadaj cej mu
metody. Schematy te umo liwiaj przeanalizowanie kodu w celu znalezienia metod i klas,
które sprawiaj problemy.
Panopticode wy wiadcza programi cie dwie bardzo istotne przyslugi. Po pierwsze, nie trze-
ba w ka dym projekcie ci gle konfigurowa tych samych rzeczy. W typowym projekcie kon-
figuracja programu trwa nie wi cej ni 5 minut. Po drugie, program umo liwia tworzenie
schematów, które slu jako agregatory informacji. W projektach zwinnych agregator infor-
macji (ang. information radiator) to reprezentacja stanu projektu umieszczona w jakim wi-
docznym miejscu (na przyklad w pobli u ekspresu do kawy). Dzi ki niemu czlonkowie
zespolu nie musz otwiera adnych zal czników, aby sprawdzi stan projektu, poniewa
mog to zrobi , id c po kaw .
Jeden z rodzajów schematów, jakie mo na tworzy za pomoc Panopticode, to ilustracje po-
krycia kodu (zobacz podrozdzial  Pokrycie kodu w rozdziale 6.). Je li metryka wygl da jak
wielka czarna plama, nie jest dobrze. Zwi kszanie pokrycia kodu zacznij od znalezienia naj-
wi kszej mo liwej kolorowej drukarki i wydrukuj na niej swój schemat (wla ciwie za pierw-
szym razem zwykle wystarcza bialo-czarna, poniewa i tak wydruk jest caly czarny). Powie
ten wydruk w widocznym miejscu. Po zako czeniu jakiego wa nego etapu pisania testów
wydrukuj nowy schemat i powie go obok poprzedniego. Jest on bardzo skutecznym moty-
watorem wszystkich czlonków zespolu  nikt nie chce by wiadkiem ponownego pogr a-
nia si projektu w ciemno ci. Jest to tak e dobry sposób na pokazanie kierownikowi, e po-
krycie kodu testami jest coraz wi ksze. Kierownicy lubi takie obrazy z rozmachem, a ten na
dodatek zawiera u yteczne informacje!
Generowanie metryk kodu za pomoc programu Panopticode | 123
Czytaj dalej...