Do tej książki zbierałem się już w zeszłym roku. Coś w okolicach lipca. Niestety pierwsze podejście skończyło się niepowodzeniem. Nie wiem czy to przez upalną pogodę czy przez oczekiwanie na narodziny syna, ale nie mogłem wtedy przebrnąć przez wstęp. Po czasie postanowiłem spróbować ponownie. Tym bardziej po opublikowaniu postanowienia noworocznego, dotyczącego czytania większej ilości książek. Rzuciłem okiem na mój regał i "Praktyka czyni mistrza" wyglądała na taką do połknięcia w kilka dni - szacując po szerokości grzbietu. Drugie podejście do tej książki to był strzał w dziesiątkę!

Zaczynamy

Wstęp? Raczej standardowy. Mowa wstępna, opis struktury i odpowiedź na pytanie "dla kogo jest ta książka?". Autorzy piszą, że odbiorcą docelowym jest młody programista, stawiający swoje pierwsze kroki w rzemiośle programowania. Zaznaczają też jednak, że bardziej doświadczone osoby również znajdą coś dla siebie. Dalej czytamy o tym jak autorzy widzą to, jak powinno się czytać ich książkę. Wynika to pośrednio ze struktury. To nie jest proza, którą czyta się od deski do deski. Książka podzielona jest na 7 rozdziałów, w których znajdziemy opisy wzorców. Nie są to w żadnym wypadku wzorce czysto techniczne - tyczące się kodu. Raczej wzorce dotyczące nauki, popychające do dalszego rozwoju, wskazujące drogę. W związku ze strukturą, autorzy proponują niekonwencjonalne podejście do czytania - na wyrywki. Co to znaczy? Znaczy to, że można sobie otworzyć książkę na dowolnie wybranym wzorcu i po prostu zacząć czytać. Ja natomiast postanowiłem pójść na przekór i przeczytałem książkę od A do Z ;)

Tak na prawdę oprócz tradycyjnego wstępu mamy też rozdział pierwszy zatytułowany "Wprowadzenie". W rozdziale tym znajdziemy informacje o tym czym jest rzemiosło (nie tylko programowania). Czym różni się uczeń od czeladnika i mistrza. Dowiemy się także czym jest wzorzec nauki i skąd wzięły się wzorce opisane w książce.

Wzorce, wzorce i jeszcze raz wzorce

W rozdziałach 2-6 znajdziemy już samo "mięso" - czyli opis wzorców. Każdy z nich opisany jest poprzez:

  • nakreślenie kontekstu,
  • opis problemu,
  • przedstawienie rozwiązania,
  • przykłady działań,
  • listę powiązanych wzorców.

Taki schemat powtarza się dla każdego wzorca.

Dla przykładu...kontekst:

Zaczynasz sobie zdawać sprawę, jak mało wiesz, lub podjąłeś się nowego wyzwania i coś nie idzie zbyt dobrze. Albo jedno i drugie.

Problem:

Poznając rozległe obszary swojej niewiedzy, czujesz się przytłoczony.

Dalej mamy rozległy opis rozwiązania wzorca "Wycofaj Się Do Swoich Kompetencji". Oraz przykładowe działanie:

Wybierz coś samowystarczalnego, co znasz już bardzo dobrze, i zaimplementuj to ponownie. Ade lubi na przykład implementować algorytmy buforowania, ponieważ mogą one być zarówno trywialne, jak i wysoce złożone. Pozwalają mu one również wzmocnić jego intuicję dotyczącą projektowania i algorytmicznej złożoności.

Zauważyliście jak przy opisie wzorca napisałem wszystko z dużych liter? Taka koncepcja :) Wiele wzorców jest powiązanych ze sobą. W niektórych kryją się pułapki, na które rozwiązanie przychodzi z innym wzorcem. Moim zdaniem jest to bardzo ciekawy zabieg stylistyczny i pomaga łatwo odróżnić dowolne stwierdzenie od nazwy wzorca.

Czyli wystarczy przeczytać i zaimplementować?

No nie do końca. Autorzy na wstępie zaznaczają, że ślepe implementowanie wszystkich wzorców z książki może nie dać zamierzonego efektu. Niektóre z wzorców należy wykorzystywać tylko czasowo. Na przykład opisany wyżej wzorzec "Wycofaj Się Do Swoich Kompetencji". Gdybyśmy za długo pozostawali w strefie komfortu to jest mała szansa, że w stabilnym tempie będziemy poznawać nowe rzeczy i rozwijać się jako programiści. Dlatego do każdego wzorca należy podejść z głową.

Czy nauczyłem się czegoś nowego?

Owszem! Mimo iż książka adresowana jest do osób, które dopiero wkraczają w świat programowania to wiele wzorców dotyczy też bardziej doświadczonych programistów. "Praktyka czyni mistrza" zainspirowała mnie do stworzenia listy lektur. Znalazłem też w niej wskazówki dotyczące tego, jak odmówić w momencie kiedy, ktoś próbuje nas "wepchnąć" na stanowisko menadżerskie :) Bardzo często zdarza się tak, że osoba, która wykazuje cechy lidera z programisty staje się team liderem zespołu, scrum masterem bądź kierownikiem projektu. Taka niestety jest często ścieżka awansu w naszym IT. Junior -> Regular -> Senior -> Menadżer. Wiadomo - trzeba to brać w dużym uproszczeniu (nie wszędzie tak jest). Gdy jako doświadczony programista, wykazujący inicjatywę liderską dostajemy propozycję "awansu" często skuszeni poczuciem jakiejś tam władzy itp. itd. Po przeczytaniu książki wiem już jak do tego nie dopuścić i pozostać na ścieżce programisty. Co więcej - wiem jak stawiać sobie nowe cele i wyzwania aby stawać się coraz lepszym w tym co robię.

Podczas czytania książki natrafiłem również na wzorce, które wywoływały uśmiech na twarzy, przypominając wcześniejsze etapy mojej kariery jako programisty. Na przykład wzorzec "Zamiataj Podłogę". Mówi on, że czasem musimy wykonać zadania, na które nikt inny nie ma ochoty. Wiadomo - nie chodzi tu o dosłowne zamiatanie podłogi w biurze ale np. wykonywanie żmudnych zadań, których nikt nie chce się tknąć. W dłuższej perspektywie sprawia to, że w oczach zespołu, menadżera, zyskujemy zaufanie. W moim przypadku chodziło o skatalogowanie płyt głównych od telewizorów. Było to podczas pracy w Samsungu. Nikt nie chciał podjąć się tego zadania. Wymagało ono sprawdzenia wszystkich płyt głównych, opisaniu ich, sprawdzeniu wersji firmware-u, zaktualizowaniu do najnowszej itp. itd. Zajmowało to dużo czasu, ale w dłuższej perspektywie się opłaciło. Nikt nie miał takiej wiedzy na temat zespołowego sprzętu jak ja :) "Hej Przemek! Mamy płytkę z wersją XX.YY?" - "Mamy, ale ma uszkodzony czujnik". Czułem się ważny ;) Z czasem dostałem propozycję objęcia pozycji koordynatora zespołu. Później okazało się, że byli też inni - bardziej doświadczeni członkowie zespołu na to miejsce. Jednak mój przełożony na podstawie inicjatywy, jaką wykazałem przy katalogowaniu płyt głównych, wybrał do tego zadania właśnie mnie. Eh...wspomnienia ;)

Wzorce to nie wszystko

Do książki dołączone są dwa posty z bloga jednego z autorów (Dave'a). Bardzo podobał mi się ten wzywający do uruchomienia programów nauki rzemiosła. Ostatnimi czasy zauważyłem taki trend, że firmy szukają najczęściej "seniorów". Kogoś, kto z marszu mógłby wskoczyć, obadać sytuację i po krótkim czasie być w stanie ogarniać sytuację w projekcie. Rzadziej widuje się ogłoszenia na stanowiska juniorskie czy nawet staże. Dave wzywa nie tylko do zatrudniania osób z mniejszym doświadczeniem ale także do otaczania ich opieką mentorską. Namawia do brania pod swoje programistyczne skrzydła nowych osób i dbaniu o to żeby nie zbaczały z obranej ścieżki rozwoju. Czasami trzeba będzie przełknąć to, że uczeń przerośnie mistrza ;) Ale z drugiej strony daje to też motywację do dalszego rozwoju.

Czytaj w oryginale

Jeśli miałbym się do czegoś przyczepić - to byłoby to niestety tłumaczenie. Generalnie przez większość książki jest "ok". Ale przy ostatnich stronach odniosłem wrażenie, że osoba tłumacząca już miała dosyć i robiła to na tzw. "odwal się". Kilka literówek i błędów składniowych w zdaniach. Najbardziej rozbroiło mnie stwierdzenie o "smukłym oprogramowaniu" :) ... Także jeśli macie dostęp do książki w oryginale to polecam. Znajdziecie ją np. na learning.oreilly.com. Jeśli jesteście nowym użytkownikiem to macie 21 dni próbnych z dostępem do wszystkich materiałów. Polecam!

Podsumowanie

Gdyby ktoś mnie spytał o książkę "na weekend" to zdecydowanie polecam "Praktyka czyni mistrza. Wzorce, inspiracje i praktyki rzemieślników programowania".

  • Fajny wstęp, opis mistrza, czeladnika i ucznia,
  • Wskazówka, żeby nie czytać od początku do końca,
  • Kontekst, Problem, Rozwiązanie, Działania,
  • Niby oczywiste ale z kontekstem daje do myślenia,
  • Mapy myśli - połączone wzorce