Pursue code Quality

When I was in high school, an English teacher said: "Writing is rewriting what others have already rewritten." "I didn't really understand the meaning of his words until college." Moreover, when I consciously adopted this practice, I began to like writing. I started to be proud of what I wrote. I began to really care about the way I express and what I want to convey.

When I started my career as a developer, I liked to read technical books written by experienced experts and wondered why they spent so much time writing code. At the time, writing code seemed like an easy job--some people (always taller than me) would give me a problem, and I would solve it in any way possible.

Until I started working with other developers on large projects, I began to understand the true meaning of my skills. That's when I started to consciously care about the code I wrote, and even the code that someone else wrote. Now I know that if you don't pay attention to the quality of the code, sooner or later they will cause me mess.

The moment that dawned on me came at the end of 1999, when I was reading Martin Fowler's influential book refactoring:improving the design of Existing code refactoring: Improving the designs of existing code, this book A series of refactoring patterns are classified, and thus a reconstructed public vocabulary is established. Until then, I've been refactoring my code (or someone else's code), but I don't know what I'm doing is refactoring. Now, I'm starting to feel more proud of the code I've written and refactored, because the work I'm doing is facilitating the way code is written and making it easier to maintain later.

What is refactoring?

In my opinion, refactoring is the behavior of improving code that has been improved. In fact, refactoring is a never-ending code-writing process designed to improve the maintainability of the Code body by improving the structure without changing the overall behavior of the code. It is important to remember that refactoring is significantly different from rewriting code.

Rewriting the code modifies the behavior of the code or even the contract, and refactoring keeps the external interface unchanged. For the client of the refactoring method, no difference is seen. Things work as before, but work better, mainly because of enhanced testability or significant performance improvements.

Active and passive refactoring

Then the question becomes, "How do I know when to refactor?" "The maintainability of a piece of code is a subjective issue. However, most of us find it much easier to maintain our own code than to maintain code written by others. But it's also controversial – maintaining your own code throughout your career is the biggest challenge. Few real "code Cowboys" are lucky enough to be able to constantly transform their work without having to modify other people's code. For most of us, the need to maintain the code of others is just part of the programmer's life. The method of determining whether the code needs to be refactored is usually subjective.

However, it is also possible to objectively determine whether the code should be refactored, whether it is your own code or someone else's code. In the previous article in this series, I described how to test code quality objectively with code metrics. In fact, code metrics can easily be used to find code that can be difficult to maintain. Once you have objectively judged the problem in your code, you can improve it with a convenient refactoring pattern.

Always Run test Cases!

The secret to refactoring someone else's code is not to make it worse. One of the things I learned in the early days of my refactoring was that it was important to have a test case before modifying something. I was through a hard night, I've been searching for a good refactoring method myself, and I learned this lesson just to find a working code that someone else has written that I accidentally destroyed, and the reason for the careless destruction is that there is no test case before refactoring. Notice my warning, always run test cases before refactoring yourself!

Extraction method Mode

In the years since Martin Fowler's book was published, a number of new refactoring patterns have been added, but the easiest model to date is probably the most efficient pattern, still the extraction method (Extract) pattern. In this pattern, a logical part of the method is removed and given its own method definition. The removed method is now replaced by the invocation of the new method, as shown in the UML diagram in Figure 1:

Figure 1. Practice of extraction Method pattern

The extraction method pattern provides two key benefits:

The original method is now shorter and therefore easier to understand.

The logic of moving away and putting it in your own way is more easily tested.