Wen yan book reviews: reading the "Code path"

Wen yan book reviews: reading the "Code path"

Books that are boring and without opinions will never interest people in reading. Rest assured that "the path to code" is definitely not!

 

Form: each article in this book raises a question by telling a story, analyzes the root cause of the question, and finally provides suggestions for improvement. Among them, the question is often very dramatic (the author also admitted that "in order to achieve the effect, I once again exaggerated the problem"), so as to highlight the huge negative impact of the problem, and make the reading process interesting. As a result, it is not surprising that the book is in the hands.

 

Don't say, "I know some architects and their lives are out of control." Come back to the real world, working under other managers may not solve the problem. "These strong and harmonious words point to the pain points of people-the reality is like this!

 

 you don't have to say, "You are always hurting the person you love", "understanding and accepting the lifestyle you have chosen." These philosophical words give rise to the illusion that the book's shelving recommendations are really "software ". project "?

 

"Management is impractical", "today, everyone speaks vernacular over cross-Department Cooperation. If you want to say something that you don't dare to say, it's enough to "catch" you-I have to read this book!

 

In positioning, this book is not only a list of practical suggestions, but also an in-depth thinking set. The lines in the book reveal the author's painstaking efforts: not only does it "push" give you practical suggestions that reflect the essence of its many years of experience, but it also helps you to cure the disease, even more, you should thoroughly think about and analyze the key issues in the first-line development. This is very commendable. Even if I do not agree with a certain point of view stated by the author, my appreciation for the author's painstaking efforts has not been reduced.

 

The content is closely related to the first-line "software engineers and engineering managers. First, it is the software development process. Chapter 2 describes the project management experience. In chapter 2, the core idea is "agile, but rational ". The true meaning of Chapter 3rd is not "stop writing a standardized book", but "to improve collaboration efficiency, informal documents are recommended ". Chapter 2 describes the relationships between developers, testers, and other roles. Chapter 4 Quality = Business Value + No engineering bug. Chapter 2 describes the preliminary design ....... Yes, process management, project management, communication management, role setting, quality management, and preliminary design are the concerns of the software development process.

 

In addition, 30% of the content in this book covers the growth of frontline developers and managers. For example, I like chapter 1 very much. The author provides managers with practical suggestions: how to identify talents, how to interview, how to help mediocre employees, and how to avoid "internal competition" in the team "....... Very pertinent.

 

Interestingly, I read a large part of this book on a train when I went out to give lectures, the reading of this book is like sitting on a shaking train. It cannot help your brain to slack off, because it will make your views jump out frequently, high Impact.

 

"Is there a way to build a bridge between large products and small teams? The answer is yes, yes! That is the architecture. The most important thing about the architecture is that it can break down hard-to-solve big problems into small problems that are easy to manage ." Very well summarized. I also often talk about the degree to which the architecture should be designed? First, we need to support detailed parallel design. Second, we can flexibly adjust it based on the team and project conditions. The third business layer and general mechanism should be further designed.

 

"The essence of the project is to know the truth, not to guess ." Concise and concise, but eager to continue.

 

· In other companies, the Team has Interaction designers, document specialists, process managers, and other roles. How do you do this? "If it is a very familiar product with a clear goal, you may not need many specialists. If it is an uncommon product with vague goals (at least for engineers), you need more specialists ." This is the answer given in code.

 

......

 

 

The importance of experience to software practitioners cannot be emphasized. In this book, the author unselfishly shares his experience gained from six different companies in the software industry and his 28-year career. I believe everyone can find what they need.

Http://www.china-pub.com/STATIC07/0810/jsj_dmzd_081022.asp