Three personal experiences on code Quality

Martin Fowler said in chapter 1 of his book refactoring to improve the design of existing code, "Any fool can write code that can be understood by computers. Only good programmers can write code that is easy to understand ." Kent Beck also described himself as "I am not a great programmer. I am just a good programmer with some good habits ." I have been writing code for more than three years since I was a bachelor's degree, and I have been learning programming for more than three months, plus seven months of practice and three months of work, it is more difficult to write code with high readability and few defects. Although "Software Engineering has no silver bullet", there are some ways to make up for it. The method is what Kent Beck says to cultivate some excellent programming habits. When I write some code, I always think that the code is very simple, and the functional logic is very simple. So I write all the code and run it again. However, in 90% of the cases, I was disappointed with the results. After repeated attacks, I began to become more confident and gradually lost. I also began to think rationally about how to program to ensure efficiency and improve code quality (strong code readability and low defect rate ...). Here are my three experiences:First: code review. Note that you can review the code immediately after it is written.
For example, if a method has more than a dozen lines of code, you can write this method and review it. Review reviews the code branch, which is equivalent to compiling and running the human brain. If a method is long, you can split the method into several parts and review each part. This can avoid many seemingly mentally retarded mistakes. For example, when writing code that returns a Boolean value, the return value is often set to false. As follows:

public boolean test() {   // TODO   return false;}

Then, complete Part Of The todo code:

Public Boolean test () {// return false for a large segment of processing logic ;}

In this way, I immediately call test () elsewhere, but I found that the test method always returns false. I had to perform one-step debugging to find that I had a very mentally retarded problem, you know. If I do not rush to run the program after writing this code, but first perform static Review of the Code, this low-level error can be completely avoided.
Second: refactoring, and continuous refactoring.
I have always thought that refactoring is helpful for improving the quality of code, but in fact there is no concept of refactoring, and I have never really practiced much in actual coding. However, I tried to refactor two examples to find that refactoring is indeed powerful. It can improve code readability and deepen your understanding of the Code business logic, this reduces the chance of introducing bugs. If refactoring is used properly, you can strike a good balance between code conciseness and code readability. For specific examples, see:
Discussion on basic programming issues: the trade-off between code readability and code concisenessHttp://www.oschina.net/code/snippet_111708_15532
   Discussion on basic programming problems: Double Loop writingHttp://www.oschina.net/code/snippet_111708_15531

   Third: test the driver.
Sometimes I write hundreds of lines of code from the front-end page to the back-end business processing, and then run it. A small problem occurs, and then I track it in a single step and fix it. Run again, no problem, OK release, submit for test. Then, after a test, all kinds of problems come back to me one after another. After thinking for a long time, I finally found that the test driver should be a good way to avoid this dilemma. According to my previous "hitting big run" programming, I can only ensure that one or a limited number of processes (or branches) run correctly. In fact, there may still be many "time bombs" in the code ". With the help of the test-driven development method, I can test each piece of data to ensure that each piece is correct. Then, the integration test is obviously better. It is also important to know that fixing bugs often takes more time than writing code, especially when the system runs for a long time before discovering bugs (at this time the system is not so familiar with it) or the bug fix by the non-code first author is more obvious.

Common Unit testing tools include JUnit for Java, nunit for C #, and unit testing for vs 2010 and later.