Four motives for refactoring serialization software modification

Software, since we have been developed and delivered to use, if it works well, we will not modify it. We want to modify the software, same, nothing more than four kinds of motives:

1. Add new features;

2. The original function has the bug;

3. Improvement of the structure of the original procedure;

4. Optimize the performance of the original system [1].

The first and second motivations are derived from the customer's functional requirements, and the fourth is derived from the customer's non-functional requirements.

The external quality of the software is measured by the customer's satisfaction with the functional requirements and non-functional requirements of the software. It involves an enterprise, a software credibility and vitality, so for all software companies attach great importance to. But at a time when all executives put software external quality above all else, the internal quality of software has long been overlooked. Enterprises do not guarantee the quality of internal software measures, and even because of the need to rush to reduce the internal quality of the standard. The long-term consequences of this is that the process of writing more and more rotten, running more and more low efficiency, the program structure more and more people can not understand. When a group of newly graduated college students wander through this heap of poorly written code, they begin to sink in and begin to naively think that's how the code is written. When our software enterprises cultivate a batch of quality of the developers, the development of a low quality software systems, they began to find the software maintenance costs more and more high, and ultimately have to reap the consequences of their own species.

To improve the internal quality of the software, there is no doubt that the third motivation of software modification: to improve the structure of the original program. Its value is recessive, not reflected in one or two times development, but gradually embodied in the future long-term maintenance of the software process. High-quality software ensures that developers (even novices) can easily read software code to ensure that every future software maintenance can be easily completed (no matter how many times the software undergoes changes and how many years it is maintained), To ensure that every change in future needs can be easily done (rather than bones). It is not easy to do these things, it requires us to continuously optimize and improve the internal quality of the system. This is the value of the system reconfiguration.

In order to effectively improve the internal quality of the software, what should we do in the system refactoring? The first is to improve the readability of the software, easy to read. Software to be readable, not to add a few lines of comments that simple thing, first of all, the software business logic should be clear. A business process may be very complex to process, and if you write it sequentially in one function, you may need to write hundreds of or even thousands of lines. For example, we want to implement a requirement that reads XML from one or several configuration files, like spring, and then creates each bean in sequence based on XML, putting each bean into beanfactory. It's hard to think about hundreds of thousand lines of code to implement this feature if you don't design it carefully, but write it in one line. But if we change our mind, just call a few top-level methods in the entry function, such as Findxmlfile (), Readxmlstream (), Buildfactory (), and then implement the top methods in turn, the program structure becomes clear and readable. Take a look at this sample code:

 public abstract class Xmlbuildfactorytemplate {/** * initial chemical plant. Reads the XML file according to the path, loads the data from the XML file into the factory * @param path XML file paths */public void Initfactory (String path) {//Find XML
        file, read data stream InputStream InputStream = findxmlfile (path);
        Parse XML file, return root Element root = Readxmlstream (InputStream);
    Create a class from an XML file and put it in a factory buildfactory (root); /** * Read an XML file, output its data stream * @param path XML file paths * @return InputStream file Input stream * * Protected input
    Stream Findxmlfile (Stringpath) {...}
    /** * Reads and parses an XML file input stream, obtains the root of the XML in the form of an element, returns the * @param inputstream file input stream * @return Elementxml root * *
    Protected Element Readxmlstream (InputStream inputstream) {...} /** * Build factory with data read from an XML file * @param root of the data read from an XML file/protected abstract void Buildfactory (Elem
ENT root); }

When implementing these top-level functions, we will also break out some of the more independent functions to form classes and interfaces, such as the Findxmlfile (), which may look for XML files in various ways, and then extract these functions Form the resource interface and its multiple implementations (as shown in Figure 1.1), called by Findxmlfile (). If we design this complex feature, there is no doubt that the system will be much more readable.

Fig. 1.1 Design diagram of factory class template

Furthermore, in an object-oriented world, the classes, methods, and associations we design should correspond to things, behaviors, and relationships in the real world. The real world has something, these things should have what behavior, what is the relationship between each other, we in the software world should design what class, what method and the relationship between them. Only such a design is the most easily understood design, and this is the idea of "domain-driven design" [1]. In System refactoring, we will use the "extraction method" to decompose large functions that are difficult to read and maintain, and "extract objects" to decompose large, omnipotent objects.

Another thing to do with system refactoring is to make software easy to maintain and easy to change. Software requirements are always getting more complex, which is an objective fact that cannot be changed. While adding new features, we need to ensure the validity of the original code, but also to effectively reuse the original code. What a contradictory thing it is! What do we do? See I step by step in the back to you decomposition ...

[1] Domain-driven design (ddd:domain-drivendesign), derived from the design ideas presented by Eric Evans, a Master of software theory, in his 2010 book of the same name, is widely mentioned in this article.

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