Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00266 005321 13256095 na godz. na dobę w sumie
Jak stać się lepszym programistą. Przewodnik - ebook/pdf
Jak stać się lepszym programistą. Przewodnik - ebook/pdf
Autor: Liczba stron: 336
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-0242-6 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> techniki programowania
Porównaj ceny (książka, ebook (-20%), audiobook).

Podręcznik prawdziwego programisty!

Zawód programisty jak żaden inny wymaga ciągłego rozwoju, nauki i doskonalenia. Każdy dzień to nowe wyzwania, techniki programistyczne oraz kolejne linie wysokiej jakości kodu. Zastanawiasz się, co jeszcze możesz zrobić, aby stać się lepszym programistą? Chcesz zaimponować ciekawymi koncepcjami oraz wprowadzić znaczące ulepszenia w codziennej pracy? Trafiłeś na książkę, która sprawi, że Twój kod nabierze nowego blasku!

Na kolejnych stronach tej książki przeczytasz o tym, jak powinien być sformatowany kod źródłowy, jakie stosować nazewnictwo oraz jak usuwanie zbędnego kodu wpływa na jego jakość. Nauczysz się odnajdywać błędy w kodzie i pisać dobre testy. Dowiesz się także, jak w pełni korzystać z możliwości systemu kontroli wersji. Książka ta jest obowiązkową lekturą dla każdego programisty ceniącego sobie ciągły rozwój, dążenie do doskonałości oraz tworzenie świetnego kodu!

Obowiązkowa lektura każdego programisty!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

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

Gdzie kupić całą publikację:

Jak stać się lepszym programistą. Przewodnik
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: