The Pragmatic Programmer: from work to read expert notes 01

    "Programmers practicing the Road," this book use a lot more interesting examples, explain some aspects of software development, software development, there are many practical aspects of skills and he also has some pitfalls, the book covers a lot of different content , personal responsibility, career development and a number of infrastructure technology. This book is a start and did not teach us how to program, but tell us some truth, these things are important in our future programming.

     "In all the weaknesses, the biggest weakness is the fear of weakness." Remark makes sense, in the programming process, our program will be the inevitable variety of errors and even modify our time than our programming bug much longer time, the face of these mistakes, we can not escape. Should stop, constant changes, I do not understand a question timely to others, perhaps with the help of others, we can find the root of the problem, and get rid of this problem, which is our future learning and life is very big help. Among the living, everyone is perfect, when people discover our problem, it is correct, it would be able to be raised.

     In programming, there will certainly be big or small problem, when there is a problem, we should stand up and take the initiative and solve the problem together, not shirk its responsibility, courage to take responsibility as a programmer is essential. We have to be strict with their own code standards, it will also save a lot of time for the development team.

    A program is impossible to be perfect, we can not superfluous in the beginning of the design, in fact, the basic needs of users, so it has been very good. Sometimes, we are always looking for software to be perfect, but overly complex procedures, the greater the risk of problems that may lead to problems because the most basic functions are not implemented in the software development process, we also We should always be to communicate with users, continue to be corrected according to the user's requirements, as long as the user satisfaction ultimately, the task has been completed very good.

     DRY principle (Do not Repeat Yourself Do not Repeat Yourself), the system must have knowledge of every single, unambiguous, authoritative representation. Orthogonality can be a good test, reduce the dependence between the parts, there is a problem when one module, this module only need to change it, do not need to change a lot of code, so you can save a lot of time.

     If you do not clear when. The classic approach is to set the system to die. Making a large number of documents, listed individually for each demand, to identify all unknown elements, and define the environment. Code luminescent in the dark, to find the target with a tracer. This can make debugging and testing becomes more efficient, and can feel the progress of the work, there is enough power to complete the next target.

     When we develop software, we will be estimated, the software developers have to spend a long time. But the precise estimated time is almost impossible, we need to use their own or other people's goals, build the model, the model for the formation of understanding, will be divided into smaller tasks, the computation time required for each small task, then they add up.

     Before that he wrote when programming job, and did not pay attention to the estimated completion time, always until completion, there is no plan to do so, but also the efficiency is very low, because there is no goal, not their programming skills It has greatly improved. In future programming, we must first estimate the time to complete their own before, look after yourself if completed within the stipulated time, develop good habits, constant corrections to improve their efficiency.