TL;DR: A comment on Clean Code Cookbook in Japanese
This is the opinion on Clean Code Book by Naoki Hayashida translated by Google.
Original in Japanese:
My collection of books has increased dramatically over the last month and this month, so I have quite a lot of unread books ...
I have finished reading one of the above, the Clean Code Cookbook, so I would like to share my thoughts on it.
Not for beginners
This book is not the kind of book that tells you how to write clean code by following recipes. It is not a "collection of recipes that you can follow to write clean, working code," but rather a "collection of recipes that will help you understand the principles, carefully consider whether they should be applied, and then improve your own code."
Therefore, this book is intended for people who have basic knowledge ofobject-oriented programming and have experience programming systems of a certain size.
Also, the sample codes are written in multiple programming languages , so it may be difficult for people who cannot read other languages at all. Moreover, most of the sample codes do not state which language they are written in.
Of course, there are many small code examples that are easy to understand even if you have never used the language itself, so if you have some experience or knowledge of multiple programming languages, you don't have to worry . However, if you are only at the level of being able to write one programming language at best , it is quite possible that you will not be able to read all the sample code.
It is important to read the first two chapters carefully.
Like other cookbooks, the majority of this book is a collection of recipes. However, it does not simply list patterns; the first two chapters are introductions and principles.
This principle is quite important, and the whole book is based on the principles up to Chapter 2. Therefore, if you look at this book as a collection of patterns without reading up to this chapter, you will miss the important viewpoints of this book, so I recommend that you hold off on reading the recipes that interest you first and read up to Chapter 2.
Sometimes I think, "Hmm, this is..."
Personally, there were some parts that made me wonder, "What's this about...?" For example, "I understand it from an implementation point of view, but is it essential as an expression of the business domain ?" I think it's fine if the logic remains within a certain object because the external behavior doesn't change, but there are some recipes that I'm a little concerned about even if they are internal expressions.
Also, in certain languages, what are called anti-patterns in recipes are considered to be so-called common code patterns. I think that you can't just apply these things because they're in the recipe.
However, most of the recipes are ones that you will think "this is it," so I think it's important for you to think for yourself, "I will try this recipe" or "I won't try this recipe."
It's extensive and voluminous, so it's probably a good idea to re-read it several times.
It's a lengthy book, and contains content in a variety of contexts, so it's not the kind of book you can learn by reading it once, nor is it the kind of book you can learn by copying out example code.
On the other hand, I think the easiest way to use it is to look back at it when you notice in your code that "Oh, this is similar to a problem with a recipe in the Clean Code Cookbook." I also think it would be good to use it as a basis for creating a common understanding within a development team, such as "Do you want to apply the recipe in the Clean Code Cookbook?"
My personal favorite recipe
This is a recipe that I personally liked.
Recipe 3.6 EliminatingDTOs
This recipe advises against using (Local) DTOs used in specific frameworks , etc.
If you are using a specific framework , this may be a recipe that you would be strongly opposed to, but if you look at it neutrally, it is true that there are disadvantages to this, such as it makes it easy to mass-produce boilerplate code and makes it easy to create objects equivalent to an anemic domain model .
Personally, I have rarely come across critical articles about DTOs on the web, so I found it interesting to see it described as a recipe.
Of course, I think this pattern has advantages such as "loose couplingbetween layers" and "no need to expose unnecessary domain logic to the presentation layer." However, this article makes me think that we should not just think that it's okay to use DTOs without thinking.
After reading this recipe, if you are thinking of usingDTO , I think it might be interesting to think, "Is there a way to obtain the same benefits as DTO ?"
Recipe 16.4 Avoiding Overgeneralizations
Sometimes abstractions are made that say commonality is justice, but the logic behind this recipe is that we should avoid commonalizing things that happen to match at the time.
This recipe, like the others, is written quite briefly, but I think it is a pretty important recipe, as standardization is always thought to be a principle of programming.
Summary
I think the Clean Code Cookbook is a book that will be useful for people who are actually writing code for medium-sized or larger systems to look back on how they write code and get closer to clean code. I think it would be a good idea to read it as an individual or as a team and aim for clean code.
