I see the greatest truths to simplicity.

A book popular on the Internet a few days ago was Zhou aimin's "the greatest truths to simplicity". After reading the name, I did not care about it, later, the project manager recommended this book to me and sent an electronic version to my mailbox. Later, someone in the company began to discuss this book, which aroused my curiosity, playing a game is also a waste of time. It is better to look at what this book has written. I got used to sleeping late when I was reading the book Late at night. I found out this book and planned to apply it to hypnosis. But then I found it counterproductive, at AM, the next day is the weekend. You can have a big sleep.
This is a book on software engineering. In fact, I have read a foreign master's work "man" before. I read this book for the name of this master, but now I almost forgot what it is about. It may be that the writing style of foreigners is different, or when I arrived in China, the translation was wrong, however, this book is different. At the beginning of most of the chapters in "the greatest truths to Jane", I want to talk about a small story from the ancient Chinese times and reference the original article. The author is really hard-thinking, use a small story to arouse the reader's desire to watch it. Use the story to explain some truth and then derive it into software development to explain some phenomena. The whole book is indeed a question. Every question tries to talk about the essence from the appearance. When it comes to the essence, the natural avenue is simple. From the object-oriented perspective ---> problem thinking ---> Software Engineering, all reflect this idea.
In fact, it can be seen from the book that the author is a practical person who is good at thinking. The above sentence actually sums up the two greatest gains I have gained from reading this book, I think this is what the author wants to convey to us. First of all, he is good at thinking. From the very beginning, he has made in-depth thoughts on every question and story he wants to elaborate, and extracted the essence of the question into simplicity, this is the first thing that the author wants to convey to us. The author may want us to be good at thinking and spend more time thinking after reading this book, instead of repeatedly writing code every day and night. In fact, we should not blindly think about it. From the actual point of view, for example, in chapter 4, the author talked about communication. The author believes that communication between customers and programmers, or the communication between the customer and the Business Company, the most important thing is that both parties can effectively communicate with each other in a short period of time to discuss substantive issues, so they can be expressed in C language or in a UML use case diagram, or, it is not a problem to use pseudocode. The author even joked that writing customer communication reports with Oracle is better than UML case subgraph. Therefore, communication aims to achieve mutual understanding, the idea similar to this is explained in a book. The author believes that solving the problem is fundamental, and so many technical terms are actually complicated, of course, we don't want them, but we need to understand their roots when we use them again. This is pragmatism, starting from solving problems together. "Just like the compiler and integrated development environment (IDE) in programming tools, the Model language in the development process is just a tool. The old tools are generated out of the need for '( software) realization '. "----- the greatest truths are the ultimate simplicity. Therefore, thinking is the source. "Go has four stages of learning: Remember to apply patterns and forget patterns to create patterns ". --- Appendix.
However, when I carefully read this book (maybe we shouldn't define it as a book at all, I personally think this article only guides us to learn to think, be good at thinking, and be diligent in thinking at the ideological level, just to better illustrate the author's point of view, taking software engineering as an example, in a certain sense, a book should be a self-contained system, so from this perspective I just define it as a long article). So from this perspective, this book is not very systematic, although the article from the object-oriented ---> problem thinking ---> Software Engineering ---> think about this very narrative logic to complete what the author wants to express, however, narration still does not cover up the flaws of the system. At the end of chapter 8, the author still turned his pen to think about this fundamental topic. However, the description in the last chapter is too fragmented and can be easily written, if this part is well organized.
In general, this is a recommendable article.
I learned how to train myself !!!