Clean Code: A Handbook of Agile Software Craftsmanship

Robert C. Martin Series

by Robert C. Martin

Even bad code can function. But if code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way.
Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship . Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code on the fly into a book that will instill within you the values of a software craftsman and make you a better programmer but only if you work at it.
What kind of work will you be doing? You'll be reading code - lots of code. And you will be challenged to think about what's right about that code, and what's wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft.
Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code - of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and "smells" gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.
Readers will come away from this book understanding

‣ How to tell the difference between good and bad code
‣ How to write good code and how to transform bad code into good code
‣ How to create good names, good functions, good objects, and good classes
‣ How to format code for maximum readability
‣ How to implement complete error handling without obscuring code logic
‣ How to unit test and practice test-driven development

This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.

Genres: Programming, Computer Science, Technology, Software, Technical, Nonfiction, Coding

431 pages, Paperback

First published January 1, 2007

About the author

Robert Cecil Martin, commonly called Uncle Bob, is a software engineer, advocate of Agile development methods, and President of Object Mentor Inc. Martin and his team of software consultants use Object-Oriented Design, Patterns, UML, Agile Methodologies, and eXtreme Programming with worldwide clients.

He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.

Reviews

[Karolina Konduracka · Rating 3 out of 5]

Spodziewałam się dowiedzieć więcej 🤷🏼‍♀️
+ romantyzowanie czytania / pisania „czystego kodu” no totalnie nie jest dla mnie xD

[San Demons · Rating 3 out of 5]

Tak jak wielu zaznacza, generalnie pierwsza połowa spoko i da się sporo dowiedzieć. Ale powinna być jakaś informacja że to jest podręcznik dla ludzi piszących w Javie, bo to dla nich będzie całość.

[kurp · Rating 4 out of 5]

Pierwsze 100-150 stron tej książki to coś w rodzaju olśnienia. Autor całkowicie zmienił mój sposób patrzenia na kod; sprawił, że wyrzuciłem kilka głupich nawyków, które uważałem za oczywistość i w tym kontekście lektura tej książki to prawdziwe objawienie. Jestem zachwycony zapropnowanym tu podejściem i zasadami, które uznałbym pewnie za zbyt radykalne, gdyby nie zostały tak dobrze sprzedane, oprzykładowane i uargumentowane.

Jedyny problem z tą książką polega na tym, że od pewnego momentu z wysokiego poziomu abstrakcji schodzimy na bardzo konkretne przykłady a wywód staje się bardzo java-centryczny, przez co traci swoje uniwersalne właściwości. Początek rozbudza ogromny apetyt, a finalnie okazuje się, że jest tu trochę mniej treści, niż można się było początkowo spodziewać. Ciągle jednak bardzo polecam.

[Tytka na książki · Rating 4 out of 5]

Do “czystego kodu” wróciłem po 8 latach, by sprawdzić, czy jest coś co zrozumiałem opacznie lub nie pamiętałem w ogóle. Jest to klasyk informatyki, szczególnie polecany osobom, które potrafią programować i ze swojego rzemiosła chcą uczynić perfekcje, zachodzącą o sztukę. 

Szczególnie warto przeanalizować najtrudniejszy rozdział w którym przerabiana jest cała biblioteka do obsługi operacji na datach. Czyta się go dość mozolnie ale jego wartość merytoryczna jest ogromna. 

Poniżej przedstawię parę zasad z książki, które uważam za szczególnie ważne w pracy zawodowej. Tworzenie znacznych różnic między nazwami metod i obiektów (account vs accountInfo), w taki sposób, by było je łatwo odnaleźć w całym projekcie . Wybieranie jednego słowa na daną czynność (np. save, persist i keep). Pisząc funkcje powinno się zakładać, że nie znamy nazwy jej parametrów. Jak to jest ważne widać w przykładzie newdate.add(3) - nie jest wiadomo, co jest dodawane do daty - dni, lata?. Na koniec warto dodawać do nazwy funkcji jej efekty uboczne (jak nie można ich wyeliminować). Ponadto, my programiści, zapominamy, by pisać funkcje na jednym poziomie abstrakcji. Jej części składowe nie powinny się różnić poziomem wykonywanych zadań.

Co do komentarzy to zgadzam się z autorem, że nie powinno się ich dodawać. Wyjątkiem są udokumentowane decyzje projektowe lub komentarze zapobiegające przed nadmierną optymalizacją.

Znalazłem jedną zasadę, którą zaniedbywałem. Powinno się unikać dodawania flag do funkcji, gdyż łamią one zasadę pojedynczej odpowiedzialności. Lepiej mieć duplikację kodu niż tak rozgałęzione funkcje.

Na koniec może dla przypomnienia – jedno z najczęściej występujących pytań rekrutacyjnych. Prawo Demeter – trzeba rozmawiać z bliskimi, a nie z nieznajomymi, tak jak w Mistrzu i Małgorzacie, czyli używać w funkcji f klasy C tylko argumentów i obiektów danej klasy C.

[Paul Kastel · Rating 4 out of 5]

Absolutnie to jest książka którą powinien przeczytać, każdy programista niezależnie od technologii w której koduje. Zbiór dobrych praktyk zaczynając od dobierania nazw, refaktorowania, podejścia do komentarzy czy testów. W drugiej połowie zaczyna się robić trochę monotonnie i autor bardziej skupia się na rzeczach domenowych dla języka JAVA, więc to jest jedyny minus, ale to wciąż dobry podręcznik, który świetnie porządkuje wiedzę i praktyki juniorom jaki i absolutnym wymiataczom.

[Kerszi · Rating 4 out of 5]

Książka jest bardziej skierowana do programistów Javy. Nazywanie zmiennych w Pythonie jest raczej inaczej przyjęte, niemniej jednak można się doszukać dużo cennych uniwersalnych rad, które się sprawdzają. Książka dosyć dziwnie się kończy w połowie. Później jest dodatek, którego już nie chciało mi się czytać.

[Panda Ruda · Rating 4 out of 5]

Na pewno będę wracać, sporo poukładała :3

[Alan Owczarzak · Rating 3 out of 5]

dałoby radę streścić w 150 stron (książka ma 400)

[Gosia · Rating 4 out of 5]

Klasyk.
Momentami ciężko się czyta (np. długie fragmenty drukowanego kodu...) + w niektórych tematach jeszcze się nie orientuję (np. testy jednostkowe, współbieżność), więc myślę że przeczytałam ok. połowę tej książki.
Ale w tej połowie było dużo przydatnych wskazówek np. nazywania zmiennych, używania komentarzy, planowania działania funkcji, klas, różnych praktykach programistycznych np. test-driven development. Bardzo przydatna wiedza, będę wykorzystywać w praktyce :)

[Lanżanka · Rating 4 out of 5]

Ciężko było się przebić przez kod bibliotek Javy, a do rozdziału o wątkach pewnie jeszcze wrócę, kiedy przyjdzie mi rozwiązać jakiś wielowątkowy problem. Nigdy więcej nie przeczytam książki informatycznej przetłumaczonej z angielskiego na polski. Są wyrażenia, których po prostu nie powinno się tłumaczyć.

[Dawid]

mocne "well, actually 🤓" energia bije od autora, sporo oczywistości, dużo dogmatyzacji i definiowania Jedynego-Właściwego-Sposobu-Na-Pisanie-Kodu™