Tytuł oryginału: Becoming a Better Programmer
Tłumaczenie: Tomasz Walczak
ISBN: 978-83-283-0239-6
© 2015 Helion S.A.
Authorized Polish translation of the English edition of Becoming a Better Programmer,
ISBN 9781491905531 © 2015 Pete Goodliffe.
This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all
rights to publish and sell the same.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording or by any information storage retrieval system,
without permission from the Publisher.
Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej
publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną,
fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje
naruszenie praw autorskich niniejszej publikacji.
Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich
właścicieli.
Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były
kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane
z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie
ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji
zawartych w książce.
Wydawnictwo HELION
ul. Kościuszki 1c, 44-100 GLIWICE
tel. 32 231 22 19, 32 230 98 63
e-mail:
helion@helion.pl
WWW:
http://helion.pl (księgarnia internetowa, katalog książek)
Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
http://helion.pl/user/opinie/jakpro
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.
Printed in Poland.
7
Spis treļci
Wprowadzenie ........................................................................................................................11
1. Troska o jakoļë kodu ................................................................................................... 15
O wäaĈciwym podejĈciu i nastawieniu do kodu
I ty.piszesz(kod); ...............................................................................19
2. Utrzymywanie pozorów ............................................................................................. 21
Prezentacja kodu — ukäad i nazwy
3. Pisz mniej kodu! ........................................................................................................... 31
Unikanie zbödnych wierszy kodu
4. Ulepszanie kodu przez jego usuwanie .......................................................................43
Identyfikowanie i usuwanie martwego kodu
5. Duch minionego kodu bazowego ............................................................................... 51
Jak siö uczyè na podstawie wäasnego starszego kodu?
6. Odnajdowanie siý w kodzie ........................................................................................59
Jak siö poruszaè po nieznanym kodzie?
7. Po uszy w bagnie .........................................................................................................69
Jak radziè sobie z chaotycznym kodem?
8. Nie ignoruj tego bĥýdu! ................................................................................................ 77
Zalecane podejĈcie do obsäugi bäödów
9. Oczekuj nieoczekiwanego ..........................................................................................83
O pisaniu niezawodnego kodu odpornego na wszelkie okolicznoĈci
10. Polowanie na bĥýdy ..................................................................................................... 87
Jak wyszukiwaè i naprawiaè bäödy?
8
_ Spis
treļci
11. Czas na testy ................................................................................................................99
Testy wykonywane przez programistów: jednostkowe, integracyjne i systemowe
12. Radzenie sobie ze zĥożonoļcié ..................................................................................113
Jak dobrze projektowaè kod i uniknñè zbödnej zäoĔonoĈci?
13. Historia dwóch systemów ......................................................................................... 123
Konsekwencje dobrych i zäych projektów
II Praktyka czyni mistrza ..................................................................137
14. Tworzenie oprogramowania to… ............................................................................. 139
Czym jest to caäe programowanie?
15. Zgodnie z reguĥami gry ..............................................................................................149
Ustalanie reguä, wedäug ktorych funkcjonuje zespóä programistyczny
16. Zachowaj prostotý ..................................................................................................... 153
Twórz proste oprogramowanie
17. Użyj gĥowy ................................................................................................................. 159
ProgramiĈci mogñ i powinni uĔywaè gäowy — nie bñdĒ gäupi!
18. Nic nie jest niezmienne .............................................................................................. 163
ēaden kod nie jest Ĉwiöty, a wszystko siö zmienia
19. Ponowne wykorzystanie kodu .................................................................................. 169
WäaĈciwe sposoby powtórnego wykorzystania kodu
20. Skuteczna kontrola wersji ......................................................................................... 175
Poprawna kontrola wersji
21. Jak umieļcië piĥký w bramce? .................................................................................... 187
Skuteczna wspóäpraca z dziaäem kontroli jakoĈci
22. Ciekawy przypadek zamrożonego kodu .................................................................. 199
ZamraĔanie kodu — czym jest i dlaczego jest niezbödne?
23. Proszý o wydanie .......................................................................................................207
Udostöpnianie oprogramowania
III Sprawy osobiste ............................................................................ 215
24. śyj tak, aby kochaë siý uczyë ..................................................................................... 217
Jak uczyè siö skutecznie?
25. Programiļci sterowani testami .................................................................................227
Programowanie jest jak prowadzenie samochodu — jak siö tego nauczyè i zdaè egzamin?
Spis treļci
_
9
26. Zagustuj w wyzwaniach ...........................................................................................233
Stawianie sobie wyzwaþ, aby zachowaè motywacjö i rozwijaè umiejötnoĈci
27. Unikaj stagnacji .........................................................................................................239
Co moĔesz zrobiè, aby Twoje umiejötnoĈci programistyczne nie staäy siö przestarzaäe?
28. Etyczny programista ..................................................................................................245
Kwestie etyczne w Ĕyciu programisty
29. Miĥoļë do jýzyków .....................................................................................................253
Poznaj wiele jözyków programowania i pokochaj te, których uĔywasz
30. Postawa programisty ................................................................................................ 261
Dbanie o zdrowie programisty: postawa ciaäa, zmöczenie oczu i morale
IV Doprowadzanie rzeczy do koħca ................................................ 269
31. Pracuj médrzej, a nie ciýżej ........................................................................................271
Skuteczna praca — unikanie zbödnych zadaþ i rozwiñzywanie wäaĈciwych problemów
32. Kiedy kod jest gotowy? ............................................................................................. 281
Zdefiniuj swoje zadania i ustal, kiedy uznasz je za wykonane
33. Tym razem na pewno býdzie dobrze… .....................................................................289
Zdejmij klapki z oczu — znajdĒ najlepszy sposób rozwiñzania problemu
V Kwestie miýdzyludzkie ................................................................ 295
34. Presja spoĥeczna ........................................................................................................ 297
Jak znaleĒè siö w zespole Ĉwietnych programistów i dobrze z nimi wspóäpracowaè?
35. Liczy siý myļlenie ......................................................................................................303
Bycie odpowiedzialnym wpäywa pozytywnie na Ciebie i Twojñ pracö
36. Komunikuj siý! ...........................................................................................................309
UmiejötnoĈci komunikowania siö dla programistów
37. Manifesty ................................................................................................................... 319
Manifesty w Ĉwiecie oprogramowania — czym sñ i do czego säuĔñ?
38. Oda do kodu ...............................................................................................................325
Historia z moraäem o nieumiejötnym zarzñdzaniu oprogramowaniem
Epilog ....................................................................................................................................329
Skorowidz .............................................................................................................................332
271
ROZDZIAĤ 31.
Pracuj médrzej, a nie ciýżej
Bitwy wygrywa siö zabijaniem i manewrowaniem. Im lepszy generaä,
tym wiökszñ wagö przykäada do manewrowania, a mniejszñ do zabijania.
— Winston Churchill
Pozwól, Ĕe opowiem pewnñ historiö. Jest ona w peäni prawdziwa. Kolega pracowaä nad kodem
interfejsu uĔytkownika i musiaä wyĈwietliè atrakcyjne, zaokrñglone strzaäki. Miaä trudnoĈci
z programowym wygenerowaniem ich za pomocñ podstawowych mechanizmów rysowania,
dlatego zasugerowaäem, aby po prostu naäoĔyä grafikö na wyĈwietlany ekran. Implementacja
takiego rozwiñzania jest znacznie äatwiejsza.
Tak wiöc kolega zabraä siö do pracy. Uruchomiä Photoshopa i zaczñä majstrowaè, i poprawiaè.
Potem jeszcze trochö pokombinowaä. Photoshop to Rolls-Royce programów graficznych, ale
nie da siö w nim szybko i äatwo narysowaè atrakcyjnej zaokrñglonej strzaäki. DoĈwiadczony
grafik prawdopodobnie przygotowaäby takñ strzaäkö w dwie minuty. Jednak mój znajomy po
prawie godzinie rysowania, wycinania, äñczenia i przesuwania nadal nie miaä dobrej zaokrñ-
glonej strzaäki.
Powiedziaä mi o tym sfrustrowany, gdy szedä zrobiè sobie szklankö herbaty.
Gdy wróciä z herbatñ, na jego komputerze czekaäa nowiutka, bäyszczñca grafika zaokrñglonej
strzaäki gotowa do uĔycia.
Jak udaäo ci siö zrobiè to tak szybko? — zapytaä.
UĔyäem wäaĈciwego narzödzia — odpowiedziaäem, robiñc unik przed latajñcñ szklankñ
z herbatñ.
Photoshop powinien byè odpowiednim narzödziem. To w tym programie wykonuje siö wiök-
szoĈè zadaþ z zakresu projektowania grafiki. Wiedziaäem jednak, Ĕe Open Office udostöpnia
wygodne narzödzie do generowania konfigurowalnych zaokrñglonych strzaäek. Utworzyäem
takñ strzaäkö w 10 sekund i przesäaäem koledze jej zrzut. Nie byäo to eleganckie rozwiñzanie,
ale zadziaäaäo.
Jaki z tego moraä?
Zawsze istnieje ryzyko, Ĕe zanadto przywiñĔesz siö do jednego narzödzia lub sposobu rozwiñ-
zywania problemów. Niezwykle äatwo jest zmarnowaè godziny pracy, brnñc w Ĉlepñ uliczkö,
podczas gdy istnieje prostsza, bardziej bezpoĈrednia droga do celu.
Jak moĔna siö przed tym ustrzec?
272
_
Rozdziaĥ 31. Pracuj médrzej, a nie ciýżej
Wybieraj pola bitwy
Aby byè produktywnym programistñ, musisz nauczyè siö pracowaè mñdrzej, a nie ciöĔej. Jed-
nñ z najwaĔniejszych cech doĈwiadczonych programistów jest nie tyle wiedza techniczna, co
umiejötnoĈè rozwiñzywania problemów i wybierania pól bitew.
Dobrzy programiĈci szybko wykonujñ zadania. Przy tym nie odstawiajñ fuszerki, co zdarza siö
strzelajñcym z biodra kowbojom Ĉwiata programowania. Dobry programista pracuje mñdrze.
Nie musi wynikaè to z tego, Ĕe jest bardziej inteligentny — po prostu wie, jak dobrze rozwiñ-
zywaè problemy. Posiada bogate doĈwiadczenie, z którego moĔe czerpaè, aby wybraè wäa-
Ĉciwe podejĈcie. Dostrzega teĔ niestandardowe rozwiñzania — potrafi zastosowaè nietypowñ
technikö, która pozwala wykonaè zadanie mniejszym nakäadem pracy. Wie, jak znaleĒè drogö
wokóä przeszkód. Potrafi wykorzystaè wiedzö do zdecydowania, jak najlepiej zainwestowaè
swój wysiäek.
Strategie walki
Oto wybrane proste techniki, które pomogñ Ci mñdrzej pracowaè.
Rozsédnie wykorzystuj gotowy kod
Nie pisz däugich fragmentów kodu samodzielnie, jeĈli moĔesz wykorzystaè istniejñcñ biblio-
tekö lub zastosowaè kod z innego Ēródäa.
Nawet jeĈli musisz zapäaciè za bibliotekö, czösto i tak jest to bardziej ekonomiczne rozwiñza-
nie niĔ samodzielne pisanie kodu. I testowanie go. I debugowanie.
KI ³
Korzystaj z istniejñcego kodu, zamiast pisaè go od podstaw. PoĈwiöè swój czas
na waĔniejsze rzeczy.
Nie poddawaj siö niechöci do kodu, który nie zostaä wymyĈlony u nas. WiökszoĈè osób uwaĔa,
Ĕe potrafi opracowaè znacznie lepsze rozwiñzanie lub utworzyè lepszñ wersjö danej aplika-
cji. Czy naprawdö tak jest? Nawet jeĈli kod nie jest zaprojektowany dokäadnie tak, jak byĈ tego
chciaä, uĔyj go. Nie musisz pisaè go od nowa, jeĈli dziaäa. JeĔeli chcesz zintegrowaè go z sys-
temem, napisz fasadö äñczñcñ system z gotowym kodem.
Przekaż problem komuļ innemu
Nie próbuj samodzielnie wymyĈlaè rozwiñzania zadania, jeĈli ktoĈ inny wie juĔ, jak to zrobiè.
MoĔliwe, Ĕe lubisz chwaliè siö dokonaniami. MoĔliwe, Ĕe chcesz nauczyè siö czegoĈ nowego.
JeĈli jednak ktoĈ moĔe Ci pomóc lub znacznie szybciej wykonaè pracö, czösto lepiej przekazaè
zadanie tej osobie.
Rób tylko to, co konieczne
Zastanów siö nad tymi bluĒnierczymi pytaniami: Czy musisz refaktoryzowaè kod? Czy musisz
przeprowadzaè testy jednostkowe?
Strategie walki
_ 273
Jestem gorñcym zwolennikiem obu tych technik, jednak czasem ich stosowanie nie jest wäaĈci-
we lub okazuje siö zäñ inwestycjñ czasu. Tak, to prawda, Ĕe refaktoryzacja i testy jednostkowe
dajñ duĔo korzyĈci, dlatego nigdy nie naleĔy z nich bezzasadnie rezygnowaè. JeĈli jednak przy-
gotowujesz prosty prototyp lub badasz moĔliwy projekt funkcjonalny obejmujñcy kod, który
i tak usuniesz, lepiej jest odäoĔyè wymienione wczeĈniej uĈwiöcone praktyki na póĒniej.
JeĈli (co godne pochwaäy) poĈwiöcasz czas na tworzenie testów jednostkowych, dobrze prze-
myĈl, które testy warto napisaè. Sztywne podejĈcie „testujemy kaĔdñ metodö” jest nierozsñd-
ne. Czösto okazuje siö, Ĕe pokrycie kodu testami jest wyĔsze, niĔ oczekiwano. Nie musisz na
przykäad testowaè kaĔdego gettera i settera w interfejsie API
1
. Skoncentruj siö w testach na
przypadkach uĔycia, a nie na metodach. Ponadto zwróè uwagö zwäaszcza na te miejsca, w któ-
rych spodziewasz siö problemów.
Wybieraj pola bitew dla testów.
Zbuduj szybki prototyp
JeĈli masz do wyboru kilka moĔliwoĈci projektowych i nie wiesz, na którñ z nich siö zdecydo-
waè, nie marnuj wielu godzin na zastanawianie siö, które podejĈcie bödzie najlepsze. Szybki
prototyp (ang. spike; jest to prototyp przeznaczony do wyrzucenia) pozwoli Ci bäyskawicznie
uzyskaè przydatne odpowiedzi.
Aby to podejĈcie dobrze zadziaäaäo, okreĈl, ile czasu chcesz poĈwiöciè na prototyp (moĔesz
zastosowaè technikö Pomodoro — http://pomodorotechnique.com/). Zakoþcz pracö, gdy ten czas
upäynie. JeĈli chcesz dokäadnie zastosowaè technikö Pomodoro, kup sobie trudny do zignoro-
wania czasomierz, który zmusi Ciö do zaprzestania pracy.
Korzystaj z narzödzi, które pomogñ Ci szybko przeĈledziè ukoþczonñ pracö (na przykäad sku-
tecznego systemu kontroli wersji).
Ustalaj priorytety
Przypisuj priorytety zadaniom. Zaczynaj od najwaĔniejszych rzeczy.
KI ³
Skoncentruj siö najpierw na najwaĔniejszych sprawach. Co jest najpilniejsze lub
najbardziej wartoĈciowe?
Potraktuj to bardzo powaĔnie. Nie zajmuj siö nieistotnymi drobiazgami — niezwykle äatwo
traciè na nie czas. Zwäaszcza gdy jedno proste zadanie zaleĔy od wykonania innej prostej pracy.
Ta wymaga wykonania innego äatwego zadanie, które z kolei… Po dwóch godzinach wrócisz
na chwilö do rzeczywistoĈci i bödziesz siö zastanawiaä, dlaczego wäaĈnie rekonfigurujesz serwer
poczty elektronicznej, skoro chciaäeĈ zmodyfikowaè metodö w klasie kontenerowej. W Ĕargo-
nie programistów takñ sytuacjö nazywa siö czasem goleniem jaka (http://catb.org/jargon/html/Y/
yak-shaving.html
).
ZauwaĔ, Ĕe wiele drobnych zadaþ, którymi siö zajmujesz, nie ma wiökszego znaczenia. Chodzi
na przykäad o sprawdzanie e-maili, wypeänianie papierów, rozmowy telefoniczne — ogólnie
1
Inny problem dotyczy tego, czy w ogóle powinieneĈ udostöpniaè gettery i settery w interfejsie API.
274
_
Rozdziaĥ 31. Pracuj médrzej, a nie ciýżej
sprawy administracyjne. Zamiast wykonywaè te czynnoĈci w trakcie dnia, kiedy przeszkadzajñ
w waĔnych zadaniach i rozpraszajñ, zajmij siö nimi wszystkimi w jednej okreĈlonej porze dnia
(lub w kilku blokach).
MoĔesz odkryè, Ĕe przydatne jest zapisywanie takich czynnoĈci na maäych listach zadaþ do
wykonania i w okreĈlonym czasie koþczenie ich tak szybko, jak to moĔliwe. Warto wtedy od-
haczaè je na liĈcie — poczucie dobrze speänionego obowiñzku jest czösto motywujñce.
Co jest naprawdý potrzebne?
Gdy otrzymasz nowe zadanie, ustal, co jest naprawdö potrzebne. Czego klient rzeczywiĈcie od
Ciebie oczekuje?
Nie twórz peänej wodotrysków wersji oprogramowania przypominajñcej Rolls-Royce’a, jeĈli
nie jest to konieczne. Nawet jeĈli klient tego zaĔñdaä, najpierw sprawdĒ, co naprawdö jest po-
trzebne. W tym celu musisz znaè kontekst, w jakim ma dziaäaè kod.
Nie chodzi tu o lenistwo. Wystöpuje ryzyko napisania za wczeĈnie zbyt duĔej iloĈci kodu.
Zgodnie z zasadñ Pareto
2
80% oczekiwanych korzyĈci moĔna uzyskaè za pomocñ 20% plano-
wanej implementacji. Czy naprawdö musisz pisaè resztö tego kodu? MoĔliwe, Ĕe uda Ci siö
lepiej spoĔytkowaè swój czas.
Jedna rzecz na raz
Rób jednñ rzecz na raz. Trudno jest skoncentrowaè siö na wiöcej niĔ jednym zadaniu (doty-
czy to zwäaszcza möĔczyzn, poniewaĔ ich mózgi gorzej sobie radzñ z wielozadaniowoĈciñ).
JeĈli spróbujesz jednoczeĈnie zajmowaè siö dwoma zadaniami, Ĕadnego z nich nie wykonasz
poprawnie. Najpierw zrób jedno, a potem zabierz siö za drugie. Wtedy szybciej ukoþczysz
oba zadania.
Pisz krótki (i prosty) kod
Dbaj o to, aby kod i projekty byäy tak niewielkie i proste, jak to moĔliwe. W przeciwnym ra-
zie utworzysz duĔo kodu, na którego konserwowanie bödziesz musiaä w przyszäoĈci poĈwiö-
caè czas i wysiäek.
KI ³
Pamiötaj o zasadzie KISS.
Bödziesz
musiaä modyfikowaè kod. Nigdy nie da siö dokäadnie przewidzieè przyszäych wyma-
gaþ. Prognozowanie przyszäoĈci do bardzo nieĈcisäa nauka. ãatwiej i mñdrzej jest od poczñt-
ku tworzyè podatny na modyfikacje kod, niĔ dodawaè obsäugö kaĔdej funkcji, która moĔe byè
w przyszäoĈci przydatna.
Niewielki, precyzyjnie wykonujñcy swoje zadania kod jest znacznie äatwiejszy do zmiany niĔ
rozbudowane projekty.
2
W wielu sytuacjach 80% efektów uzyskuje siö w wyniku 20% dziaäaþ. Wiöcej informacji na ten temat znaj-
dziesz na stronie: http://pl.wikipedia.org/wiki/Zasada_Pareto.
Strategie walki
_ 275
Nie odkĥadaj rozwiézaħ i nie kolekcjonuj problemów
Niektórych trudnych zadaþ (na przykäad integracji kodu) nie naleĔy odkäadaè na póĒniej tyl-
ko dlatego, Ĕe sñ skomplikowane. Wiele osób popeänia bäñd i odracza zadania, aby uniknñè
nieprzyjemnoĈci. To wyglñda jak wybieranie pola bitwy, prawda?
W rzeczywistoĈci lepiej zaczñè wczeĈniej i zmierzyè siö z nieprzyjemnoĈciami, gdy jeszcze sñ
niewielkie. ãatwiej jest wczeĈniej zintegrowaè niewielkie fragmenty kodu, a nastöpnie czösto
doäñczaè kolejne zmiany, niĔ przez rok pracowaè nad trzema rozbudowanymi funkcjami, a na
zakoþczenie próbowaè je poäñczyè ze sobñ.
To samo dotyczy testów jednostkowych. Pisz testy od razu, razem z kodem (lub nawet wcze-
Ĉniej). DuĔo trudniejsze i mniej produktywne jest czekanie z pisaniem testów do momentu,
gdy kod zacznie dziaäaè.
JeĈli coĈ boli, rób to czöĈciej
.
Automatyzacja
Pamiötaj starñ wskazówkö: JeĈli musisz coĈ zrobiè wiöcej niĔ raz, napisz skrypt, który bödzie robiä
to za Ciebie
.
KI ³
JeĈli czösto wykonujesz jakieĈ zadania, spraw, aby komputer robiä je za Ciebie.
Zautomatyzuj proces za pomocñ skryptu.
Automatyzacja czösto wykonywanych i Ĕmudnych zadaþ pozwoli Ci uniknñè wielu godzin
pracy. PomyĈl teĔ o prostych zadaniach, które jednak trzeba wielokrotnie powtarzaè. MoĔli-
we, Ĕe szybciej bödzie napisaè narzödzie i raz je uruchomiè, niĔ röcznie wykonywaè powta-
rzalnñ operacjö.
Automatyzacja ma teĔ dodatkowñ zaletö — pomaga w bardziej inteligentnej pracy innym. JeĈli
zdoäasz przygotowaè proces budowania uruchamiany za pomocñ jednego polecenia
zamiast
serii 15 skomplikowanych instrukcji i klikniöè przycisków
caäy zespóä bödzie mógä spraw-
niej budowaè oprogramowanie i bödzie moĔna szybciej wdroĔyè nowicjuszy w pracö.
Dlatego doĈwiadczeni programiĈci wybierajñ moĔliwe do zautomatyzowania narzödzia, na-
wet jeĈli nie zamierzajñ w danym momencie automatyzowaè Ĕadnych zadaþ. Preferuj proce-
sy pracy, które prowadzñ do generowania zwykäego tekstu lub plików poĈrednich o prostej
strukturze (na przykäad w formacie JSON lub XML). Wybieraj narzödzia majñce interfejs uru-
chamiany z poziomu wiersza poleceþ oprócz (lub zamiast) maäo elastycznego graficznego in-
terfejsu uĔytkownika.
Czasem trudno stwierdziè, czy warto pisaè skrypt do wykonywania danego zadania. Oczy-
wiĈcie, jeĈli prawdopodobnie bödziesz wykonywaä dane zadanie wielokrotnie, warto rozwa-
Ĕyè przygotowanie skryptu. JeĔeli nie jest on wyjñtkowo trudny do napisania, prawdopodob-
nie nie zmarnujesz czasu, tworzñc go.
276
_
Rozdziaĥ 31. Pracuj médrzej, a nie ciýżej
Zapobieganie bĥýdom
Znajduj bäödy jak najszybciej, aby nie marnowaè duĔo czasu na pracö nad niewäaĈciwymi rzeczami.
Aby osiñgnñè ten cel:
x
Pokazuj projekt klientom juĔ na wczesnych etapach pracy i rób to czösto. Pozwoli to szyb-
ko wykryè, Ĕe budujesz nie to, co powinieneĈ.
x
Omawiaj projekt kodu z innymi. Dziöki temu szybciej siö dowiesz, czy nie da siö lepiej
ustrukturyzowaè rozwiñzania. Nie wkäadaj wysiäku w pracö nad zäym kodem, jeĈli mo-
Ĕesz tego uniknñè.
x
Czösto recenzuj maäe, zrozumiaäe fragmenty kodu zamiast duĔych, skomplikowanych
bloków.
x
Od poczñtkuj przeprowadzaj testy jednostkowe. Zadbaj o to, aby testy jednostkowe byäy
uruchamiane czösto, co pozwoli wykryè bäödy, zanim stanñ siö problemem.
Komunikacja
Naucz siö lepiej komunikowaè i zadawaè wäaĈciwe pytania, aby jednoznacznie zrozumieè
przekaz. Nieporozumienie moĔe sprawiè, Ĕe bödziesz musiaä potem modyfikowaè kod lub
czekaè na odpowiedzi na pytania, które za póĒno zadaäeĈ. Komunikacja jest bardzo waĔna,
dlatego poĈwiöcony jest jej caäy rozdziaä „Komunikuj siö”.
Naucz siö prowadziè produktywne spotkania, aby demony kryjñce siö po kñtach sali narad
nie wyssaäy z Ciebie caäej energii.
Unikaj wypalenia
Nie pracuj po nocach, poniewaĔ moĔe to prowadziè do przemöczenia i nierealistycznych ocze-
kiwaþ ze strony przeäoĔonych. Jasno komunikuj, Ĕe wykraczasz poza swoje obowiñzki, aby
inni nie oczekiwali od Ciebie zbyt czösto takich poĈwiöceþ.
W zdrowych projektach nie trzeba czösto zostawaè w nadgodzinach.
Dobre narzýdzia
Zawsze szukaj nowych narzödzi, które usprawniñ Twój proces pracy.
Nie uzaleĔniaj siö jednak od wyszukiwania nowego oprogramowania. Nowe narzödzia czösto
majñ ostre krawödzie, o które äatwo siö pokaleczyè. Preferuj sprawdzone rozwiñzania, z któ-
rych korzysta wiele osób. Dostöpna przez wyszukiwarkö Google wspólna wiedza na temat
takich narzödzi jest bezcenna.
Wnioski
Wybieraj pola bitew
(tak, tak). Pracuj mñdrzej, a nie ciöĔej (juĔ to säyszeliĈmy).
Sñ to wyĈwiechtane powiedzenia, ale zawierajñce prawdö.
Wnioski
_ 277
OczywiĈcie nie oznacza to, Ĕe masz unikaè ciöĔkiej pracy. Chyba Ĕe chcesz, aby Ciö zwolnili. Ale
to nie jest zbyt mñdre.
Pytania
1.
Jak okreĈliè, na ile dokäadnie naleĔy przetestowaè napisany kod? Korzystasz w tym za-
kresie z wäasnego doĈwiadczenia czy z wytycznych? PomyĈl o kodzie, który napisaäeĈ
w ostatnich miesiñcach. Czy na pewno zostaä wäaĈciwie przetestowany?
2.
Jak dobrze radzisz sobie z okreĈlaniem priorytetów prac? Czy moĔesz coĈ poprawiè w tym
obszarze?
3.
Jak dbasz o to, aby jak najszybciej wykrywaè usterki? Ilu popeänionych bäödów lub prze-
róbek mogäeĈ uniknñè?
4.
Czy cierpisz na syndrom nie wynalezione u nas? Czy z definicji uwaĔasz kod innych pro-
gramistów za kiepski? Czy moĔesz poprawiè swoje nastawienie? Czy potrafisz pogodziè
siö z äñczeniem kodu innych osób z wäasnym?
5.
JeĈli pracujesz w Ĉrodowisku, w którym liczbö przepracowanych godzin ceni siö bardziej
niĔ jakoĈè kodu, jak moĔesz mñdrze pracowaè, a jednoczeĈnie nie wyjĈè na lenia?
Zobacz także
x
„Tym razem na pewno bödzie dobrze…”. Tu znajdziesz pouczajñcñ historiö — äatwo jest
pracowaè mniej mñdrze, niĔ potrafisz.
x
„Ponowne wykorzystanie kodu”. Zastosuj inteligentne podejĈcie do ponownego wyko-
rzystania kodu. Unikaj chaosu zwiñzanego z powtórzeniami, ale nie pisz wiöcej kodu, niĔ
jest to konieczne.
x
„Kiedy kod jest gotowy?”. Nie pisz wiöcej kodu, niĔ jest to niezbödne. Naucz siö okreĈlaè,
kiedy rozwiñzanie jest gotowe.
Spróbuj tego…
WskaĔ trzy rzeczy, które pomogñ Ci staè siö bardziej produktywnym programistñ. Postaraj siö
znaleĒè dwie nowe techniki, które moĔesz zaczñè stosowaè, i jeden szkodliwy nawyk. Zacznij
korzystaè z tych technik juĔ od jutra. Niech ktoĈ sprawdza, czy je stosujesz.
332
_ Skorowidz
Skorowidz
A
analiza
kodu, 64
przyczyn bäödów, 92
statyczna, 62
archeologia oprogramowania,
71, 90
architektura, 62
oprogramowania, 130
systemu Metropolis, 124
asercje, 90
atomowe zmiany, 180
atrapy, mock, 110
automatyzacja, 275
automatyzacja testów, 100
B
bäödny ukäad kodu, 22
bäödy, 55, 77, 83, 87–95, 194,
276
bäödy nieregularne, 94
brak obsäugi bäödów, 79
budowanie wydania, 209
C
cechy dobrego testu, 105
certyfikat, 230, 245
Chaotyczne Metropolis
niepotrzebne powiñzania, 126
niespójnoĈè, 125
niezrozumiaäoĈè, 124
problemy poza kodem, 127
problemy z kodem, 126
zäa architektura, 128
ciñgäa integracja, 104
ciekawe projekty, 234
cierpliwoĈè, 257
czas projektowania, 266
ê
èwiczenie oczu, 267
D
debuger, 92
debugowanie, 88, 92
decyzje projektowe, 55
dekompozycja, 282
däug techniczny, 131, 167, 203
däugoĈè okresu zamroĔenia, 203
dobra
architektura, 134
komunikacja, 314
dobre
narzödzia, 276
relacje w pracy, 195
testy, 105
dobry kod, 111, 310
dokumentacja, 62, 65
dostöp do pamiöci, 95
dostrzeganie problemów, 69
doĈwiadczenie, 299
dubler, 110
dziaä kontroli jakoĈci, 191, 196
E
efekty uboczne, 78
egzamin, 229
ekspert, 298
etyczne postawy, 247
etyka, 245, 246, 326
F
funkcja, 83
G
gotowe rozwiñzanie, 283
I
idiomy, 27, 54
ignorowanie moĔliwych
bäödów, 77
informacje
wielomodalne, 219
zwrotne, 99
informowanie o postöpach, 291
inicjowanie tworzenia
wydania, 209
interakcje
miödzy zespoäami, 189
w sieci, 94
J
jakoĈè
kodu, 15, 62, 70, 111, 305
projektu, 131
jednoznacznoĈè, 27
jözyk
C++, 254, 311
ciaäa, 313
naturalny, 311
Skorowidz
_ 333
jözyki
asemblerowe, 254
deklaratywne, 254
funkcyjne, 254
kompilowane, 253
logiczne, 254
skryptowe, 253
K
kod, 309
bazowy, 51
do testowania kodu, 100
interfejsu uĔytkownika, 45
kontenerowy, 73
podatny na bäödy, 79
pomocniczy, 45
wielowñtkowy, 94
kodeks etyczny, 250
komentarze, 36, 310
kompetencje, 220
komunikacja, 257, 276, 309,
312, 315
równolegäa, 314
w kontekĈcie zespoäów, 314
konserwowanie
kodu, 45
testów, 108
kontekst, 26, 106
kontrola
jakoĈci, 188, 191
wersji, 175
konwersacja, 312
koþczenie
pracy programu, 84
zadania, 281
kopiowanie wäasnoĈci
intelektualnej, 247
koszty niepotrzebnego kodu, 45
kóäka, 114
kwestie
miödzyludzkie, 295
prawne, 246
L
licencja GPL, 246
liczba komentarzy, 310
linie, 116
ludzie, 118
Ĥ
äatwe cele, 63
äatwoĈè
budowania kodu, 61
pobierania kodu
Ēródäowego, 60
M
manifest, 321
Craftsmanship Manifesto,
320
GNU, 320
The Agile Manifesto, 320
The Hacker Manifesto, 320
The Refactoring Manifesto,
320
manifesty uniwersalne, 319
mapa powiñzaþ, 117
martwy kod, 36, 44, 45
menedĔer, 249
mentor, 298
Miasto Projektu
praca z projektem, 133
projektowanie, 133
rozwijanie architektury,
130
spójnoĈè, 129
testy jednostkowe, 132
utrzymywanie jakoĈci, 131
zasada YAGNI, 130
znajdowanie funkcji, 129
model
Dreyfusa, 221
liniowy, 187
wodospadu, 195
modele uczenia siö, 221
modyfikowanie
dziaäania kodu, 27, 72, 163
interfejsu API, 73
ukäadu kodu, 27, 72
motywacja, 233
N
nadmiarowoĈè, 26
nakäad pracy, 272
namiastki, stub, 110
naprawianie bäödów, 89
narzödzie
Cucumber, 109
debuger, 92
Electric Fence, 91
Fit, 109
Valgrind, 92
nastawienie, 330
nazwy, 26
nazwy testów, 107
niedbaäa logika, 32
niekonieczna zäoĔonoĈè, 114
niepotrzebne
funkcje, 44
powiñzania, 126
niepotrzebny kod, 32, 43, 45
niespójnoĈè systemu, 125
nieĈwiadoma
kompetencja, 220, 227
niekompetencja, 220
niezabezpieczony kod, 79
NNW, Narzödzie Niszczenia
Wzroku, 261
O
obiekty fikcyjne, dummy, 110
obsäuga
bäödów, 77, 83, 84
odgaäözieþ, 181
odgaäözienia, 181
odgaäözienie wydania, 201, 210
odpowiedzialnoĈè, 304, 306
odraczanie decyzji
projektowych, 130
odstöpy, 25
okres zamroĔenia, 203
oprogramowanie, 139
optymalizacja, 156
organizacja
ACM, 245
BSI, 245
P
P2P, 177
pakowanie wydania, 211
pötle z informacjami
zwrotnymi, 100
pisanie kodu, 309
plik README, 65
334
_ Skorowidz
podziaä
na poäowy, 90
zadania, 282
ponowne wykorzystanie
kodu, 169–171
poprawki, 72
portfel wiedzy, 222
porzñdkowanie kodu, 64, 71
postawa programisty, 261–266
powiñzanie, 125
powstawanie bäödów
nieregularnych, 94
powtórzenia, 33
poziom
kompetencji, 220
wykorzystania pamiöci, 95
zäoĔonoĈci, 114
poznawanie kodu, 60
praca, 271
praca zespoäowa, 315
pracodawca, 249
praktyka, 63, 137
prawo Goodliffe’a, 21
presja spoäeczna, 297
prewencja, 88
prezentacja kodu, 22
priorytety, 273
problemy, 69, 326
poza kodem, 127
z kodem, 126
programowanie
ekstremalne, 43
od koþca, 282
sterowane testami, 99
w parach, 305
proste projekty
krótsze ĈcieĔki, 155
stabilnoĈè, 155
uĔytkowanie, 154
wielkoĈè, 154
zapobieganie bäödnemu
uĔyciu, 154
proste wiersze kodu, 155
prostota, 156
prototyp, 273
przechowywanie
jak najmniej danych, 178
wszystkich plików, 178
wydaþ oprogramowania,
179
przedwczesna optymalizacja,
156
przekazywanie informacji, 23
przyczyny problemów, 326
przygotowanie wydania, 207,
209
przysiöga Hipokodesa, 250
puäapki, 90
punkt
RTM, 204
zakoþczenia prac, 199
R
ramki z komentarzami, 23
raport o bäödach, 194
RC, release candidate, 200
refaktoryzacja, 34, 165, 273
regresja oprogramowania, 192
reguäa KISS, 153, 159
reguäy, 149–151, 200
rejestrowanie zdarzeþ, 90
relacje, 118
w pracy, 195
z jözykiem, 256
repozytorium, 177–179
repozytorium z kontrolñ
wersji, 182
rodzaje
dublerów, 110
testów, 101
zamraĔania, 201
rozdzielanie pracy zespoäów,
190
rozmowa z klientami, 315
rozproszona toĔsamoĈè, 118
rozwijanie
architektury, 130
kodu, 165
rozwlekäoĈè, 37
rozwój
kompetencji, 221
osobisty, 215
RTM, release to manufacture,
199
S
schematy ukäadu kodu, 52
singletony, 95, 109
spójnoĈè, 25, 125, 129
sprawdzanie pamiöci, 91
stagnacja, 239
standard pisania kodu, 26
strategia podziaäu na poäowy,
90
strategie poĈrednie, 93
struktura
katalogów, 61
kodu, 24
organizacji, 190
powiñzaþ, 117
repozytorium, 179
testów, 108
zespoäu, 133
SUT, System Under Test, 101
syndrom rozbitych szyb, 93
system
CVS, 177
kontroli wersji, 175, 180,
183
oprogramowania, 117, 123
Chaotyczne Metropolis,
124
Miasto Projektu, 128
systemy
rozproszone, 177
scentralizowane, 177
szukanie wskazówek, 60
szybki prototyp, spike, 273
Ļ
Ĉledzenie historii zmian, 176
Ĉwiadoma
kompetencja, 220, 228
niekompetencja, 220
T
TDD, test-drive development,
99, 102
technika
kopiuj-wklej, 169
TDD, 102
Skorowidz
_ 335
techniki inĔynierii, 88
test double, 110
testowanie jednostki, 109
testy, 61, 64, 99–111, 195
cechy, 105
konserwacja, 108
nazwy, 107
rodzaje, 101
struktura, 108
uruchamianie, 104
wybór platformy, 109
testy
integracyjne, 102
jednostkowe, 91, 101, 132,
191, 273
systemowe, 102
zautomatyzowane, 132, 167
tworzenie
mapy powiñzaþ, 117
tworzenie
nazw, 26
niepotrzebnego kodu, 44
oprogramowania, 140–145
portfela wiedzy, 222
systemu oprogramowania,
117
wersji, 193
wydania oprogramowania,
208
U
uczenie siö, 218, 223, 241
udostöpnianie
wersji, 191, 192
wydania, 211
oprogramowania, 199
ukäad kodu, 24, 52
uäatwianie wykrywania
bäödów, 79
umiejötnoĈci, 239
umiejötnoĈci programistyczne,
230
unikanie
bezmyĈlnoĈci, 160
bäödów, 22
zamraĔania, 204
upraszczanie relacji, 118
uruchamianie testu, 104
ustalanie
priorytetów, 273
reguä, 150
usuwanie
funkcji, 44
kodu, 43
martwego kodu, 45, 46
utrata danych, 176
utrzymywanie jakoĈci, 131
W
wñtki, 84
wersja oprogramowania, 191
alfa, 200
beta, 200
RC, 200
wiadomoĈci na temat zmian,
180
wäasnoĈè intelektualna, 247
wprowadzanie poprawek, 72,
164, 166
wskazówki, 60
wspólne wartoĈci, 258
wydanie oprogramowania,
207, 208
budowanie, 209
inicjowanie, 209
pakowanie, 211
przygotowywanie, 209
udostöpnianie, 211
wyjñtki, 78
wykorzystywanie gotowego
kodu, 272
wykrywanie bäödów, 79, 87, 89
wymagania, 62
wystarczalnoĈè, 157
wyszukiwanie martwego
kodu, 46
wytyczne dotyczñce stylu, 26
wyznaczanie standardów, 306
wyzwania, 234, 235
Z
zaangaĔowanie, 256
zadanie gotowe, 283
zaleĔnoĈci projektu, 62
zaäoĔenia, 156
zamraĔanie kodu, 199–205
zapobieganie
bäödom, 276
infekcjom, 92
zarzñdzanie däugiem
technicznym, 132
zasada, 149–151
DRY, 34, 169
KISS, 274
YAGNI, 130, 171
zbiory reguä, 150
zespóä, 187, 190, 248, 315
zäa
architektura, 128
struktura, 79
zäe
nazwy, 22
testy, 105
zäoĔonoĈè w
oprogramowaniu, 113
zäy
kod, 74, 285
projekt, 38
zmöczenie oczu, 266
zmiany przesäane do
repozytorium, 180, 181
zmienne globalne, 95, 109
zmniejszanie zäoĔonoĈci kóäek,
115
znajdowanie funkcji, 129
zwracane kody bäödów, 77
Wyszukiwarka
Podobne podstrony:
Jak stać się obcym i jak przestać nim być, Dokumenty(1)
Wychowawca czyli kto Jak stac sie wzorem do nasladowania
ćwiczenia drugie; jak stać się?rdziej kreatywnym
Jak stać się geniuszem
Czy możliwe jest stać się lepszym w ciągu jednej nocy, ! PSYCHOLOGIA PSYCHIATRIA, 0 0 NA DOBRY POCZĄ
Jak włamać się do, programowanie i nie tylko, programowanie
10 krokow BY STAC SIĘ LEPSZYM RODZICEM
Jak stać się obcym i jak przestać nim być, Dokumenty(1)
Najmocniejsze ogniwo Jak stac sie niezastapionym zawsze i wszedzie najogn 2
ćwiczenia drugie; jak stać się bardziej kreatywnym inny format
Damian Myśliwy Wskazówki jak stać się atrakcyjnym mężczyzną
Najmocniejsze ogniwo Jak stac sie niezastapionym zawsze i wszedzie
Bright Line Eating Jak stac sie szczuplym szczesliwym i wolnym czlowiekiem brliea
Maciej „Merlin” Moroz 20 Cech Samca Alfa, Czyli Jak Stać Się Najbardziej Pożądanym Facetem (Artykuł
Sekrety Seksualnej Pewnosci Siebie Jak stac sie pewnym siebie z kobietami
Jak stać się bogatym dzieckiem
więcej podobnych podstron