Clean code book review
There are a few books that I usually recommend to any software engineer who wants to get better at writing clean code. Among them, my favorite is "Clean Code" by Robert C. Martin. This is one of the books that influenced me a lot early in my career and I want to share a review about it.
Comment
Personally, I like the two definitions of “clean code” listed in the book. One by Dave Thomas:
Clean code can be read and enhanced by a developer other than its original author. It has unit test and acceptance test. It has meaningful names. It provides one way instead of multiple ways to do one thing. It has minimal, well-defined dependencies and provides a clear and minimal API. The code should be easy to understand because depending on the language, not all of the required information can be clearly represented in the code alone.
And another definition of Michael Feathers:
Clean code always looks like it was written by someone interested.
Long-term maintenance accounts for the majority of the cost of a software project. The more complex the system, the longer the programmer takes to understand it, and as a result, the more opportunities to misinterpret the original intent. There are two common sources of bad code:
A conscious choice in the face of deadlines - The team performs the bad code merge with a promise to spend time on it in future sprints. Sometimes it won't be resolved due to other backlog priorities, especially if the team works in a fast-paced environment typical for startups. As a result, the group's productivity gradually decreased over time until there was a need to settle the technical debt. Debt will have to be paid at a hefty price to rewrite the entire function. The author gives an example in which a team spent 10 years rewriting the codebase while gradually increasing new functions. By the time the rewrite is complete, the "new" codebase requires another full rewrite.
Lack of design principles and practices broken down through code reviews - It's easy to write code that is clear to the author because they have deep understanding of the problem and full context. The design looks clean and "beautiful" to the creator. However, other maintainers will not have the same understanding and they may take a different view of what "clean and beautiful" means. Worse yet, the original intent can be lost if the author is no longer in the group. Maintenance people introduce new code according to their own standards and understanding. That starts a snowball effect that will ultimately worsen the codebase.
“Clean code” expresses the author's opinion about clean code as a school of thought based on their long experience in software building. Some opinions are controversial, others can be disputed. Uncle Bob, the author, makes it very clear that there are other views on clean code definition. Opinion should not be taken as absolute, but rather a great opportunity to learn.
The book is organized into three parts:
Clean code rules, patterns and practices. It covers a wide range of topics: comments, naming, functions, objects and data structures, etc. Some topics that I personally like: One level of abstraction per function, Step by step rules for organizing code, Check for third-party dependencies.
Code cleanup case study. The case studies include: refactoring the command line argument parser; JUnit internal restructuring; Refactor the SerialDate class in the JCommon library. It is very interesting to look at the authors' thought processes and the transformation of the code.
List of experiences gathered while creating the case studies. It describes how authors think as they write, read, and clean up code. Much of the code is borrowed from Martin Fowler's "Refactoring". Some interesting signs: inconsistency in code; misplaced responsibility; design execution with structure, not by convention; avoid negative conditions; choose the name at the appropriate level of abstraction.
The authors consider Kent Beck's four simple design rules as a good starting point for maintaining clean code:
Run all tests - Tests force you to test your code design as a consumer. Keeping tests clean is just as important as keeping clean code.
Contains No Duplicates - Duplication is the main enemy of well-designed systems. Extracting common ground at small levels can reduce the complexity of the overall system.
Expressing the intent of the programmer –Code needs to clearly show the intent of the author. Using good names, keeping functions and classes small, using standard nomenclature, keeping well-written unit tests are ways to facilitate the expression of intent.
Minimize the number of classes and methods - a way to counter dogmaticism and put more effort into grasping the essence of design (although the first three rules are more important)
“Clean Code” provides lots of code examples that help explain principles and techniques. The book is easy to read and Uncle Bob has his own unique way to engage a very interesting audience.
My experience
There are good books on how to write clean code but like any skill, coding takes practice. You may be lucky enough to have a great mentor or senior engineer on the team that will help you get into good coding habits and habits through a series of code reviews. But if you don't have it, a handbook with tips and techniques packed with good examples is sure to help. “Clean Code” is one of those manuals.
Many of the things Uncle Bob mentions in the book can be implemented using the right tools such as being able to automatically check the code and reject the pull request. However, that depends a lot on the programming language you choose and the maturity of the ecosystem. For example, Golang provides a lot of tools and is forced to write code in a certain way. On the other hand, Scala offers different ways of how one might write code, and that can lead to an undesirable state of the code base. If tools are missing, one way to increase the quality of the code base is to document best practices and provide training for engineers during the introduction and execution of those methods through code review cycle. Executing code reviews for each pull request is a good way to share knowledge and make code more consistent.
At the same time, learning different programming models and languages can accelerate good coding habits. For example, functional programming and the concept of referential transparency provide a different view of how code is written and that knowledge can be transferred to other programming languages to a certain extent. For example, functional components encourage splitting code into smaller functions that do one thing. It helps to reuse code and provides modules to incorporate those functions. Clearly grasping the side effects makes programming argument easier and forces the author to focus more on separating concerns and dividing responsibilities between code classes.