Praca z zastanym kodem. Najlepsze techniki

Recenzje ebooka: Praca z zastanym kodem. Najlepsze techniki (2) Poniższe recenzje mogły powstać po przekazaniu recenzentowi darmowego egzemplarza poszczególnych utworów bądź innej zachęty do jej napisania np. zapłaty.

1. Recenzja: forbot.pl gogowitczak

   Recenzja dotyczy produktu: ksiązka drukowana

   Czy recenzja była pomocna:

    TAK  (0)  NIE  (0)

   W tej recenzji chciałbym przybliżyć czytelnikom Forbota książkę „Praca z zastanym kodem. Najlepsze techniki”, autorstwa M. Feathersa.
   
   Jest to jedna z nowych pozycji wydawnictwa Helion, obecna w księgarniach od niemal roku.
   
   
   
   Zawartość
   
   Książka podzielona jest na trzy części, składające się łącznie z 25 rozdziałów, zajmujących łącznie niemal 450 stron. Jest zorganizowana w formie najczęściej zadawanych pytań i odpowiedzi (ang. FAQ – Frequently Asked Questions), np. „Nie rozumiem wystarczająco dobrze kodu, żeby go zmienić” czy „Muszę dokonać zmian. Które metody powinienem przetestować?”, które są jednocześnie tytułami rozdziałów. Dzięki temu nie ma potrzeby jej czytania „od deski do deski”, można wybrać jedynie rozdziały, które nas interesują. Wszystkie te pytania są wyszczególnione w spisie treści, zainteresowanych odsyłam na stronę wydawnictwa.
   
   Na samym początku lektury autor odpowiada na pytanie czym jest zastany kod (ang. legacy code). Istnieje wiele definicji – kod napisany przez kogoś innego (którego często nie rozumiemy) czy kod starszej wersji systemu, który musimy utrzymywać celem zapewnienie kompatybilności wstecznej. Feathers wprowadza nową, prostszą definicję zastanego kodu – „kod bez testów”.
   
   Kod bez testów to zły kod. Nie ma znaczenia, jak dobrze jest napisany; nie ma znaczenia, jaki jest ładny, jak bardzo zorientowany obiektowo czy też jak mocno hermetyczny. Za pomocą testów możemy zmienić zachowanie naszego kodu szybko i w sposób weryfikowalny. Bez nich tak naprawdę nie wiemy, czy kod zmierza ku lepszemu, czy ku gorszemu.
   
   Można śmiało powiedzieć, że jest to również motto tej książki. Autor pokazuje praktyczne przykłady w jaki sposób zmodyfikować istniejący kod, aby możliwe stało się jego przetestowanie. Wiąże się to również ze swojego rodzaju błędnym kołem – aby stworzyć testy, należy zmodyfikować kod, ale aby bezpiecznie to zrobić, należy najpierw napisać do niego testy.
   
   Praca z zastanym kodem przypomina stąpanie po polu minowym – a autor pokazuje, w jaki sposób bezpiecznie wyciągnąć i zabezpieczyć te miny, nakładając na nie testy.
   
   Większość przykładów dotyczy języków Java i C#, choć zdarzają się również przykłady w C++ (przede wszystkim cały rozdział 19. „Mój projekt nie jest zorientowany obiektowo. Jak mogę bezpiecznie wprowadzać zmiany?”).
   
   
   
   Subiektywna opinia i podsumowanie
   
   Po pierwsze należy zwrócić uwagę, do kogo skierowana jest ta książka. Jest to pozycja dla zawodowych programistów, którzy w swojej karierze już zetknęli się z zastanym kodem i widzieli niejedne „ośmiotysięczniki” (potoczna nazwa na klasy/pliki składające się z ponad 8.000 linijek kodu). Dopiero mając takie doświadczenie, można „czerpać garściami” z treści zawartych w tej książce.
   
   Jeżeli, Drogi Czytelniku, nie posiadasz takiego doświadczenia, to zdecydowanie polecam lekturę kultowej już pozycji „Czysty Kod. Podręcznik dobrego programisty”, również wydanej przez Helion.
   
   Zdecydowanie polecam tę książkę wszystkim programistom, którzy chcą podnieść swoje umiejętności w zakresie refaktoryzacji i poprawy zastanego kodu, aby ułatwić sobie prace i „zostawić ten kod trochę lepszym, niż się go zastało”.

2. Recenzja: klubdobrejksiazki.pl Rafał Kocisz

   Recenzja dotyczy produktu: ksiązka drukowana

   Czy recenzja była pomocna:

    TAK  (0)  NIE  (0)

   Są takie tematy, których autorzy książek dotyczących inżynierii oprogramowania sukcesywnie
   unikają niczym ognia. Mam tu na myśli te najciemniejsze zakątki naszej profesji. Nie dziwię się temu wcale; nie jest miło pisać o projektach z góry skazanych na klęskę, o tym, jak pracować
   z dziesięcioletnim kodem opatrzonym chińskimi komentarzami bądź o technikach przetrwania
   przy pracy w rozproszonym zespole, gdzie kierownik projektu po stronie klienta nie ma o tym projekcie bladego pojęcia, technologia, na której projekt się opiera, jest niestabilna, a morale członków zespołu jest tak niskie, że już nawet nikomu nie chce się na ten temat dyskutować. Znacznie przyjemniej jest pisać o nowych, cudownych językach programowania, niezawodnych
   narzędziach czy genialnych metodologiach, które sprawią, że projekt sam się będzie prowadził. Dla jasności: nie jestem wcale przeciwnikiem tej drugiej kategorii tematów; wręcz przeciwnie – cieszę się, że ludzie z całego świata nieustannie tworzą nowe narzędzia, języki czy metodologie, sprawiające, iż nasze próby przetrwania w smolistym grzęzawisku inżynierii oprogramowania mają coraz większe szanse powodzenia. Z drugiej strony ubolewam nad tym, że te trudniejsze, mniej wdzięczne, ale jakże życiowe tematy związane z wytwarzaniem
   oprogramowania traktowane są przez autorów fachowej literatury po macoszemu.
   Z tego też względu z dużym zainteresowaniem przyglądam się tytułom, które tego rodzaju zagadnienia analizują. Jeden z tych tytułów chciałbym dziś zaprezentować na łamach kolumny Klub Dobrej Książki.
   
   Praca z zastanym kodem (ang. legacy code) jest niewątpliwie tematem,
   który można zaliczyć do trudnych i mało wdzięcznych zagadnień związanych z inżynierią oprogramowania. Z drugiej strony problem ten jest powszechny; sytuacje, w których zespoły programistyczne muszą borykać się z tego rodzaju kodem, są na porządku dziennym. Jestem w stanie zaryzykować stwierdzenie, iż projekty tego rodzaju są częścią pracy statystycznego programisty znacznie częściej niż przedsięwzięcia, w których można cieszyć się luksusem
   pisania kodu od podstaw. W tej sytuacji z wielkim zainteresowaniem sięgnąłem po książkę autorstwa Michaela Feathersa pt. Praca z zastanym kodem. Najlepsze Techniki. Fakt, iż autor tej pozycji wywodzi się z legendarnej firmy konsultingowej Object Mentor, jeszcze bardziej zaostrzył mój apetyt na tę lekturę. I wyprzedzając nieco fakty, mogę stwierdzić, że się na tej książce nie zawiodłem…
   
   Kilka słów o strukturze omawianej pozycji. Książka składa się z trzech głównych części, podzielonych w sumie na 25 rozdziałów. Części pierwsza, opatrzona tytułem Mechanika Zmian, stanowi swoiste wprowadzenie w temat, oraz – co istotne – definiuje słownik pojęć, na których opiera się główna treść książki, zawarta w części drugiej. Czytając to wprowadzanie, poznamy
   następujące tematy:
   - rola wprowadzania zmian w oprogramowaniu,
   - rola testów w pracy z zastanym kodem,
   - rozpoznanie i separowanie jako podstawowe techniki usuwania zależności przy pracy z zastanym kodem,
   - model spoinowy, czyli jak można zmieniać zachowanie programu bez jego edycji,
   - narzędzia wspierające pracę z zastanym kodem.
   
   Część druga książki, zatytułowana Zmiany w Oprogramowaniu, to obszerny fragment zorganizowany w postaci FAQ (ang. Frequently Asked Questions), czyli najczęściej zadawanych pytań oraz odpowiedzi dotyczących pracy z zastanym kodem. Autor omawia w tym miejscu następujące zagadnienia:
   - Jak mogę dodać nową funkcjonalność w zastanym kodzie?
   - Co zrobić, kiedy nie mogę umieścić danej klasy w jarzmie testowym?
   - Co zrobić, kiedy nie mogę uruchomić danej metody w jarzmie testowym?
   - Muszę dokonać zmian. Które metody powinienem przetestować?
   - Muszę dokonać wielu zmian w jednym miejscu. Czy powinienem pousuwać zależności we wszystkich klasach, których te zmiany dotyczą?
   - Muszę dokonać zmian, ale nie wiem, jakie testy napisać.
   - Dobijają mnie zależności biblioteczne.
   - Cała moja aplikacja to wywołania API.
   - Nie rozumiem wystarczająco dobrze kodu, żeby go zmienić.
   - Moja aplikacja nie ma struktury.
   - Przeszkadza mi mój testowy kod.
   - Mój projekt nie jest zorientowany obiektowo. Jak mogę bezpiecznie wprowadzać zmiany?
   - Ta klasa jest za duża, a ja nie chcę, żeby stała się jeszcze większa.
   - Wszędzie zmieniam ten sam kod.
   - Muszę zmienić monstrualną metodę, lecz nie mogę napisać do niej testów.
   - Skąd mam wiedzieć, czy czegoś nie psuję?
   
   Ostatnia, trzecia część książki, opatrzona tytułem Techniki Usuwania Zależności, to katalog refaktoryzacji, które są szczególnie przydatne przy pracy z zastanym kodem.
   
   Patrząc z mojej perspektywy (programista oraz techniczny kierownik projektów IT z ponad dziesięcioletnim doświadczeniem), książka autorstwa Michaela Feathersa jest bardzo cennym źródłem wiedzy w temacie organizacji pracy z zastanym kodem. Szczególnie wartościowy jest katalog rozwiązań opisany w części drugiej (Zmiany w Oprogramowaniu), głównie ze względu na swój wysoce praktyczny i rzeczowy charakter. W trakcie lektury czuć, że mamy do czynienia z bardzo doświadczonym autorem; z tego względu po lekturze tej pozycji najwięcej skorzystają dojrzali programiści, występujący w roli liderów technicznych w swoich zespołach (dla początkujących adeptów inżynierii oprogramowania treść tej książki będzie niewątpliwie przytłaczająca).
   
   W ramach podsumowania niniejszej recenzji pozwolę sobie zacytować fragment przedmowy do książki Praca z zastanym kodem autorstwa Roberta C. Martin'a (znanego pod pseudonimem Wujek Bob):
   "Ta książka to nie zaczarowany pocisk. Nie dowiesz się z niej, jak w ciągu jednej
   nocy wyeliminować nagromadzone w Twoich systemach zepsucie. Zamiast tego
   w książce tej opisano zbiór elementów dyscypliny, koncepcji oraz postaw, które
   będą przy Tobie obecne przez resztę Twojej kariery i które pomogą Ci zmienić systemy,
   które stopniowo się degenerują, w systemy, które stopniowo są coraz lepsze."

więcej recenzji

ukryj recenzje