As a novice, it is natural to learn more skills in order to make your skills grow day by day! After all, many skills do not overwhelm you, and learning a few more skills can always add a lot of convenience to your work.
0. Refactoring is the main skill of programmers.
If you want to increase your brain capacity, start checking your work log.
Investigate with profiler before you can start talking about optimization.
Notes are not expensive.
Ordinary programmer + google = super programmer.
Unit tests are always cost-effective.
Don't write the framework first and then the implementation. Better to do it the other way around, distill the framework from the prototype.
The code structure is clear, and other problems are not a problem.
A good project has a hard-line style, one-click testing, one-click release, and one-click deployment; bad projects are inherently vulgar, spread by word of mouth, do not establish words, and are mysterious.
Coding Don't fear change, embrace change.
In programming, isolation is the direction, naming is the key, testing is the protagonist, debugging is the supplement, and version control is the medicine for regret.
One pawn per line of code. Only by forming a system can there be combat effectiveness. The scale of the unit should not be too large, a class of thousands, and a row of 10,000 people can easily become a mass grave.
Refactoring/optimizing/fixing bugs, only one thing can be done at the same time.
Simple modules pay attention to encapsulation, and complex modules pay attention to layering.
The human brain has limited capabilities, and neatness is better than clutter. If you don't understand the code, try to organize the format; if the interface is not easy to use, try to repackage it.
The iteration speed determines the work intensity. If you want to be faster and more economical, start by simplifying the development process and accelerating the iteration speed.
Forget about optimizing your code. Premature optimization equals vandalism; forget about code optimization. Optimize based on performance testing, not read between the lines.
The best tool is pen and paper; the next best tool is markdown.
The most useful language is English. Second might be Python.
Resources and code should be version managed together. Resource match errors are far more difficult to troubleshoot than code match errors.
Don't develop based on imagination, develop based on prototype. The value of a prototype is to quickly validate an idea and save everyone time.
Serialization prefers plaintext. Such as binary, obfuscation, encryption, compression, etc. are added when needed.
The compiler will always understand micro-optimization better than you. It can only work in the direction it is not good at.
At least half of the time will be spent on integration. Time, time, time is never enough.
When it goes against the prevailing opinion/method/style/habit, it is most reliable to examine yourself first.
If there is a bug, check it actively, whether it is yours or not. This can make your business ability soar and your personal image soar.
When I don't know how to choose a technical book, I am picky. At least it's not too expensive, and you can read it.
Log to write time and classification. And to be able to redirect the output.
Comments are slightly poor documentation. Even better is clear naming. Let the code tell its own story.
Code reviews are best done in groups/pairs. With some understanding of the business, advice would 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.
A big difference between veterans and novices comes from the ability to debug.
0. Find mistakes from the top to the bottom.
Many newbies encounter wrong program execution results (especially graphics programmers), first think that it is a machine fault (floating-point precision, hardware failure), then think that the driver is faulty, and then think that the system is faulty, and finally start to check their own. program. In fact, in 99% of the cases, there is a bug in your own program, 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 minimal. It should be checked from the top to the bottom, not the other way around.
1. The scientific method
Debug is generally aware of the phenomenon, but the cause is unknown. This is the same as in many natural sciences, so it can also be done scientifically:
Propose a hypothesis -> make a prediction based on the hypothesis -> do an experiment to confirm or deny the prediction.
Corresponding to debug, that is, assuming that there is a problem somewhere, then infer that it must lead to other phenomena than the phenomenon you see, and run the program to see if your inference holds true.
After mastering this method, debug does not become a blind trial, but a systematic and reliable method.