The most real is the program, right is right, wrong is wrong, not for any reason and change. The article has been trying to make a results-oriented programmer, and the results-oriented programmer will tell himself that a mistake has happened that it has been a very bad thing. Each programmer tells himself something that is not likely to happen when writing code, so it simplifies these questions when writing, and does not want to have any problems with these neglected things. Use an assertion checker to check for things that never happen, but you can't use assertions instead of a real error-handling method. Exceptions are also encountered during the process of running the program. Always thought that the exception is not wrong too. But for this book, feeling abnormal is also very useful, reasonable use, can let abnormal play the unthinkable benefits.
When learning the data structure, the teacher always mentions the efficiency of the algorithm, and now it is not clear how the efficiency of the algorithm is calculated. The algorithm is efficient, then must be good for their own programs? That is not to be certain. This once again puts forward the programmer to learn to consider both theoretical issues and practical issues. The algorithm should be considered together with practical problems and procedures.
The teacher has been training us for the team this semester. Individual projects are generally based on interests and hobbies. And good project development will not open the team, the importance of the team is self-evident. To do a good team development, we must learn to communicate with you, learn to trust the other members of the team, of course, you have to do well. Oh, I'm still very far away.
This book read down, learned a lot of things, the author has been repeating a results-oriented programmer, in the future in writing programs to pay more attention to. Learn to apply it in practice.
"Programmer's way of practicing--from small to expert" read Note 3