Turn: Enhance the debug capability to improve work efficiency

Address: http://yaocoder.blog.51cto.com/2668309/1210546

In my opinion:It is very easy to make a business function, but it is difficult to do well and to do well efficiently.Aside from the preliminary architecture design and technical solution formulation, we just need to write well.CodeThis stage brings different levels of challenges to each of us. I have also written an article about the coding stageArticleThe "class" tool for improving work efficiency, I will talk about my views from the perspective of code debug below.

• Avoid bugs and reduce debugging when writing code as much as possible
  Prevention is the primary priority for any problems. This kind of colleague can often be seen in the team. The code is written very quickly, but after the empty code, it puts itself into the swamp of endless debugging. I would like to advise my colleagues that they should spend more time designing code structures, review code frequently, and be careful.

• make good use of IDE and tools
  I often hear that vim and Emacs look down on IDE, I think Vim .. it's just silver bullet. No matter what language or platform, as long as you ask him what IDE is best, he will definitely answer you Vim... Of course, it is not ruled out that there are people who can use Vim. Most of the others are installed with X. Remember, your goal is to complete the work, not to show yourself how high-end, how cool X. Similarly, GDB. A suitable ide has many advantages: Error prompts, Code Completion, rich replacement searches, and various associated jumps. Of course, if you are not too troublesome, if you are not afraid of inaccuracy, you can configure Vim to achieve the same effect. However, please read this article before making a decision on Editor and IDE. the benefits brought by the above several ides are not exactly significant to the "Avoiding bugs as much as possible" mentioned above. In addition, the debug interface integrated by IDE is friendly and powerful (friends who have used GDB certainly know), breakpoint, step over, step into, memory variable, call stack... this is a debug artifact. At least the standard steps for writing the Program Read Programs depend on these steps. ( It is exaggerated, but I have met many people, including engineers with many years of work experience, who have never used breakpoint debugging, I walked around with printf, and my "surprise" was like a great river... ) in debugging, other tools can make debugging more efficient, such as memory leakage detection tools, there are also various tools for network programming (wirshark, Netcat, tcpdump ...)

• Program output log
  I think the log system should also be a standard component of a program. Its biggest use is to help us sort out program behavior and accurately locate bugs. Some friends have asked, I can use IDE for debugging and observation. The problem is that many bugs are not found when you write code for testing, but are found by users after the release, dumb, right? Another important point is that the problem of multithreading and other problems that depend on the specific system environment or time environment is hard to reproduce. If you can't catch it this time, just wait for your patience. I have been using Apache's log4x series at work, and it is another powerful artifact. However, log4x cannot be used in some environments. For example, in some embedded environments that are sensitive to the space occupied by applications (the log4cxx dynamic library is large ), you can use the standard output to encapsulate the corresponding log system, and then perform targeted output during running.

• Crash Dump
  The major fatal-level bugs such as crash are the biggest headache. in C/C ++, memory violations (segment errors) are the cause. This bug is also the most difficult to find, so we must locate it as accurately as possible. The most effective way is to use the memory dump file. On the Linux platform, you can use GDB core to perform Location Analysis. Windows is troublesome. You have to implement the memory dump function by yourself. We recommend you use mini_dump as a tool. Once the program crashes, a dump file will be generated, and then you can use windbg for debugging.

• Google
  Many bugs cannot be fixed or fixed by thinking about various methods, so you have to ask Google. Do not use Baidu as much as possible. If there are few or no Chinese search entries, you may find more gains if you change to an English search.

• Question
  I gave my team members such a suggestion: If you try a problem yourself, you can also Google it, but it cannot be solved. If you have spent more than an hour on this issue, please feel free to seek external help and ask experienced Members in the team. Maybe he has met, maybe he will provide you with good suggestions or ideas.

• Deep Learning
  In fact, it is more appropriate to go to the top of the line, so you should first go deep into learning and then do the corresponding work. However, in our actual work, we often encounter problems and study them in depth. I think the formation of many bugs is caused by our ignorance or even ignorance of knowledge, we should try our best to abandon that kind of temporary learning. Instead, we should continue to learn and study in depth in our own career.

The above are some of my views and practices on improving the debug capability.