Czy warto kupić książkę Czysty kod?

pytanie zadane 4 lutego w PHP, Symfony, Zend przez `Krzychuu Stary wyjadacz (12,630 p.)

Czy warto kupić Czysty kod Robert C Martin?, Słyszałem że przykłady są w Java, ucze się PHP i zastanawiam się czy inny język w przykładach nie będzie problemem

3 odpowiedzi

odpowiedź 4 lutego przez Tomek Sochacki Mędrzec (179,130 p.)
wybrane 4 lutego przez `Krzychuu

Najlepsza

Tak warto, jest to jedna z lepszych pozycji o programowaniu praktycznie dla każdego programisty niezależnie od języka. Dużo z niej wyniesiesz.

1	komentarz 4 lutego przez Hiskiel Pasjonat (22,880 p.) Co takiego jest ciekawego w tej książce? Pisanie czystego kodu, to (literally) paręnaście zasad, a książka ma ok. 400 stron..

1	komentarz 4 lutego przez Tomek Sochacki Mędrzec (179,130 p.) Moim zdaniem jest tam wiele cennych rad, zresztą nie znam chyba żadnego programisty który by stwierdził, że jest to słaba pozycja... także jesteś pierwszym :) A tak z ciekawości, skoro ją krytykujesz, to czytałeś ją w ogóle :)?

komentarz 4 lutego przez Hiskiel Pasjonat (22,880 p.)

Nie krytykuję jej, tylko pytam co w niej jest ciekawego. Stwierdziłem, że zasady pisania dobrego kodu można rozpisać na stronie - dwóch, a książka ma 400, więc nie za bardzo widziałem sensu tej książki.

komentarz 4 lutego przez Tomek Sochacki Mędrzec (179,130 p.)

teoretycznie tak, ale jak ktoś początkujący przeczyta jedną stronę to wydaje mi się, że niezbyt to zapamięta. A jeśli o każdej zasadzie poczyta na kilku stronach to chyba jakoś bardziej wryją się one w pamięć.

A tak po za tym to czy kupiłbyś książkę o 10 stronach :) ? Może 400 to faktycznie nieco za dużo, ale trzeba też na to spojrzeć z nieco innej, bardziej "marketingowej" strony :)

komentarz 4 lutego przez Ehlert Mędrzec (164,760 p.)

Skoro zasady pisania czystego kodu są dla Ciebie jasne i oczywiste na 2 strony to zgaduję że zagadnienia takie jak: EventSourcing, EventStorming, CQRS, Domeny, Bounded Context czy architektura hexagonalna są Ci obce.

Ja po zderzeniu się z kilkoma kursami OOP myślałem, że większość już wiem, mało mnie może zdziwić.

Po zderzeniu się z pie%)06_-$+% wymaganiami biznesowymi oraz DDD stwierdziłem że nie jestem nawet u podnóża góry lodowej.

odpowiedź 4 lutego przez kubaapk Nałogowiec (40,960 p.)

odpowiedź 4 lutego przez k.wichura Pasjonat (19,250 p.)

Jeżeli nie wiesz czy warto to moim zdaniem nie. Napisałeś że uczysz się programować w PHP więc na tym poziomie nic z niej nie wyniesiesz

komentarz 4 lutego przez Tomek Sochacki Mędrzec (179,130 p.)

Szczerze, to jesteś pierwszym programistą, który uważa, że nie warto zainwestować w tę książkę :)

Ja uważam że warto, jest to naprawdę zbiór dobrych reguł uniwersalnych dla każdego języka. I to szczególnie dla osób uczących się, bo nierzadko widzę błędy typu złe nazwy funkcji, nadmiar komentarzy itp.

komentarz 4 lutego przez rot18ru Obywatel (1,000 p.)

Do wszystkich wskazówek zawartych w tej książce każdy programista jest w stanie sam dojść poprzez praktykę, a bez praktyki i tak się nic nie zrozumie. Dużo programistów robi sobie krzywdę wpajając różne regułki, a później się na nie powołują bez uzasadnienia.

Przykładem może być tutaj częsta krytyka zmiennych globalnych, a przecież umożliwiają one pisanie czytelnych i prostych rozwiązań, dla mniej skomplikowanych problemów. Ale niedoświadczony programista tego nie zrozumie, bo przeczytał w książce, że zmienne globalne są złe i kropka, i zrobił sobie tym krzywdę.

Sam kiedyś wpadłem w pułapkę regułek programowania i później nie byłem wstanie nic napisać, bo wszędzie widziałem łamanie zasad. Ostatecznie nie twierdzę, że książki o programowaniu są złe, ale uważam, że praktyka zawsze będzie lepsza.

komentarz 4 lutego przez Tomek Sochacki Mędrzec (179,130 p.)

a ja się nie zgodzę, że zmienne globalne to takie super rozwiązanie :)

A co do zasad, to na przykład zasada aby tworzyć sensowne nazwy funkcji i zmiennych jest bez sensu? Albo zasady odnośnie komentarzy? Warto takie nawyki wpajać sobie od samego początku.

Sam kiedyś wpadłem w pułapkę regułek programowania i później nie byłem wstanie nic napisać, bo wszędzie widziałem łamanie zasad.

a dasz jakiś przykład? Bo taką opinię słyszę po raz pierwszy :)

ale uważam, że praktyka zawsze będzie lepsza

owszem, ale to nie ma związku z tematem. Możesz pisać w czasie nauki funkcje typu save(), a potem nagle w pracy zjadą Cię na CR bo okazuje się, że nie potrafisz nawet stworzyć sensownej, czytelnej nazwy funkcji... Lepiej od razu uczyć się, że czasem lepiej poświęcić nawet z 10-15 minut na dobrą nazwę niż potem pisać miliard komentarzy i za rok zastanawiać się co ja kurde miałem na myśli pisząc to... :)

komentarz 4 lutego przez mokrowski VIP (105,840 p.)

@rot18ru, pomyśl co jest zasadą a co wyjątkiem od reguł zanim zaczniesz takie rzeczy pisać. Radzę też przeczytać coś o stanie globalnym i kontroli intelektualnej nad kodem. Może to nie być Uncle Bob.

A co do tematu... po przeczytaniu Uncle Boba, warto sięgnąć jeszcze po klasyka. Ostatnio przeglądam taką literaturę https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style książka jest z 1974 :) Już ją polecałem. Zerknijcie na rady. Ani trochę się nie zestarzały choć w samej książce przykłady z Fortranem :) Klasyka rules :)

komentarz 4 lutego przez k.wichura Pasjonat (19,250 p.)

@Tomek Sochacki, Nie napisałem, że nie nie warto inwestować. Sam czytałem, nawet kilka razy, ale z własnego doświadczenia wiem, że na początku mojej kariery przeczytałem ją, ale i tak nic nie rozumiałem. To nie jest książka dla początkującego programisty i na tym etapie szkoda na nią czasu.

Polecam ją z czystym sercem, ale jeżeli jesteśmy już na 'pewnym' etapie i sami umiemy myśleć na temat programowania, a naszymi problemami nie są pytania, czy warto czytać książkę, która jest jedną z najlepszych pozycji o programowaniu.

komentarz 4 lutego przez Ehlert Mędrzec (164,760 p.)

Zmienne globalne? Ok. Mogą być. Jeśli nasze api to jeden plik js/php. Czemu nie.

komentarz 4 lutego przez Tomek Sochacki Mędrzec (179,130 p.)

Jeśli nasze api to jeden plik js/php

hmm... spoko... powodzenia w utrzymaniu tego :) No chyba, że mówimy tu o API do jakieś prostej stronki z paroma endpointami to oki, ale jak rozmawiamy o normalnych aplikacjach to nie wyobrażam sobie takiego podejścia :)