Clean Code - Refactoring, Patterns, Testen Und Techniken Für Sauberen Code (2009) - Plot & Excerpts
The entire content of Clean Code is, or at least should be, common sense to the competent software engineer. Even though the average developer isn't likely to derive a whole lot of new knowledge from reading Clean Code, I consider it up there with the "classics" of software development literature, along with The Pragmatic Programmer, SICP, Introduction to Algorithms, and so on.As far as subject matter coverage, it's reasonably complete. A new developer can read through this book, and at the end have a reasonably complete understanding of the basics of software design. And you can actually read through the book cover-to-cover; it's presented more like narrative than an instruction manual (think Pragmatic Programmer, not SICP).A common gripe with this book is that the examples are a little bit exaggerated, taking the ideology further than anyone actually would in practice. This is definitely true, but they're examples -- designed to help illustrate a point -- not an exact instruction. It goes a little beyond the fundamentals into more controversial areas (Exceptions vs error codes, TDD, etc), which I feel detracts somewhat from the overall cohesiveness of the book. It's also somewhat sparse on details overall, so it helps to have Google at the ready while you're reading it. To me, though, that's the beauty of Clean Code. It outlines the fundamentals in a concise, readable way. I make a point to re-read it every few months. A good book to read for any coder - perhaps not as thorough as Code Complete but much more effective than Pragmatic Programmer. This book's biggest strength is that it includes tons of code examples, including some fairly long and in depth ones. Instead of just listing rules or principles of clean code, many of the chapters go through these code examples and iteratively improve them. The rules and principles fall out of this process and the reader is a part of developing them, which is an effective way to learn.I also liked the justification for why clean code matters in the intro chapters. However, there was not enough discussion of real world trade offs. The book brushes them aside and claims that the programmer should *always* write the most clean code possible; what is not mentioned is to what extent to do this and when. In fact, the book compares code to poetry and art and makes a point to mention that neither is ever done. And yet, everyone needs to ship at some point. So when is code not just clean, but clean enough?Some downsides: the chapters have different authors, so a few are weaker than others. Also, the book is too tailored to Java and imperative/OO programming. Similar to Code Complete, this book would benefit from discussing functional programming, which addresses many of the lessons/problems. Some fun quotes from Clean Code:We want the factory running at top speed to produce software. These are human factories: thinking, feeling coders who are working from a product backlog or user story to create product. Yet even in the auto industry, the bulk of the work lies not in manufacturing but in maintenance—or its avoidance. In software, 80% or more of what we do is quaintly called “maintenance”: the act of repair.You should name a variable using the same care with which you name a first-born child.Quality is the result of a million selfless acts of care—not just of any great method that descends from the heavens.You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers.Remember that code is really the language in which we ultimately express the requirements.LeBlanc’s law: Later equals never.Michael Feathers: I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you—code left by some- one who cares deeply about the craft.Language bigots everywhere, beware! It is not the language that makes programs appear simple. It is the programmer that make the language appear simple!The ratio of time spent reading vs. writing is well over 10:1.Books on art don’t promise to make you an artist. All they can do is give you some of the tools, techniques, and thought processes that other artists have used. So too this book cannot promise to make you a good programmer. It cannot promise to give you “code-sense.” All it can do is show you the thought processes of good programmers and the tricks, tech- niques, and tools that they use.The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.Functions should do one thing. They should do it well. They should do it only. Every system is built from a domain-specific language designed by the programmers to describe that system. Functions are the verbs of that language, and classes are the nouns. This is not some throwback to the hideous old notion that the nouns and verbs in a requirements document are the first guess of the classes and functions of a system. Rather, this is a much older truth. The art of programming is, and has always been, the art of language design.Master programmers think of systems as stories to be told rather than programs to be written. The proper use of comments is to compensate for our failure to express ourself in code. Note that I used the word failure. I meant it. Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration."Objects are abstractions of processing. Threads are abstractions of schedule.” —James O. CoplienConcurrency is a decoupling strategy. It helps us decouple what gets done from when it gets done.Boolean arguments loudly declare that the function does more than one thing.Names in software are 90 percent of what make software readable.
What do You think about Clean Code - Refactoring, Patterns, Testen Und Techniken Für Sauberen Code (2009)?
One of the best books for coders! A must read.Highly recommended!
—quan
A bible for everyone interested in be a better programmer.
—bkstarr21
