Clean Code: A Handbook of Agile Software Craftsmanship
- Paperback: 464 pages
- Publisher: Prentice Hall; 1 edition (August 11, 2008)
- Language: English
- ISBN-10: 0132350882
- ISBN-13: 978-0132350884
The book can be roughly divided into three major sections with an additional “Prologue”.
In the Prologue the Author and several guest authors explain their personal definition of “Clean Code” and why dedication to write the best code you possibly can is so important for the individual software developer.
The first section (Chapter 2 -13) describes a set of best practices for writing readable and elegant code. The topics covered range from basics such as variable naming and formatting to recommendations for structuring classes and systems. The reasoning given for each of the recommendations is detailed and comprehensible.
In the second section Martin dissects three code samples and walks the reader through his series of refactorings as he tries to transform the code into a cleaner state. While valuable, the format makes it difficult to follow the changes being made.
The third section contains a set of “code smells”, similar to those in Martin Fowlers seminal work “Refactoring“.
Opinion and Conclusion:
All guidelines presented are reasonable and well-defined. I got the most value out of the book by reading the first and the third section, while I found the section with the sample refactorings very tedious and not all too helpful. However, comparing the code before and after the refactoring helped to gain an insight into what kind of improvements can be achieved.
Some of the guidelines are no-brainers and are probably the absolute minimum every passionate software developer should stick to.
However, some of the guidelines left me unconvinced. “A function should only know how do to one thing”. I’m perfectly fine with that guideline and agree with it, but if you take it to the extreme it will make you create three helper methods that are only called from one place. Even worse, you will need to pass intermediate state around (bloating signatures) or introduce artificial state in form of class fields. Not to mention the tight temporal coupling helper methods and the artificial class variables will have. Some of the examples in the book suffer from that “over-abstraction”, I think beyond a certain point readability is actually hurt rather than improved.
On the other hand, the level of abstraction should be high enough so the code is self describing in terms of what it does and should not require additional comments. That’s one of the points that particularly struck me as I read the book: Comments are excuses for bad code, so you should always try to make them superfluous.
In general I could learn a lot from the book and would recommend it for reading. Even if not all the guidelines were 100% convincing, the book helped me learn a critical look at code.
Links and Accompanying Books:
- I’m currently reading http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/ref=pd_sim_b_1 from the same series (thanks InishTech!). I think it’s a very good addition. Maybe it’s even more valuable.
I have just updated my Bookshelf. It’s been Christmas season recently, which means I was able to add some substantial extensions to my library. First of all I got a copy of the Gang of Four (GoF) standard work “Design Patterns: Elements of reusable Object-Oriented Software”. As with Eric Evan’s book on Domain Driven Design, I am impressed by the precise style of writing they used to describe common patterns in Software. It’s been pretty handy in situations where I felt like “wait, I have seen this before, let’s do it right this time”.
My next book, “Best Kept Secrets of Peer Code Review” by Jason Cohen was provided for free by Smart Bear Software, the creators of CodeCollaborator a Software to help with code review. By coincidence, the book deals exactly with this matter and describes the necessary steps to introduce, execute and improve a peer code review process. A very interesting read. Thanks guys.
For Christmas I got Peter Seibel’s “Coders at Work”. Unfortunately, I don’t have much time for reading since I need to prepare for my (soon!!!) exams, so this is one of the books that will have to sit on my bookshelf unread for a while. However, I expect it to be a fun and more relaxed read than most other “tech books”.
My employer was kind enough to donate me an Amazon voucher, which I used to buy the Albahari Brother’s (the are also the creators of LINQ Pad) LINQ Pocket Reference and a book on Functional Programming with F#. Thank you very much Mrs. Leber. Even though I could just read small parts of them, they provided for an excellent bonus on understanding of the underlying principles on LINQ, which was especially handy during my work with the MoreLinq project.
I feel a little unsatisfied for having around 5 books sitting on my desk which I am half through. I’m on a very tight schedule at the moment and need to prioritize tasks relentlessly. Pretty much the same I had to do my whole last year, so I’m used to it :-). Each of those books has been a valuable support to the work I’ve done lately, so I will continue to expand my library in this and that direction, if I see the above criteria met. This leaves me realizing, how important continuous learning and expanding one’s horizon is, which is fun because the horizon is so huge and there’s always something new to discover. Kind of opposite to what I need to do for school at the moment (fixed horizons, fixed expectations and known solutions)…
Author : Eric J. Evans
Publisher: Addison-Wesley Longman, Amsterdam; Edition: 1. A. (4. September 2003)
Eric Evans introduces a new approach to Software Modeling: Domain Driven Design (DDD). Just as the title says it deals with techniques and best practices for managing domain complexity. At the core of it lies the concept of “unavoidable complexity” that is, the complexity of the domain. It is all about creating a model of your domain in software that captures all the knowledge necessary to solve the problems the software is intended to.
Evans starts with describing the development process necessary to make this goal achievable. Knowledge Crunching is all about invoking the Domain Experts and making the Developers understand the Domain. A Ubiquitos Language with a sharp description of all its elements must evolve, to make communication efficient and less prone to errors. An agile, feedback driven process is necessary for Binding Model and Implementation that is, feeding back insight gained during model implementation into the modeling process.
This takes us to the next important concept: Insight. Insight describes the process at a human level. It is the core challenge of building software that is intended to solve real-world problems. Software Developers mustn’t be specialists – they need to be generalists: engineers. A good developer bridges the gap between technology and domain because he is an expert in both. Eric Evans acknowledges it is impossible to be an expert in every domain without having experience with it.He therfore appreciates Insight and advocates refining the model when new Insight is gained. Through continuous Knowledge Crunching and Distillation a Deep Model eventually emerges.
A process like this requires proactive structuring of the code base to accomodate change – Supple Design. Something which I think is a very essential concept. It is necessary for a Test Driven Design Process or in areas of the domain that are likely to evolve in the future. For this purpose he describes a set of patterns that help abstracting domain object responsibilities into explicit concepts, which is another core tenet of Supple Design: Making Implicit Concepts Explicit. This applies not only to the structure of the code base but also to the concepts of the domain.
Opinion and Conclusion:
I think this book is a must read for everyone that considers software development to be a craft. The parallels to engineering are astonishing. Eric Evans has a very explicit style of writing, which accounts a lot to the value of this book. The sharp definitions and clear distinctions make it possible to convey a lot of information in a very dense manner. I wonder if Evans is a mathematician :-)
Links and Accompanying Books:
- Eric Evans: What I’ve learned about DDD since the book
- (Martin Fowler) Patterns of Enterprise Application Architecture
In the following weeks I want to write reviews about the programming and technology related books sitting on my bookshelf. You can find an up to date list of these books here, where I will also link the corresponding Blog Post.
There are several goals I try to accomplish with this series:
- Recapitulate gained knowledge, focusing on the most crucial aspects
- Keeping track of what books I do have but didn’t have time to read yet
- A Wishlist of Books I plan to buy, mostly focused on those areas I want to enrich my knowledge
- Provide a ‘get started on a topic’ list for others
I think the format will be something like:
- Title, Author, Pages, ISBN, Picture, Amazon link
- Short Summary of Content
- Most important thing i learned
- What did I like? What not?
- Conclusion, good accompanying books