The second chapter book review
I recently read "The Pragmatic Programmer - from small work to the experts," this book, read the second chapter, let me software for programming have a deeper understanding and awareness, benefit, here is what I the resulting second chapter of this book in the sense.
The second chapter is entitled "pragmatic approach", the chapter is divided into seven sections, each section has a principle, steadily interlocking, step by step in depth for our in-depth introduction to some of the pragmatic approach, As long as we remember that during programming of these basic principles, we will be able to write faster, better, more robust code, and even you can make these look easy.
(7) Chapter VII of the section, tell us about the dangers of repeating, reminding us everywhere not to be repeated in the knowledge system. As a programmer, we collect, organize, maintain, use of knowledge, unfortunately, knowledge is not stable, changes often occur, all of which are unstable means that we have to spend a lot of time on maintenance, re-organize our expression system knowledge, for whatever reason, are not maintenance activities from time to time, but the entire development process routine, when maintenance, we must find the relevant knowledge, and make the appropriate changes, if we in the development of the process is repeated excessive use that knowledge to maintain them will become very troublesome, if we do this, we are in an invitation to maintenance nightmare, a nightmare that began before the release of the application. For this reason we should fundamentally prevent such a nightmare, put an end to re-use the same knowledge to program development. A reliable software development, and make it easier to understand and maintain the only way is to follow the DRY principle: the system must have knowledge of every single, unambiguous, authoritative representation forehead. This is one of the essential principles of pragmatic programmers. Authors introduce us to a variety of repetition, and repetition is how it happened, so that we can try to avoid duplication, away from the nightmare.
(8) The eighth section, as we are talking about are orthogonal, what is orthogonal? In computing, the term for almost independent or not in some decoupling. If a change occurs two or more things, and these things is orthogonal, in a well-designed system, the database code and user interface are orthogonal, you can change the interface, without affecting the data, change the database without changes to the interface. An orthogonal system, not only can improve the productivity can also reduce risk. This is the orthogonality principle. Orthogonal principles and DRY principles are closely linked, use DRY principle, you can ask the system to minimize duplication, orthogonal principle, you can reduce the interdependence between the various components.
(9) The ninth Summary talking about the reversibility, and about the importance of a flexible architecture for us, as a qualified programmer, project development time not only to ensure the flexibility of the code, but also to consider maintaining the architecture , deployment flexibility and integration in areas such suppliers.
(10) Then as we introduced the tracer, prototype and notes as well as the field of language and the ability to estimate, these are a programmer need to learn and master, whether it is team development or academic exchanges, which are particularly important, especially It is the field of language, which he represented you in this circle basic image, and how to estimate the project progress in project development, make a correct assessment of the project, which is very important.
The above is what I feel resulting from Reading.