A big difference between an old bird and a novice comes from the ability of debugging. Among them, the most important thing can be seen from two aspects:
finding the wrong one from the top to the bottom.
scientific method.
.
Many novices encounter incorrect program execution results (especially graphic programmers). They first think that it is a machine fault (floating point precision, hardware fault), then think that it is a driver fault, then think that it is a system fault, and finally start to check their own programs. In fact, in 99% of cases, there is something wrong with your own program, and then 99% of the 1% is a bug in the system, and then 99% of the 1% is a bug in the driver. Finally, the hardware problem is very small. We should check from the top to the bottom, not the other way around.
1.
debug is generally aware of the phenomenon, but the reason is unknown. This is the same as that of many natural sciences, so it is entirely possible to use scientific methods:
Propose hypotheses->; Make predictions according to hypotheses->; Do experiments to affirm or deny predictions.
corresponding to debug, that is, if there is a problem somewhere, then inference will definitely lead to other phenomena besides what you see. Run the program to see if your inference is valid.
after mastering this method, debugging is no longer a blind attempt, but a method that can be followed by the system.
4 tips for beginners
. Refactoring is the main skill of programmers.
working diary can improve brain capacity.
use profiler to investigate before you can talk about optimization.
notes are expensive but not expensive. Put an end to the "note" like a big aunt. The rambling notes are actually background noise.
ordinary programmer +google= super programmer.
unit testing is always cost-effective.
don't write the framework first and then the implementation. On the other hand, it is best to extract the framework from the prototype.
the code structure is clear, and other problems are nothing.
Good project style is hard-core, with one-click testing, one-click release and one-click deployment; Bad projects are obscene by nature, passed on by word of mouth, and are mysterious without words.
coding should not be afraid of change, but embrace it.
always charge. There is only one way for programmers to die: the soil.
In programming, isolation is the direction, naming is the key, testing is the protagonist, debugging is the supplement, and version control is the regret medicine.
one line of code is one soldier. Only by forming an organizational system can we have combat effectiveness. The size of the unit should not be too large, with thousands of classes and 1, rows of people easily becoming mass graves.
refactor/optimize/fix bugs, and you can only do one thing at a time.
simple modules pay attention to encapsulation, while complex modules pay attention to layering.
The human brain has limited performance, and neatness is better than clutter. If you can't read the code, try to sort out the format; ? Bad interface, try to repackage it.
the iteration speed determines the work intensity. If you want to save as much as possible, you should start by simplifying the development process and speeding up the iteration.
forget to optimize writing code. Premature optimization equals malicious destruction; Forget the code and optimize. Optimization should be based on performance testing, not between the lines.
the best tool is a pen and paper; Secondly, markdown is good.
the p>leader asked about the task time, but if he couldn't answer, it might be that the task division was not detailed enough.
I'd rather count one more week than one less day. Too "optimistic" is easy to scare the boss.
the most useful language is English. The second may be Python.
seeing is believing. Draw the result at a glance. The debugging time will be greatly shortened.
resources and codes should be under version management together. Resource matching errors are far more difficult to troubleshoot than code matching errors.
don't develop based on imagination, develop based on prototype. The value of the prototype is to quickly verify ideas and save time for everyone.
serialize the preferred plaintext. Such as binary, obfuscation, encryption, compression, and so on.
compilers will always know more about micro-optimization than you do. We can only work hard in the direction it is not good at.
don't make plans that are too big, too far and too detailed. Even if it is decided, it is useless.
at least half the time will be spent on integration. Time, time, time is always not enough.
when it goes against the mainstream opinion/method/style/habit, review yourself first.
take the initiative to check bugs, whether they are yours or not. This can make your business ability soar and your personal image soar; If your bug is found out by others ... hehe, you will be very passive ~ ≧≦
You will pick thin when you don't know how to choose technical books. At least it won't be too expensive, and you can finish it.
git is the best. Simple, reliable and free.
only assert "predictable irrationality".
the time and classification to be written in the p>Log. And be able to redirect the output.
comments are poor documents. Even better is a clear name. Let the code tell its own story.
making wheels is a good exercise method. If you have seen other wheels.
code review is best in the form of group/pair. With a certain understanding of the business, suggestions will be more valuable (but not absolute). And it won't be a burden. The administrator's personal review can easily become the bottleneck of the team.
do research before asking questions. Not asking questions is both despised and a waste of your time.
Never underestimate Cheng Xuyuan (╯3╰)!