How often do you feel the development time is tight and the product is always on the shelf? This leads to a series of difficult code maintenance and complex requirements iteration. What happens when you end up developing code that no one dares to touch? If YES, the rest is worth reading. Although there are many reasons for this phenomenon, such as frequent requirements change, overly optimistic estimation time… And so on. But next, I will summarize the development experience from the module of code improvement and improve the development efficiency by more than 50%.

Who ate all our development time

In some projects, debugging can take up to 50% of the entire development cycle. For many programmers, debugging is the most difficult part of programming. Debugging should not be the hardest problem to solve if code specifications are strictly followed. So from the beginning you should follow the code specification to improve the quality of your software and avoid debugging. If debugging is inevitable, I’ll summarize some of the techniques I use to debug projects that save you more effort than the usual ones

Debugging means to help you save more debugging time

Why talk about debugging? Is there anyone who doesn’t know how to debug? True, not everyone knows how to debug. One study showed that experienced programmers found the same set of defects in about 1/20 of the time that less experienced programmers did. And some programmers can find more bugs and fix them more accurately. So the significance of discussing scientific debugging methods can be imagined. Scientific debugging methods will be introduced next.

  1. Code reading: A study by NASA’s Software Engineering Laboratory found that reading code detected about 80% more bugs per hour than testing, and a study by IBM found that checking a bug only took 3.5 work hours, compared to 15 to 25 work hours for testing. So you need to read the program you are writing, and if you really understand the code thoroughly, it is impossible to make mistakes, and you should have corrected them long ago. Or you could have found it by reading the code. The thinking itself is much more efficient and fun, so debugging is not just printing.
  2. Five even ask: each debugging repair error will be issued after their own five even ask: why can make such a mistake? How to catch this bug faster? How can such errors be prevented? Is there another similar error in the code? Can mistakes be killed before they cause trouble? When get into the habit of this summary, you will find that the things you want to debug will be less and less, because you are belong to which kinds of defects can clear the defect, I proposed, after the commissioning repair defects, submit code, take five even asked the answer as to submit code, on the one hand is your summary of the commissioning repair, In summary (similar to pair programming) you may suddenly discover another bug, which on the other hand makes it easier for the team to review your code.
  3. Examine your approach to fixing a bug: Are you just putting a patch on a bug? Instead of getting to the root of the problem and addressing the defect at its root, which is why it is only a symptom rather than a root cause (this method of fixing the defect will go wrong sooner or later), or is it a precise analysis of the root cause of the problem and the right remedy? (This is the standard bug fix method.)
  4. Scientific debugging methods: a. Collect data through repeatable experiments => Construct a hypothesis based on the statistics of relevant data => design an experiment to prove or disprove the hypothesis => Prove or disprove the hypothesis => Repeat the above steps as needed. B. Stabilize the fault. => Determine the faulty data source. => Repair the defect

Debugging is a fertile ground for your progress, and it’s where all the key software paths intersect: readability, design, software quality, you name it. If you do this, you’ll spend less time debugging, or even less time debugging.

How to avoid debugging

Since debugging takes so much time and effort, why not avoid it? Debugging itself doesn’t improve code quality, it’s the price you pay for not coding properly. Ensuring software quality is an effective means of avoiding debugging, and software quality must be established gradually from the beginning: the best way to develop high-quality software products is to accurately describe requirements, improve design, and write specifications with high-quality code. Debugging is only a last resort

Ensure software quality

Collaborative Build: “Collaborative Build” includes pair programming, formal reviews, informal technical reviews, document reading, and other techniques that let developers share responsibility for creating code and other work products. The primary purpose of co-programming is to improve software quality.

  • IBM found that an hour of code review saves about 100 hours of related work (testing and bug fixing)
  • HP reports that its formal inspection program saves the company about $21.5 million a year.
  • Imperial Chemical found that the cost of maintaining all the documentation for 400 programs was only a tenth of the cost of maintaining similar, unchecked programs
  • One study of large programs found that an hour spent on a formal inspection saved an average of 33 hours of maintenance work and inspection performance was 20 times better than testing
  • Before the introduction of code review, 55 percent of single-line changes in a software maintenance organization were wrong. With the introduction of code reviews, that number dropped to 2%. If you consider all types of changes, 95% of the corrections after the introduction of review are correct once. Before it was introduced, only 20% were correct once.
  • The same team developed 11 programs and released them into the product. The first five were not reviewed and averaged 4.5 errors per 100 lines of code. The other six were reviewed with an average of 0.82 errors per 100 lines of code. Review eliminates 80% of errors.

Various studies have shown that collaborative development is not only more effective than testing in catching errors, but also in finding different types of errors. Collaborative development can uncover a lot of hard coding, inappropriate annotation, and duplication of code that needs to be homogenized that testing doesn’t find. Another effect of collaborative development is to make people aware that their code is being reviewed, so that they can carefully check their work. Collaborative builds help to impart corporate culture and programming expertise, and reviews can quickly elevate all developers to the level of the best.

Developer testing: You have to expect bugs in your code. Although this expectation may seem counterintuitive, you should expect it to be you, not someone else, who makes the mistake.

  • Test each of the related requirements to ensure that they have been implemented
  • Test each relevant design concern to ensure that the design has been implemented.
  • Use a checklist of the types of mistakes you’ve made so far in the project, as well as the types of mistakes you’ve made in past projects.
  • Boundary value analysis, the idea of boundary value analysis is to write some test cases to test boundary value conditions
  • Test for several types of bad data (too little data, too much data, bad data conditions (invalid data, null, undefined, etc.), data of wrong length, uninitialized data)