What is System refactoring

We mentioned earlier, in the face of the advent of the software industry, our software companies into a deeper confusion, a "after the pursuers, before a cliff, dilemma" situation. After the following: In the face of the maintenance of decades of large legacy systems, whether we change or not change? In the face of more and more changes in demand, our maintenance costs are becoming more and more difficult, and the face of the emerging new technologies makes our system look uglier and more backward, facing more and more competitors, we are faced with the risk of being eliminated by the market. Before the cliff: The original operation of a good software system, make up for a few years can also run. Accidentally changed the problem, the enterprise immediately stop vegetables, face a large number of user complaints, enterprises around the fire, competitors, this is any software enterprises can not afford the huge risk. Baffled really "bear's paw and fish can't have both"? Is there really no way to ensure that our system can be reformed and effectively avoid the risks of the transformation process? Yes, that's system refactoring.

When it comes to refactoring, many people are secretive and respectful. What is a system refactoring? You may have a lot of different views:

1. The system reconfiguration is those system architect, the technology Daniel plays the high-end thing, our ordinary cock silk does not understand, has nothing to do with us.

2. System reconfiguration is to change the code, the big change that kind of, the whole again that kind, this is more evil, more easy to change things, or not easy to try for the wonderful.

3. I know the system refactoring, also know that it can improve the legacy system, but I still do not dare to try, because the problem to do, or forget it.

However, I think that now we have so many misconceptions about system refactoring that we don't know it very well enough to shut it out. What is a system refactoring? It is a rigorous and safe process method, which ensures that the software can be optimized without introducing new bugs and guaranteeing the quality of the software transformation through a series of effective methods and measures. This is one step in the next step in the disassembly, you can slowly realize.

Let's look at the concept of system refactoring first. System refactoring is to change the internal structure of the software without changing the external behavior of the software, making it easier to read, maintainable and easy to change [1].

One of the key prerequisites of system reconfiguration is "do not change the external behavior of Software", which is very important, which ensures that we will not bring new bugs to the original system while transforming the original system, so as to ensure the security of the transformation. Here, what is "bringing new bugs to the original system"? We have to make a strict definition of it, that is, "change the original external behavior of the software." Perhaps you have some disagree with this, changed the original external behavior of the software, how can arbitrarily think, is for the original system brought new bugs? So let's take an example.

If a system of report query function, originally in the form of the return results, the date is such a "2013-2-18", after the system transformation into such a "2013-2-18 00:00:00", this is a bug? As a developer you might think this is a bug, but as a customer it's a bug because it makes the tables look ugly and not easy to use. System refactoring, for customers should be completely transparent. We do a lot of work for it, and they should not feel it at all. If our refactoring does this, then our refactoring is necessarily safe, reliable, and risk-free.

More generally, if we open the inside of the software, we guarantee that each interface in the system is equivalent to the prior transformation, that is, its input and output are consistent before and after the transformation. When each of our transformation is done this way, it is inevitable that the system will not bring new bugs. This is the insurance cord that we've been revamping, and it's the fundamental difference between what I'm talking about as refactoring and the way I used to take code.

All in all, system refactoring is not the kind of code modification that runs at great risk, it must be consistent with input and output before and after the modification, which is what we call "no change of external behavior". To this end, throughout the refactoring process is continuous testing. At first this test was hand-tested and then gradually turned into automated testing. Each change a little bit to do a test, and then modify a little bit. Test, is the system reconfiguration of the insurance cord.

[1] refactoring:a changemade to the internal structure of software to make it easier to understand Andcheaper to modify W  Ithout changing its observable behavior. --A quote from refactoring: improving the design of existing code

This column more highlights: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/