Read it again and feel a lot

Read it again and feel a lot

I remember the first book I got from my company when I first started my work four years ago. This book is the "Programmer cultivation path" (English version). As a learning material for study group, at that time, I learned this book with other colleagues under the leadership of senior engineer. Although I have heard that this is a good book before, I only thought it was justified when I was reading it. But it is natural that I have to spend so much time talking about it. Why? So I just threw it to the other side.

I have also read many similar books later. "Programmer cultivation path" has always been a necessary learning material for newcomers in the company, but I have never re-read this book carefully, the English version of the year was not displayed on the bookshelf until the English version of the year was sent to me by Mr. Yan last week. He carefully read the English version of the year against the Chinese version.

This re-reading has a lot of feelings and can quite understand why the company has always chosen this book as a new textbook.

Although this book only contains a lot of seemingly simple truths, it is actually a painstaking summary of some experiences. For example, everyone knows that they should not ignore the broken windows of their own house. But in reality, they have heard too many compromises: This code is already like this, and they can only stick ugly workaround on it, this is actually a type of shirking of responsibility and not responsible for the future. Of course, the reality is imperfect. Sometimes the fire fighters have to put down their windows and accommodate others. But as a pragmatic programmer, it is necessary to maintain a perfect mentality, we will pursue the beautiful code, the design, the orthogonal implementation, the dry (don't repeat yourself) principle ......

About dry, I 'd like to say, not only don't repeat yourself, but also don't repeat others. We see too many stories about repeated wheel creation, as mentioned in the book, as a pragmatic programmer, reasonable use of tools, libraries, and the wheel of development accumulated by myself will continuously improve the producticategory. This reminds me of the awesome "cool man" in the company. Everyone has been trying to share the cache in the product process into multiple processes. When we are discussing how to do this, "Niu Ren" has been completed in just a few days, and everyone worships him again. The "cool" actually has a lot of ready-made code. To do this, you just need to reuse the encapsulated modules that have been accumulated.

Another method cited in the book: drag bullet. I used prototype before and hesitated to reuse the code. In principle, prototype code should be discarded, but sometimes some work done in the early stage is to determine the scheme and build the framework, and these are also the basis for later work. In fact, whether prototype or drag-and-play is worth careful consideration in the early stage of the project depends on their application scenarios (for product development, the application scenarios of drag-and-play may be more ).

Of course, for the Management (Knowledge investment), communication and communication importance of knowledge assets mentioned in the book, I think this is not only applicable to programmers, anyone who wants to make a difference has to say more about the importance of these aspects. The experience in automation and text processing is also the experience mentioned in many books (such as Unix programming art and effective programmers ).

Finally, let's talk about this book's translator mavida. I first read his translated ace documents and related materials at school, with a lot of benefits. Ace can be described as a collection of network programming technologies, this "the way to practice programmers" can be described as a set of programmers who have elaborated on various aspects in this book from project management, software architecture and design, code writing and testing. The translation quality of this book should be accurate and basically true to express the meaning of the original book. However, due to literal translation, some statements may be difficult to understand, such as p146, "as long as it is well known and acceptable for those modules that are coupled together, your design will be fine." However, read this book carefully, and these obscure contents can still be understood. Of course, the translator can still add some "Comments" to make it easier for readers to understand and make the content smoother. For example, if the book directly uses Gulu to translate guru, it may be better to add explanations; for example, law of Demeter is not clearly explained in the original book. It may be easier to understand it if you add more explanations.

I would like to thank Mr. Zhou for giving me the opportunity to repeat this excellent book and improve my understanding in order to complete my homework.

Trend Micro stuff engineer Fei