MENU
Nasze ceny
Przeczytaj fragment on-line
Pragmatyczny programista. Od czeladnika do mistrza - ebook
Wydawnictwo:
Tłumacz:
Format:
EPUB
Data wydania:
9 lutego 2021
Pragmatyczny programista. Od czeladnika do mistrza - ebook
Wydanie jubileuszowe z okazji 20. rocznicy pierwszej edycji.
Programiści dysponują coraz lepszym, szybszym i wszechstronniejszym sprzętem. Pojawiają się nowe języki programowania i nowe paradygmaty tworzenia architektury oprogramowania. Są jednak rzeczy, które w świecie programowania pozostają stałe i niezmienne. Wciąż proces stawania się programistą wymaga od adeptów tego rzemiosła sporego wysiłku. Akt kodowania to za mało. Trzeba zmienić sposób myślenia, nawyki, zachowania i oczekiwania. Konieczne jest świadome dążenie do stosowania dobrych praktyk. Jeśli pilnuje się jakości swojej pracy i nieustannie pamięta, co i po co się robi, można w końcu stać się pragmatycznym programistą.
W drugim wydaniu tego kultowego przewodnika wskazówki techniczne harmonijnie łączą się z aspektami filozofii pragmatycznego programisty. Książka została zaktualizowana i gruntownie przejrzana, aby teraz, dwadzieścia lat po pierwszym wydaniu, ponownie pokazać, co to znaczy być nowoczesnym, pragmatycznym programistą. Poruszono tu tematy osobistej odpowiedzialności i rozwoju zawodowego, komunikacji i poznawania prawdziwych wymagań, nowoczesnych technik architektonicznych oraz coraz ważniejszych kwestii zachowania bezpieczeństwa i prywatności. Książka składa się z krótkich rozdziałów, które tworzą szeroki kontekst, dzięki czemu zyskasz wiedzę o najlepszych podejściach, unikniesz głównych pułapek, a co najważniejsze — rozwiniesz nawyki i postawy, które staną się fundamentem Twojego sukcesu zawodowego.
Dowiedz się, jak:
- pisać kod dynamiczny, elastyczny i łatwy do dostosowywania
- unikać pułapek związanych z powielaniem wiedzy
- chronić oprogramowanie przed lukami w zabezpieczeniach
- budować zespoły pragmatycznych programistów
- skutecznie testować
- wziąć odpowiedzialność za swoją pracę i karierę
Dbaj o swoje rzemiosło i myśl o tym, co robisz!
| Kategoria: | Poradniki |
| Zabezpieczenie: |
Watermark
|
| ISBN: | 978-83-289-2380-5 |
| Rozmiar pliku: | 5,1 MB |
FRAGMENT KSIĄŻKI
Opinie na temat drugiego wydania książki _Pragmatyczny programista_
Niektórzy twierdzą, że w książce _Pragmatyczny programista_ Andy i Dave schwytali błyskawicę do butelki. Jest mało prawdopodobne, aby ktoś wkrótce napisał książkę, która poruszy branżę w taki sposób, w jaki oni to zrobili. Czasami jednak błyskawica uderza dwa razy. Ta książka jest dowodem, że to możliwe. Dzięki zaktualizowanej treści pozostanie ona na szczycie list najlepszych publikacji dotyczących rozwoju oprogramowania przez 20 kolejnych lat. To miejsce jej się należy.
VM (VICKY) BRASSEUR
Dyrektor strategii open source, Juniper Networks
Jeśli chcesz, aby Twoje oprogramowanie było łatwe do aktualizacji i utrzymania, miej pod ręką egzemplarz książki _Pragmatyczny programista_. Jest ona pełna praktycznych porad, zarówno technicznych, jak i zawodowych, które będą służyły Tobie i Twoim projektom przez długie lata.
ANDREA GOULET
Dyrektor naczelny firmy Corgibytes; założyciel witryny _LegacyCode.Rocks_
_Pragmatyczny programista_ to książka, która całkowicie zmieniła tor mojej kariery w tworzeniu oprogramowania i wskazała kierunek do sukcesu. Jej lektura otworzyła mój umysł na możliwości bycia rzemieślnikiem, a nie tylko trybikiem w wielkiej maszynie. To jedna z najważniejszych książek w moim życiu.
OBIE FERNANDEZ
Autor książki _The Rails Way_
Czytelnicy, którzy sięgają po tę książkę po raz pierwszy, mogą spodziewać się fascynującego wprowadzenia do nowoczesnego świata praktyk tworzenia oprogramowania — świata, w którego kształtowaniu pierwsze wydanie tej książki odegrało ważną rolę. Czytelnicy pierwszej edycji na nowo odkryją trafne spostrzeżenia i praktyczną mądrość, dzięki którym ta publikacja stała się tak ważna. Drugie wydanie zostało fachowo uzupełnione i uaktualnione dużą ilością nowego materiału.
DAVID A. BLACK
Autor książki _The Well-Grounded Rubyist_
Mam na półce starą, papierową kopię pierwszego wydania _Pragmatycznego programisty_. Książkę tę czytałem wiele razy i stale do niej wracam. Dawno temu zmieniła ona wszystko w sposobie, w jaki podchodziłem do zawodu programisty. W nowym wydaniu zmieniło się wszystko, a jednocześnie nie zmieniło się nic: teraz czytam ją na moim iPadzie, a w przykładach kodu wykorzystano nowoczesne języki programowania, ale opisywane pojęcia, pomysły i sposoby postępowania są ponadczasowe i mają uniwersalne zastosowanie. Dwadzieścia lat po pierwszym wydaniu książka jest tak samo aktualna, jak kiedyś. Jestem szczęśliwy, że obecni i przyszli programiści będą mieć taką samą okazję uczenia się od Andy’ego i Dave’a ich głębokich spostrzeżeń, jaką miałem ja czytając pierwsze wydanie.
SANDY MAMOLI
Trener Agile, autor książki _How Self-Selection Lets People Excel_
Dwadzieścia lat temu pierwsze wydanie _Praktycznego programisty_ całkowicie zmieniło trajektorię mojej kariery. Niniejsza nowa edycja może zrobić to samo dla Was.
MIKE COHN
Autor książek _Succeeding with Agile_, _Agile Estimating and Planning_ oraz _User Stories Applied_PRZEDMOWA DO DRUGIEGO WYDANIA
W latach dziewięćdziesiątych pracowaliśmy z firmami, które miały problemy ze swoimi projektami. Mówiliśmy wszystkim to samo: może powinniście przetestować kod przed opublikowaniem? Dlaczego kod buduje się tylko na maszynie Marii? Dlaczego nikt nie zapytał o zdanie użytkowników?
Aby zaoszczędzić czas spędzony z nowymi klientami, zaczęliśmy robić notatki. Z tych notatek powstała książka _Pragmatyczny programista_. Ku naszemu zaskoczeniu okazała się strzałem w dziesiątkę. Przez 20 lat od jej wydania nadal jest popularna.
Ale 20 lat to w przypadku oprogramowania wiele życiorysów. Weźcie programistę z roku 1999 i włączcie go do współczesnego zespołu — będzie czuć się nieswojo w tym dziwnym, nowym świecie. Ale świat lat dziewięćdziesiątych jest równie obcy dla dzisiejszych programistów. Odniesienia w książce do takich technologii, jak CORBA, do narzędzi CASE oraz indeksowanych pętli byłyby w najlepszym razie jedynie ciekawostką, a co bardziej prawdopodobne, byłyby mylące.
Jednocześnie trzeba przyznać, że 20 minionych lat nie miało w ogóle wpływu na sposób zdroworozsądkowego myślenia. Być może zmieniła się technologia, ale nie zmienili się ludzie. Praktyki, które były dobre wtedy, pozostają dobre także dziś. Ten aspekt książki dobrze się starzeje.
Kiedy nadszedł czas, aby przygotować niniejsze jubileuszowe wydanie, musieliśmy podjąć decyzję. Mogliśmy przejrzeć książkę i zaktualizować technologie, do których się odwoływaliśmy. Drugim podejściem mogło być ponowne przyjęcie założeń dotyczących zalecanych praktyk w świetle dwóch dekad nowych doświadczeń.
Ostatecznie zrobiliśmy i jedno, i drugie.
W rezultacie ta książka jest czymś w rodzaju statku Tezeusza1. Mniej więcej jedna trzecia tematów w niej jest całkowicie nowa. Większość z reszty została przepisana — częściowo lub całkowicie. Naszym zamiarem było przedstawienie tematów w sposób bardziej czytelny, wyraźniejszy i — mamy nadzieję — bardziej ponadczasowy.
Podjęliśmy kilka trudnych decyzji. Usunęliśmy dodatek „Zasoby”, zarówno dlatego, że utrzymanie jego aktualności byłoby niemożliwe, jak i z tego powodu, że łatwiej jest szukać tego, czego potrzebujemy. Zreorganizowaliśmy i przepisaliśmy tematy dotyczące współbieżności. Wzięliśmy przy tym pod uwagę obecną obfitość współbieżnego sprzętu, jak i brak dobrych sposobów jego obsługi. Dodaliśmy treści uwzględniające zmianę postaw i środowisk — począwszy od ruchu Agile, do którego upowszechnienia się przyczyniliśmy, do rosnącej akceptacji idiomów programowania funkcyjnego oraz coraz większej potrzeby uwzględniania aspektów prywatności i bezpieczeństwa.
Co ciekawe, było między nami znacznie mniej dyskusji co do zawartości tego wydania, w porównaniu z pierwszą edycją. Obaj czuliśmy, że łatwiej jest teraz zidentyfikować tematy, które są ważne.
Niniejsza książka jest rezultatem naszej pracy. Życzymy przyjemnej lektury. Być może warto zacząć stosować kilka nowych praktyk. Być może stwierdzicie, że niektóre rzeczy, które proponujemy, są złe. Zachęcamy do zaangażowania się w rozwój naszego rzemiosła. Podzielcie się z nami Waszymi opiniami.
Ale najważniejsze jest to, abyście mieli z tego frajdę.
Jak zorganizowano tę książkę
Ta książka jest zbiorem stosunkowo krótkich podrozdziałów. Każdy podrozdział jest autonomiczny i dotyczy konkretnego zagadnienia. Poszczególne podrozdziały zawierają też liczne odwołania, które znacznie ułatwiają postrzeganie prezentowanych zagadnień w szerszym kontekście. Zachęcamy do swobodnej lektury tych podrozdziałów w dowolnej kolejności — tej książki nie trzeba czytać od pierwszej do ostatniej strony.
Od czasu do czasu można natrafić na ramkę oznaczoną tytułem Wskazówka nr… (na przykład Wskazówka nr 2, „Należy myśleć o tym, co się robi”). Oprócz zwracania szczególnej uwagi na pewne sugestie mamy wrażenie, że wskazówki w tej formie żyją własnym życiem — sami uwzględniamy je w codziennej pracy. Podsumowanie wszystkich wskazówek można znaleźć na wyciąganej karcie na końcu tej książki.
Wszędzie tam, gdzie to było możliwe, proponowaliśmy dodatkowe ćwiczenia i wyzwania. O ile odpowiedzi dla ćwiczeń w większości są stosunkowo proste, wyzwania wymagają głębszego zastanowienia. Aby lepiej zilustrować nasz sposób myślenia, odpowiedzi do ćwiczeń zawarliśmy w dodatku, jednak chcemy podkreślić, że tylko niewielka część tych zadań ma tylko jedno poprawne rozwiązanie. Wyzwania mogą stanowić podstawę dla dyskusji w szerszym gronie lub być tematami rozpraw zadawanych słuchaczom zaawansowanych kursów programowania.
Zamieściliśmy także krótką bibliografię, w której wymieniliśmy książki i artykuły, do których wyraźnie się odwołujemy.
Co to znaczy?
_„Kiedy używam jakiegoś słowa — powiedział Humpty Dumpty dość nonszalanckim tonem — oznacza ono tyle, co moim zdaniem ma oznaczać, ani więcej, ani mniej”._
LEWIS CARROLL, _ALICJA PO TAMTEJ STRONIE LUSTRA_
W rozmaitych miejscach tej książki można znaleźć najróżniejsze przykłady żargonu — niektóre z nich są zupełnie prawidłowymi słowami języka polskiego, którym całkiem niedawno nadano jakieś techniczne znaczenie, inne są raczej przerażającymi zlepkami wyrazów wymyślonymi przez informatyków, którzy zdają się nie zważać na piękno swojego języka. Kiedy po raz pierwszy używamy każdego z tych określeń, staramy się je zdefiniować lub przynajmniej dać jakieś wskazówki co do jego znaczenia. Mimo to jesteśmy pewni, że część niejasnych określeń niezauważenie przedostała się przez to sito, a inne, jak „obiekt” czy „relacyjna baza danych”, są na tyle popularne, że ich definiowanie byłoby po prostu nudne. W razie napotkania nieznanego terminu w żadnym razie nie należy go ignorować. Warto poświęcić trochę czasu na odnalezienie jego znaczenia, czy to w internecie, czy w innej książce informatycznej. Zachęcamy też do informowania nas o podobnych niedopatrzeniach, tak aby w następnym wydaniu nie zabrakło odpowiednich definicji.
Po tym wstępie możemy przyznać, że postanowiliśmy zrewanżować się informatykom. Istnieją doskonałe określenia stosowane w żargonie informatyków i dobrze opisujące pewne pojęcia czy zjawiska, a mimo to zdecydowaliśmy o ich ignorowaniu. Dlaczego? Ponieważ istniejący żargon zwykle jest kojarzony z konkretną dziedziną problemu lub fazą wytwarzania. Jednym z najważniejszych założeń, które przyświecało nam podczas pisania tej książki, było proponowanie możliwie uniwersalnych technik — na przykład podział na moduły ma zastosowanie w kodzie, projekcie, dokumentacji i organizacji zespołu. Kiedy próbowaliśmy używać typowego słowa żargonowego w szerszym kontekście, nasze intencje stawały się niejasne — nie mogliśmy poradzić sobie z bagażem oryginalnego kontekstu. W każdym takim przypadku postanawialiśmy zwiększyć swój wkład w upadek języka i wymyślaliśmy własne terminy.
Kod źródłowy i inne zasoby
Większość kodu źródłowego prezentowanego w tej książce pochodzi z plików źródłowych gotowych do kompilacji, które są dostępne do pobrania pod adresem:
_https://ftp.helion.pl/przyklady/prag2v.zip_
Znajdziecie także łącza do zasobów, które uważamy za przydatne, a także aktualizacje książki i wiadomości dotyczące innych przedsięwzięć związanych z książką _Pragmatyczny programista_.
Prześlij nam opinię
Będziemy wdzięczni za przesyłanie opinii na temat książki. Można wysłać do nas e-mail pod adres [email protected]_.
Podziękowania do wydania drugiego
W ciągu ostatnich 20 lat przeprowadziliśmy dosłownie tysiące ciekawych rozmów o programowaniu. Spotykaliśmy ludzi na konferencjach, na kursach, a czasami nawet na pokładach samolotów. Każda z tych rozmów poprawiła nasze zrozumienie procesu programowania i przyczyniła się do aktualizacji wprowadzonych w tym wydaniu. Dziękujemy Wam wszystkim (a jeśli jesteśmy w błędzie, dalej mówcie nam o tym).
Dziękujemy uczestnikom procesu beta książki. Wasze pytania i komentarze pomogły nam lepiej wyjaśnić niektóre zagadnienia.
Zanim doszliśmy do wersji beta, udostępniliśmy książkę kilku osobom z prośbą o opinie. Dziękujemy VM (Vicky) Brasseur, Jeffowi Langrowi i Kim Shrier za szczegółowe komentarze, a także José Valimowi i Nickowi Cuthbertowi za opinie techniczne.
Dziękujemy Ronowi Jeffriesowi za pozwolenie skorzystania z przykładu Sudoku.
Jesteśmy wdzięczni pracownikom Wydawnictwa Pearson, którzy zgodzili się, abyśmy stworzyli tę książkę na swój sposób.
Specjalne podziękowania kierujemy dla nieocenionej Janet Furlow, która w mistrzowski sposób kieruje wszystkim, co robi, i która dopilnowała, żebyśmy dotrzymali terminu.
Na koniec dziękujemy wszystkim pragmatycznym programistom, dzięki którym programowanie w ciągu ostatnich dwudziestu lat stało się lepsze dla wszystkich. Mamy nadzieję, że niniejsze wydanie zapoczątkuje kolejne takie dwadzieścia lat.
1 Jeżeli w ciągu wielu lat napraw wadliwych części wymieniono wszystkie oryginalne elementy statku, to czy w dalszym ciągu jest to ten sam statek?Z PRZEDMOWY DO PIERWSZEGO WYDANIA
Ta książka pomoże czytelnikowi zostać lepszym programistą.
Nie ma znaczenia, czy czytelnik jest wolnym strzelcem, członkiem wielkiego zespołu projektowego, czy konsultantem równocześnie współpracującym z wieloma klientami. Ta książka pomoże każdemu w lepszym wykonywaniu swojej pracy. Ta książka nie jest zbiorem teorii — koncentrujemy się raczej na tematach praktycznych, na efektywnym wykorzystywaniu własnych doświadczeń do podejmowania lepszych decyzji. Słowo _pragmatyczny_ pochodzi od łacińskiego wyrazu _pragmaticus_ („sprawny w działaniu”), który z kolei pochodzi od greckiego słowa _pragmatikós_ oznaczającego „do zrobienia”.
Ta książka jest właśnie o robieniu.
Programowanie jest rzemiosłem. W najprostszej postaci sprowadza się do zmuszania komputera do robienia tego, czego chcemy (lub czego chce użytkownik). Jako programiści jesteśmy po części słuchaczami, po części doradcami, po części tłumaczami i po części dyktatorami. Próbujemy gromadzić ulotne, trudne do sformułowania wymagania i znajdować sposoby ich wyrażania w sposób zrozumiały dla zwykłej maszyny. Staramy się tak dokumentować naszą pracę, aby inni mogli ją zrozumieć, i jednocześnie próbujemy stosować metody inżynierskie, tak aby na bazie naszych dokonań inni mogli budować własne rozwiązania. Co więcej, próbujemy robić to wszystko wbrew bezlitosnym wskazówkom zegara bieżącego projektu. Każdego dnia dokonujemy małych cudów.
To trudna praca.
Wiele osób oferuje nam pomoc. Twórcy narzędzi przekonują o niewiarygodnych możliwościach swoich produktów. Specjaliści od metodyk obiecują, że ich techniki gwarantują doskonałe efekty. Każdy twierdzi, że jego język programowania jest najlepszy i że jego system operacyjny jest pierwszą skuteczną odpowiedzią na wszystkie znane choroby.
Żadne z tych zapewnień oczywiście nie jest prawdziwe. Nie istnieją proste odpowiedzi. Nie istnieje jedno _najlepsze_ rozwiązanie, czy to w formie narzędzia, języka programowania bądź systemu operacyjnego. Mogą co najwyżej istnieć systemy, które w konkretnych okolicznościach sprawdzają się lepiej od konkurencyjnych produktów.
Właśnie tutaj potrzebny jest pragmatyzm. Nie powinniśmy wiązać swojej kariery z żadną konkretną technologią — musimy raczej dbać o stały rozwój swojej wiedzy i gromadzenie doświadczeń niezbędnych do wybierania właściwych rozwiązań w różnych sytuacjach. Nasza wiedza wynika z rozumienia podstawowych zasad informatyki, zaś nasze doświadczenie bierze się z wielu różnych praktycznych projektów. O naszej sile decyduje połączenie teorii i praktyki.
Musimy dostosowywać swoje postępowanie do bieżących okoliczności i środowiska, w którym aktualnie pracujemy. Musimy rozstrzygać względne znaczenie wszystkich czynników wpływających na projekt i wybierać najwłaściwsze rozwiązania na podstawie swoich doświadczeń. Co więcej, musimy robić to nieustannie wraz z postępem prac nad projektem. Pragmatyczni programiści doprowadzają sprawy do końca i robią to dobrze.
Kto powinien przeczytać tę książkę?
Książka jest kierowana do programistów zainteresowanych poprawą swojej efektywności i produktywności. Część programistów jest sfrustrowana wrażeniem niepełnego wykorzystania swojego potencjału. Inni programiści z zazdrością obserwują kolegów po fachu, którzy sprawiają wrażenie, jakby korzystali z narzędzi zapewniających wyższą wydajność. Jeszcze inni używają obecnie starszych technologii i chcą wiedzieć, jak nowe rozwiązania i koncepcje sprawdziłyby się w ich pracy.
Nie udajemy, że znamy wszystkie (ani nawet większość) odpowiedzi. Nie twierdzimy też, że nasze pomysły sprawdzają się we wszystkich sytuacjach. Możemy za to zagwarantować, że postępowanie według naszych zaleceń pozwoli błyskawicznie zdobywać nowe doświadczenia, podniesie produktywność programisty i umożliwi lepsze rozumienie całego procesu wytwarzania. Czytelnik będzie też pisał lepsze oprogramowanie.
Co decyduje o byciu pragmatycznym programistą?
Każdy programista jest inny, ma własne mocne strony i słabości, preferencje i uprzedzenia. Z czasem każdy programista wypracowuje także własne środowisko pracy. Wspomniane środowisko odzwierciedla indywidualne cechy programisty równie mocno jak jego hobby, ubiór czy fryzura. Pragmatyczni programiści mają jednak pewne cechy wspólne (a przynajmniej większość z wymienionych poniżej):
- SZYBKIE SPRAWDZANIE NOWINEK, BŁYSKAWICZNE DOSTOSOWYWANIE WARSZTATU. Pragmatyczni programiści instynktownie poszukują nowych technologii i technik — wprost uwielbiają eksperymentować z nowinkami. Kiedy tylko trafi w ich ręce coś nowego, potrafią błyskawicznie opanować nowe rozwiązania i zintegrować je z resztą swojej wiedzy. Ocena poszczególnych nowości wynika z doświadczenia.
- DOCIEKLIWOŚĆ. Pragmatyczni programiści zadają pytania. _To ciekawe — jak_ _to zrobiłeś? Miałeś jakieś problemy z tą biblioteką? Czym właściwie jest_ _ten BeOS, o którym tyle słyszałem? Jak zaimplementowano dowiązania_ _symboliczne?_ Pragmatyczny programista jest prawdziwym kolekcjonerem faktów — każda taka informacja może wpłynąć na jego decyzję wiele lat po jej zdobyciu.
- KRYTYCZNE MYŚLENIE. Pragmatyczni programiści rzadko akceptują otrzymywane informacje bez zapoznania się z faktami. Kiedy nasi koledzy mówią „tak to jest zrobione i już” lub kiedy jakiś producent obiecuje rozwiązanie wszystkich naszych problemów, od razu wiemy, że trzeba to dobrze sprawdzić.
- REALIZM. Pragmatyczni programiści próbują zrozumieć naturę każdego problemu, z którym muszą się zmierzyć. Realizm pozwala nam dość dobrze szacować trudność poszczególnych zadań i — tym samym — czas trwania planowanych czynności. Świadomość poziomu złożoności procesu i czasu potrzebnego do jego zakończenia pozwala nam wytrwale dążyć do celu.
- GOTOWOŚĆ DO NOWYCH WYZWAŃ. Pragmatyczni programiści starają się poznawać najróżniejsze technologie i środowiska. Robią, co w ich mocy, aby na bieżąco poznawać nowe technologie i modele wytwarzania. Nawet jeśli aktualny projekt wymaga specjalizacji w określonej dziedzinie, pragmatyczni programiści zawsze są gotowi do pracy w odmiennych obszarach i przyjmowania nowych wyzwań.
Najbardziej podstawowe cechy zostawiliśmy sobie na koniec. Te dwie cechy łączą wszystkich pragmatycznych programistów. Są na tyle proste, że można je wyrazić w formie wskazówek:
+--------------------------------------------------------------------------+
| Wskazówka nr 1 |
| |
| Należy dbać o swoje rzemiosło. |
+--------------------------------------------------------------------------+
Uważamy, że tworzenie oprogramowania nie ma najmniejszego sensu, jeśli programista nie dba o jakość swoich produktów.
+--------------------------------------------------------------------------+
| Wskazówka nr 2 |
| |
| Należy myśleć o tym, co się robi. |
+--------------------------------------------------------------------------+
Warunkiem bycia pragmatycznym programistą jest ustawiczne myślenie o tym, co się robi, przede wszystkim w trakcie tych czynności. Nie chodzi o jednorazowy audyt bieżących praktyk — powinniśmy raczej krytycznie oceniać każdą podejmowaną decyzję w codziennej pracy i podczas wszystkich czynności związanych z wytwarzaniem. Nigdy nie możemy pozwolić sobie na lot z włączonym autopilotem. Musimy stale myśleć i krytycznie oceniać swoją pracę w czasie rzeczywistym. Stare motto korporacyjne obowiązujące w firmie IBM, MYŚL!, jest też mantrą pragmatycznych programistów.
Jeśli ustawiczne ocenianie własnych decyzji wydaje nam się trudne, możemy być niemal pewni, że spełniamy warunek _realizmu_. Myślenie rzeczywiście będzie wymagało trochę cennego czasu — czasu, który już teraz jest przedmiotem poważnych nacisków. Nagrodą będzie jeszcze większe zaangażowanie w pracę, którą kochamy, świadomość świetnej znajomości coraz większej liczby zagadnień oraz przyjemne uczucie ciągłego doskonalenia umiejętności. Z czasem zainwestowany czas zwróci się z nawiązką, kiedy my i nasz zespół staniemy się bardziej efektywni, tworzony przez nas kod będzie łatwiejszy w konserwacji, a my sami będziemy tracili dużo mniej czasu na nudnych spotkaniach.
Pojedynczy pragmatycy, wielkie zespoły
Niektórzy sądzą, że w wielkich zespołach lub podczas realizacji złożonych projektów nie ma miejsca na indywidualności. „Tworzenie oprogramowania to zadanie typowo inżynierskie, którego realizacja jest niemożliwa, jeśli poszczególni członkowie zespołu sami podejmują decyzje”.
To nieprawda.
Budowa oprogramowania rzeczywiście powinna być przedsięwzięciem inżynierskim. Inżynierski charakter projektu nie wyklucza jednak rzemiosła członków zespołu projektowego. Warto przywołać przykład wielkich katedr budowanych w średniowiecznej Europie. Każda z nich wymagała tysięcy roboczolat, a budowa jednego obiektu nierzadko zajmowała wiele dekad. Lekcje z kolejnych etapów były wykorzystywane przez następne zastępy budowniczych, których osiągnięcia stopniowo przyczyniały się do rozwoju dziedziny mechaniki konstrukcji. Stolarze, kamieniarze, rzeźbiarze i szklarze byli jednak rzemieślnikami, którzy na swój sposób interpretowali wymagania inżynierskie, aby na tej podstawie stworzyć pewną całość — dzieło nieporównanie ciekawsze od czysto mechanicznego aspektu konstrukcji. O sukcesie całych projektów decydowała wiara budowniczych w znaczenie ich indywidualnego wkładu: _My, którzy wydobywamy zwykłe kamienie, zawsze musimy mieć przed oczami katedry._
W ramach ogólnej struktury projektu zawsze istnieje przestrzeń dla indywidualności i rzemiosła. Możliwości w tym względzie są szczególnie widoczne na bieżącym etapie rozwoju inżynierii oprogramowania. Nawet jeśli za sto lat nasze współczesne techniki będą wyglądały równie archaicznie co metody stosowane przez średniowiecznych budowniczych katedr w oczach współczesnych inżynierów budownictwa, nasze rzemiosło wciąż będzie doceniane.
To proces bez końca
_Turysta zwiedzający angielski Eton College zapytał ogrodnika, jak to możliwe, że trawa jest zawsze tak równo skoszona._
— _To proste — odpowiedział — wystarczy lekko podlewać codziennie rano, kosić co drugi dzień i walcować raz w tygodniu._
_— To wszystko? — zapytał zdziwiony turysta._
_— Oczywiście — odrzekł ogrodnik. — Rób tak przez 500 lat, a też będziesz_ _miał piękny trawnik._
Piękne trawniki wymagają prostych codziennych, choćby niewielkich, nakładów pracy — tak samo jest ze świetnymi programistami. Konsultanci zajmujący się zarządzaniem lubią mówić o ciągłym doskonaleniu (jap. _kaizen_). Kaizen to japoński termin określający ustawiczne wprowadzanie drobnych udoskonaleń. Uważa się, że właśnie ta filozofia jest jednym z powodów ogromnego wzrostu produktywności i jakości japońskiego przemysłu, stąd jej powszechne powielanie na całym świecie. Filozofia _kaizen_ ma zastosowanie także w przypadku jednostek. Wystarczy codziennie pracować nad doskonaleniem swoich dotychczasowych umiejętności i uzupełniać swój warsztat o nowe narzędzia. Inaczej niż w przypadku trawników w Eton, pierwsze efekty będą widoczne już w ciągu kilku dni. Po latach ze zdziwieniem odkryjemy wprost niewiarygodny wzrost swojego doświadczenia i poprawę umiejętności.
Niektórzy twierdzą, że w książce _Pragmatyczny programista_ Andy i Dave schwytali błyskawicę do butelki. Jest mało prawdopodobne, aby ktoś wkrótce napisał książkę, która poruszy branżę w taki sposób, w jaki oni to zrobili. Czasami jednak błyskawica uderza dwa razy. Ta książka jest dowodem, że to możliwe. Dzięki zaktualizowanej treści pozostanie ona na szczycie list najlepszych publikacji dotyczących rozwoju oprogramowania przez 20 kolejnych lat. To miejsce jej się należy.
VM (VICKY) BRASSEUR
Dyrektor strategii open source, Juniper Networks
Jeśli chcesz, aby Twoje oprogramowanie było łatwe do aktualizacji i utrzymania, miej pod ręką egzemplarz książki _Pragmatyczny programista_. Jest ona pełna praktycznych porad, zarówno technicznych, jak i zawodowych, które będą służyły Tobie i Twoim projektom przez długie lata.
ANDREA GOULET
Dyrektor naczelny firmy Corgibytes; założyciel witryny _LegacyCode.Rocks_
_Pragmatyczny programista_ to książka, która całkowicie zmieniła tor mojej kariery w tworzeniu oprogramowania i wskazała kierunek do sukcesu. Jej lektura otworzyła mój umysł na możliwości bycia rzemieślnikiem, a nie tylko trybikiem w wielkiej maszynie. To jedna z najważniejszych książek w moim życiu.
OBIE FERNANDEZ
Autor książki _The Rails Way_
Czytelnicy, którzy sięgają po tę książkę po raz pierwszy, mogą spodziewać się fascynującego wprowadzenia do nowoczesnego świata praktyk tworzenia oprogramowania — świata, w którego kształtowaniu pierwsze wydanie tej książki odegrało ważną rolę. Czytelnicy pierwszej edycji na nowo odkryją trafne spostrzeżenia i praktyczną mądrość, dzięki którym ta publikacja stała się tak ważna. Drugie wydanie zostało fachowo uzupełnione i uaktualnione dużą ilością nowego materiału.
DAVID A. BLACK
Autor książki _The Well-Grounded Rubyist_
Mam na półce starą, papierową kopię pierwszego wydania _Pragmatycznego programisty_. Książkę tę czytałem wiele razy i stale do niej wracam. Dawno temu zmieniła ona wszystko w sposobie, w jaki podchodziłem do zawodu programisty. W nowym wydaniu zmieniło się wszystko, a jednocześnie nie zmieniło się nic: teraz czytam ją na moim iPadzie, a w przykładach kodu wykorzystano nowoczesne języki programowania, ale opisywane pojęcia, pomysły i sposoby postępowania są ponadczasowe i mają uniwersalne zastosowanie. Dwadzieścia lat po pierwszym wydaniu książka jest tak samo aktualna, jak kiedyś. Jestem szczęśliwy, że obecni i przyszli programiści będą mieć taką samą okazję uczenia się od Andy’ego i Dave’a ich głębokich spostrzeżeń, jaką miałem ja czytając pierwsze wydanie.
SANDY MAMOLI
Trener Agile, autor książki _How Self-Selection Lets People Excel_
Dwadzieścia lat temu pierwsze wydanie _Praktycznego programisty_ całkowicie zmieniło trajektorię mojej kariery. Niniejsza nowa edycja może zrobić to samo dla Was.
MIKE COHN
Autor książek _Succeeding with Agile_, _Agile Estimating and Planning_ oraz _User Stories Applied_PRZEDMOWA DO DRUGIEGO WYDANIA
W latach dziewięćdziesiątych pracowaliśmy z firmami, które miały problemy ze swoimi projektami. Mówiliśmy wszystkim to samo: może powinniście przetestować kod przed opublikowaniem? Dlaczego kod buduje się tylko na maszynie Marii? Dlaczego nikt nie zapytał o zdanie użytkowników?
Aby zaoszczędzić czas spędzony z nowymi klientami, zaczęliśmy robić notatki. Z tych notatek powstała książka _Pragmatyczny programista_. Ku naszemu zaskoczeniu okazała się strzałem w dziesiątkę. Przez 20 lat od jej wydania nadal jest popularna.
Ale 20 lat to w przypadku oprogramowania wiele życiorysów. Weźcie programistę z roku 1999 i włączcie go do współczesnego zespołu — będzie czuć się nieswojo w tym dziwnym, nowym świecie. Ale świat lat dziewięćdziesiątych jest równie obcy dla dzisiejszych programistów. Odniesienia w książce do takich technologii, jak CORBA, do narzędzi CASE oraz indeksowanych pętli byłyby w najlepszym razie jedynie ciekawostką, a co bardziej prawdopodobne, byłyby mylące.
Jednocześnie trzeba przyznać, że 20 minionych lat nie miało w ogóle wpływu na sposób zdroworozsądkowego myślenia. Być może zmieniła się technologia, ale nie zmienili się ludzie. Praktyki, które były dobre wtedy, pozostają dobre także dziś. Ten aspekt książki dobrze się starzeje.
Kiedy nadszedł czas, aby przygotować niniejsze jubileuszowe wydanie, musieliśmy podjąć decyzję. Mogliśmy przejrzeć książkę i zaktualizować technologie, do których się odwoływaliśmy. Drugim podejściem mogło być ponowne przyjęcie założeń dotyczących zalecanych praktyk w świetle dwóch dekad nowych doświadczeń.
Ostatecznie zrobiliśmy i jedno, i drugie.
W rezultacie ta książka jest czymś w rodzaju statku Tezeusza1. Mniej więcej jedna trzecia tematów w niej jest całkowicie nowa. Większość z reszty została przepisana — częściowo lub całkowicie. Naszym zamiarem było przedstawienie tematów w sposób bardziej czytelny, wyraźniejszy i — mamy nadzieję — bardziej ponadczasowy.
Podjęliśmy kilka trudnych decyzji. Usunęliśmy dodatek „Zasoby”, zarówno dlatego, że utrzymanie jego aktualności byłoby niemożliwe, jak i z tego powodu, że łatwiej jest szukać tego, czego potrzebujemy. Zreorganizowaliśmy i przepisaliśmy tematy dotyczące współbieżności. Wzięliśmy przy tym pod uwagę obecną obfitość współbieżnego sprzętu, jak i brak dobrych sposobów jego obsługi. Dodaliśmy treści uwzględniające zmianę postaw i środowisk — począwszy od ruchu Agile, do którego upowszechnienia się przyczyniliśmy, do rosnącej akceptacji idiomów programowania funkcyjnego oraz coraz większej potrzeby uwzględniania aspektów prywatności i bezpieczeństwa.
Co ciekawe, było między nami znacznie mniej dyskusji co do zawartości tego wydania, w porównaniu z pierwszą edycją. Obaj czuliśmy, że łatwiej jest teraz zidentyfikować tematy, które są ważne.
Niniejsza książka jest rezultatem naszej pracy. Życzymy przyjemnej lektury. Być może warto zacząć stosować kilka nowych praktyk. Być może stwierdzicie, że niektóre rzeczy, które proponujemy, są złe. Zachęcamy do zaangażowania się w rozwój naszego rzemiosła. Podzielcie się z nami Waszymi opiniami.
Ale najważniejsze jest to, abyście mieli z tego frajdę.
Jak zorganizowano tę książkę
Ta książka jest zbiorem stosunkowo krótkich podrozdziałów. Każdy podrozdział jest autonomiczny i dotyczy konkretnego zagadnienia. Poszczególne podrozdziały zawierają też liczne odwołania, które znacznie ułatwiają postrzeganie prezentowanych zagadnień w szerszym kontekście. Zachęcamy do swobodnej lektury tych podrozdziałów w dowolnej kolejności — tej książki nie trzeba czytać od pierwszej do ostatniej strony.
Od czasu do czasu można natrafić na ramkę oznaczoną tytułem Wskazówka nr… (na przykład Wskazówka nr 2, „Należy myśleć o tym, co się robi”). Oprócz zwracania szczególnej uwagi na pewne sugestie mamy wrażenie, że wskazówki w tej formie żyją własnym życiem — sami uwzględniamy je w codziennej pracy. Podsumowanie wszystkich wskazówek można znaleźć na wyciąganej karcie na końcu tej książki.
Wszędzie tam, gdzie to było możliwe, proponowaliśmy dodatkowe ćwiczenia i wyzwania. O ile odpowiedzi dla ćwiczeń w większości są stosunkowo proste, wyzwania wymagają głębszego zastanowienia. Aby lepiej zilustrować nasz sposób myślenia, odpowiedzi do ćwiczeń zawarliśmy w dodatku, jednak chcemy podkreślić, że tylko niewielka część tych zadań ma tylko jedno poprawne rozwiązanie. Wyzwania mogą stanowić podstawę dla dyskusji w szerszym gronie lub być tematami rozpraw zadawanych słuchaczom zaawansowanych kursów programowania.
Zamieściliśmy także krótką bibliografię, w której wymieniliśmy książki i artykuły, do których wyraźnie się odwołujemy.
Co to znaczy?
_„Kiedy używam jakiegoś słowa — powiedział Humpty Dumpty dość nonszalanckim tonem — oznacza ono tyle, co moim zdaniem ma oznaczać, ani więcej, ani mniej”._
LEWIS CARROLL, _ALICJA PO TAMTEJ STRONIE LUSTRA_
W rozmaitych miejscach tej książki można znaleźć najróżniejsze przykłady żargonu — niektóre z nich są zupełnie prawidłowymi słowami języka polskiego, którym całkiem niedawno nadano jakieś techniczne znaczenie, inne są raczej przerażającymi zlepkami wyrazów wymyślonymi przez informatyków, którzy zdają się nie zważać na piękno swojego języka. Kiedy po raz pierwszy używamy każdego z tych określeń, staramy się je zdefiniować lub przynajmniej dać jakieś wskazówki co do jego znaczenia. Mimo to jesteśmy pewni, że część niejasnych określeń niezauważenie przedostała się przez to sito, a inne, jak „obiekt” czy „relacyjna baza danych”, są na tyle popularne, że ich definiowanie byłoby po prostu nudne. W razie napotkania nieznanego terminu w żadnym razie nie należy go ignorować. Warto poświęcić trochę czasu na odnalezienie jego znaczenia, czy to w internecie, czy w innej książce informatycznej. Zachęcamy też do informowania nas o podobnych niedopatrzeniach, tak aby w następnym wydaniu nie zabrakło odpowiednich definicji.
Po tym wstępie możemy przyznać, że postanowiliśmy zrewanżować się informatykom. Istnieją doskonałe określenia stosowane w żargonie informatyków i dobrze opisujące pewne pojęcia czy zjawiska, a mimo to zdecydowaliśmy o ich ignorowaniu. Dlaczego? Ponieważ istniejący żargon zwykle jest kojarzony z konkretną dziedziną problemu lub fazą wytwarzania. Jednym z najważniejszych założeń, które przyświecało nam podczas pisania tej książki, było proponowanie możliwie uniwersalnych technik — na przykład podział na moduły ma zastosowanie w kodzie, projekcie, dokumentacji i organizacji zespołu. Kiedy próbowaliśmy używać typowego słowa żargonowego w szerszym kontekście, nasze intencje stawały się niejasne — nie mogliśmy poradzić sobie z bagażem oryginalnego kontekstu. W każdym takim przypadku postanawialiśmy zwiększyć swój wkład w upadek języka i wymyślaliśmy własne terminy.
Kod źródłowy i inne zasoby
Większość kodu źródłowego prezentowanego w tej książce pochodzi z plików źródłowych gotowych do kompilacji, które są dostępne do pobrania pod adresem:
_https://ftp.helion.pl/przyklady/prag2v.zip_
Znajdziecie także łącza do zasobów, które uważamy za przydatne, a także aktualizacje książki i wiadomości dotyczące innych przedsięwzięć związanych z książką _Pragmatyczny programista_.
Prześlij nam opinię
Będziemy wdzięczni za przesyłanie opinii na temat książki. Można wysłać do nas e-mail pod adres [email protected]_.
Podziękowania do wydania drugiego
W ciągu ostatnich 20 lat przeprowadziliśmy dosłownie tysiące ciekawych rozmów o programowaniu. Spotykaliśmy ludzi na konferencjach, na kursach, a czasami nawet na pokładach samolotów. Każda z tych rozmów poprawiła nasze zrozumienie procesu programowania i przyczyniła się do aktualizacji wprowadzonych w tym wydaniu. Dziękujemy Wam wszystkim (a jeśli jesteśmy w błędzie, dalej mówcie nam o tym).
Dziękujemy uczestnikom procesu beta książki. Wasze pytania i komentarze pomogły nam lepiej wyjaśnić niektóre zagadnienia.
Zanim doszliśmy do wersji beta, udostępniliśmy książkę kilku osobom z prośbą o opinie. Dziękujemy VM (Vicky) Brasseur, Jeffowi Langrowi i Kim Shrier za szczegółowe komentarze, a także José Valimowi i Nickowi Cuthbertowi za opinie techniczne.
Dziękujemy Ronowi Jeffriesowi za pozwolenie skorzystania z przykładu Sudoku.
Jesteśmy wdzięczni pracownikom Wydawnictwa Pearson, którzy zgodzili się, abyśmy stworzyli tę książkę na swój sposób.
Specjalne podziękowania kierujemy dla nieocenionej Janet Furlow, która w mistrzowski sposób kieruje wszystkim, co robi, i która dopilnowała, żebyśmy dotrzymali terminu.
Na koniec dziękujemy wszystkim pragmatycznym programistom, dzięki którym programowanie w ciągu ostatnich dwudziestu lat stało się lepsze dla wszystkich. Mamy nadzieję, że niniejsze wydanie zapoczątkuje kolejne takie dwadzieścia lat.
1 Jeżeli w ciągu wielu lat napraw wadliwych części wymieniono wszystkie oryginalne elementy statku, to czy w dalszym ciągu jest to ten sam statek?Z PRZEDMOWY DO PIERWSZEGO WYDANIA
Ta książka pomoże czytelnikowi zostać lepszym programistą.
Nie ma znaczenia, czy czytelnik jest wolnym strzelcem, członkiem wielkiego zespołu projektowego, czy konsultantem równocześnie współpracującym z wieloma klientami. Ta książka pomoże każdemu w lepszym wykonywaniu swojej pracy. Ta książka nie jest zbiorem teorii — koncentrujemy się raczej na tematach praktycznych, na efektywnym wykorzystywaniu własnych doświadczeń do podejmowania lepszych decyzji. Słowo _pragmatyczny_ pochodzi od łacińskiego wyrazu _pragmaticus_ („sprawny w działaniu”), który z kolei pochodzi od greckiego słowa _pragmatikós_ oznaczającego „do zrobienia”.
Ta książka jest właśnie o robieniu.
Programowanie jest rzemiosłem. W najprostszej postaci sprowadza się do zmuszania komputera do robienia tego, czego chcemy (lub czego chce użytkownik). Jako programiści jesteśmy po części słuchaczami, po części doradcami, po części tłumaczami i po części dyktatorami. Próbujemy gromadzić ulotne, trudne do sformułowania wymagania i znajdować sposoby ich wyrażania w sposób zrozumiały dla zwykłej maszyny. Staramy się tak dokumentować naszą pracę, aby inni mogli ją zrozumieć, i jednocześnie próbujemy stosować metody inżynierskie, tak aby na bazie naszych dokonań inni mogli budować własne rozwiązania. Co więcej, próbujemy robić to wszystko wbrew bezlitosnym wskazówkom zegara bieżącego projektu. Każdego dnia dokonujemy małych cudów.
To trudna praca.
Wiele osób oferuje nam pomoc. Twórcy narzędzi przekonują o niewiarygodnych możliwościach swoich produktów. Specjaliści od metodyk obiecują, że ich techniki gwarantują doskonałe efekty. Każdy twierdzi, że jego język programowania jest najlepszy i że jego system operacyjny jest pierwszą skuteczną odpowiedzią na wszystkie znane choroby.
Żadne z tych zapewnień oczywiście nie jest prawdziwe. Nie istnieją proste odpowiedzi. Nie istnieje jedno _najlepsze_ rozwiązanie, czy to w formie narzędzia, języka programowania bądź systemu operacyjnego. Mogą co najwyżej istnieć systemy, które w konkretnych okolicznościach sprawdzają się lepiej od konkurencyjnych produktów.
Właśnie tutaj potrzebny jest pragmatyzm. Nie powinniśmy wiązać swojej kariery z żadną konkretną technologią — musimy raczej dbać o stały rozwój swojej wiedzy i gromadzenie doświadczeń niezbędnych do wybierania właściwych rozwiązań w różnych sytuacjach. Nasza wiedza wynika z rozumienia podstawowych zasad informatyki, zaś nasze doświadczenie bierze się z wielu różnych praktycznych projektów. O naszej sile decyduje połączenie teorii i praktyki.
Musimy dostosowywać swoje postępowanie do bieżących okoliczności i środowiska, w którym aktualnie pracujemy. Musimy rozstrzygać względne znaczenie wszystkich czynników wpływających na projekt i wybierać najwłaściwsze rozwiązania na podstawie swoich doświadczeń. Co więcej, musimy robić to nieustannie wraz z postępem prac nad projektem. Pragmatyczni programiści doprowadzają sprawy do końca i robią to dobrze.
Kto powinien przeczytać tę książkę?
Książka jest kierowana do programistów zainteresowanych poprawą swojej efektywności i produktywności. Część programistów jest sfrustrowana wrażeniem niepełnego wykorzystania swojego potencjału. Inni programiści z zazdrością obserwują kolegów po fachu, którzy sprawiają wrażenie, jakby korzystali z narzędzi zapewniających wyższą wydajność. Jeszcze inni używają obecnie starszych technologii i chcą wiedzieć, jak nowe rozwiązania i koncepcje sprawdziłyby się w ich pracy.
Nie udajemy, że znamy wszystkie (ani nawet większość) odpowiedzi. Nie twierdzimy też, że nasze pomysły sprawdzają się we wszystkich sytuacjach. Możemy za to zagwarantować, że postępowanie według naszych zaleceń pozwoli błyskawicznie zdobywać nowe doświadczenia, podniesie produktywność programisty i umożliwi lepsze rozumienie całego procesu wytwarzania. Czytelnik będzie też pisał lepsze oprogramowanie.
Co decyduje o byciu pragmatycznym programistą?
Każdy programista jest inny, ma własne mocne strony i słabości, preferencje i uprzedzenia. Z czasem każdy programista wypracowuje także własne środowisko pracy. Wspomniane środowisko odzwierciedla indywidualne cechy programisty równie mocno jak jego hobby, ubiór czy fryzura. Pragmatyczni programiści mają jednak pewne cechy wspólne (a przynajmniej większość z wymienionych poniżej):
- SZYBKIE SPRAWDZANIE NOWINEK, BŁYSKAWICZNE DOSTOSOWYWANIE WARSZTATU. Pragmatyczni programiści instynktownie poszukują nowych technologii i technik — wprost uwielbiają eksperymentować z nowinkami. Kiedy tylko trafi w ich ręce coś nowego, potrafią błyskawicznie opanować nowe rozwiązania i zintegrować je z resztą swojej wiedzy. Ocena poszczególnych nowości wynika z doświadczenia.
- DOCIEKLIWOŚĆ. Pragmatyczni programiści zadają pytania. _To ciekawe — jak_ _to zrobiłeś? Miałeś jakieś problemy z tą biblioteką? Czym właściwie jest_ _ten BeOS, o którym tyle słyszałem? Jak zaimplementowano dowiązania_ _symboliczne?_ Pragmatyczny programista jest prawdziwym kolekcjonerem faktów — każda taka informacja może wpłynąć na jego decyzję wiele lat po jej zdobyciu.
- KRYTYCZNE MYŚLENIE. Pragmatyczni programiści rzadko akceptują otrzymywane informacje bez zapoznania się z faktami. Kiedy nasi koledzy mówią „tak to jest zrobione i już” lub kiedy jakiś producent obiecuje rozwiązanie wszystkich naszych problemów, od razu wiemy, że trzeba to dobrze sprawdzić.
- REALIZM. Pragmatyczni programiści próbują zrozumieć naturę każdego problemu, z którym muszą się zmierzyć. Realizm pozwala nam dość dobrze szacować trudność poszczególnych zadań i — tym samym — czas trwania planowanych czynności. Świadomość poziomu złożoności procesu i czasu potrzebnego do jego zakończenia pozwala nam wytrwale dążyć do celu.
- GOTOWOŚĆ DO NOWYCH WYZWAŃ. Pragmatyczni programiści starają się poznawać najróżniejsze technologie i środowiska. Robią, co w ich mocy, aby na bieżąco poznawać nowe technologie i modele wytwarzania. Nawet jeśli aktualny projekt wymaga specjalizacji w określonej dziedzinie, pragmatyczni programiści zawsze są gotowi do pracy w odmiennych obszarach i przyjmowania nowych wyzwań.
Najbardziej podstawowe cechy zostawiliśmy sobie na koniec. Te dwie cechy łączą wszystkich pragmatycznych programistów. Są na tyle proste, że można je wyrazić w formie wskazówek:
+--------------------------------------------------------------------------+
| Wskazówka nr 1 |
| |
| Należy dbać o swoje rzemiosło. |
+--------------------------------------------------------------------------+
Uważamy, że tworzenie oprogramowania nie ma najmniejszego sensu, jeśli programista nie dba o jakość swoich produktów.
+--------------------------------------------------------------------------+
| Wskazówka nr 2 |
| |
| Należy myśleć o tym, co się robi. |
+--------------------------------------------------------------------------+
Warunkiem bycia pragmatycznym programistą jest ustawiczne myślenie o tym, co się robi, przede wszystkim w trakcie tych czynności. Nie chodzi o jednorazowy audyt bieżących praktyk — powinniśmy raczej krytycznie oceniać każdą podejmowaną decyzję w codziennej pracy i podczas wszystkich czynności związanych z wytwarzaniem. Nigdy nie możemy pozwolić sobie na lot z włączonym autopilotem. Musimy stale myśleć i krytycznie oceniać swoją pracę w czasie rzeczywistym. Stare motto korporacyjne obowiązujące w firmie IBM, MYŚL!, jest też mantrą pragmatycznych programistów.
Jeśli ustawiczne ocenianie własnych decyzji wydaje nam się trudne, możemy być niemal pewni, że spełniamy warunek _realizmu_. Myślenie rzeczywiście będzie wymagało trochę cennego czasu — czasu, który już teraz jest przedmiotem poważnych nacisków. Nagrodą będzie jeszcze większe zaangażowanie w pracę, którą kochamy, świadomość świetnej znajomości coraz większej liczby zagadnień oraz przyjemne uczucie ciągłego doskonalenia umiejętności. Z czasem zainwestowany czas zwróci się z nawiązką, kiedy my i nasz zespół staniemy się bardziej efektywni, tworzony przez nas kod będzie łatwiejszy w konserwacji, a my sami będziemy tracili dużo mniej czasu na nudnych spotkaniach.
Pojedynczy pragmatycy, wielkie zespoły
Niektórzy sądzą, że w wielkich zespołach lub podczas realizacji złożonych projektów nie ma miejsca na indywidualności. „Tworzenie oprogramowania to zadanie typowo inżynierskie, którego realizacja jest niemożliwa, jeśli poszczególni członkowie zespołu sami podejmują decyzje”.
To nieprawda.
Budowa oprogramowania rzeczywiście powinna być przedsięwzięciem inżynierskim. Inżynierski charakter projektu nie wyklucza jednak rzemiosła członków zespołu projektowego. Warto przywołać przykład wielkich katedr budowanych w średniowiecznej Europie. Każda z nich wymagała tysięcy roboczolat, a budowa jednego obiektu nierzadko zajmowała wiele dekad. Lekcje z kolejnych etapów były wykorzystywane przez następne zastępy budowniczych, których osiągnięcia stopniowo przyczyniały się do rozwoju dziedziny mechaniki konstrukcji. Stolarze, kamieniarze, rzeźbiarze i szklarze byli jednak rzemieślnikami, którzy na swój sposób interpretowali wymagania inżynierskie, aby na tej podstawie stworzyć pewną całość — dzieło nieporównanie ciekawsze od czysto mechanicznego aspektu konstrukcji. O sukcesie całych projektów decydowała wiara budowniczych w znaczenie ich indywidualnego wkładu: _My, którzy wydobywamy zwykłe kamienie, zawsze musimy mieć przed oczami katedry._
W ramach ogólnej struktury projektu zawsze istnieje przestrzeń dla indywidualności i rzemiosła. Możliwości w tym względzie są szczególnie widoczne na bieżącym etapie rozwoju inżynierii oprogramowania. Nawet jeśli za sto lat nasze współczesne techniki będą wyglądały równie archaicznie co metody stosowane przez średniowiecznych budowniczych katedr w oczach współczesnych inżynierów budownictwa, nasze rzemiosło wciąż będzie doceniane.
To proces bez końca
_Turysta zwiedzający angielski Eton College zapytał ogrodnika, jak to możliwe, że trawa jest zawsze tak równo skoszona._
— _To proste — odpowiedział — wystarczy lekko podlewać codziennie rano, kosić co drugi dzień i walcować raz w tygodniu._
_— To wszystko? — zapytał zdziwiony turysta._
_— Oczywiście — odrzekł ogrodnik. — Rób tak przez 500 lat, a też będziesz_ _miał piękny trawnik._
Piękne trawniki wymagają prostych codziennych, choćby niewielkich, nakładów pracy — tak samo jest ze świetnymi programistami. Konsultanci zajmujący się zarządzaniem lubią mówić o ciągłym doskonaleniu (jap. _kaizen_). Kaizen to japoński termin określający ustawiczne wprowadzanie drobnych udoskonaleń. Uważa się, że właśnie ta filozofia jest jednym z powodów ogromnego wzrostu produktywności i jakości japońskiego przemysłu, stąd jej powszechne powielanie na całym świecie. Filozofia _kaizen_ ma zastosowanie także w przypadku jednostek. Wystarczy codziennie pracować nad doskonaleniem swoich dotychczasowych umiejętności i uzupełniać swój warsztat o nowe narzędzia. Inaczej niż w przypadku trawników w Eton, pierwsze efekty będą widoczne już w ciągu kilku dni. Po latach ze zdziwieniem odkryjemy wprost niewiarygodny wzrost swojego doświadczenia i poprawę umiejętności.
więcej..
