Big talk reconstruction and serialization 5: Four motivations for Software Modification

Software, since it was developed and delivered and used by us, if it runs well, we will not modify it. If we want to modify the software, there are four motivations:

1. Added new features;

2. The original functions have bugs;

3. Improve the structure of the original program;

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

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

The external quality of the software is measured by the customer's satisfaction with the functional and non-functional requirements of the software. It involves the credibility and vitality of an enterprise and software, so it is highly valued by all software companies. However, while all corporate executives put the external quality of the software above all levels, the internal quality of the software has been ignored for a long time. Enterprises do not have any measures to ensure the internal quality of software, or even drop the internal quality standards as they need to work in a hurry. The long-term consequence of this is that programming is getting worse and worse, the running efficiency is getting lower, and the program structure is getting increasingly incomprehensible. When a group of just-graduated college students were wandering in this pile of poorly written code, they began to sink and began to naively think that the code was written like this (it was really broken ). When our software companies cultivate a batch of low-quality developers and develop low-quality software systems, they begin to find that software maintenance costs are getting higher and higher, in the end, I had to reap the evil consequences I had planted.

To improve the internal quality of the software, there is no doubt that the third motivation for software modification is to improve the structure of the original program. Its value is implicit, not reflected in one or two development processes, but gradually reflected in the long-term maintenance of the software process in the future. High-quality software ensures that developers (even new users) can easily understand the software code and can easily complete every software maintenance in the future (no matter how many changes the software has undergone, years of maintenance), which ensures that every demand change in the future can be easily implemented (rather than making a huge change ). It is not easy to achieve these points. We need to constantly optimize and improve the internal quality of the system. This is the value of system restructuring.

In order to effectively improve the internal quality of software, what should we do in system restructuring? The first is to improve the readability and ease of reading of the software. The software should be readable. It is not as simple as adding several lines of comments. First, the business logic of the software should be clear. A business process may be complicated. If a function is written down one row in sequence, hundreds or even thousands of rows may be required. For example, we need to implement the following requirement: Read XML from one or more configuration files like spring, create every bean Based on XML, and put every bean into beanfactory. It would be hard to think about how to implement this function without being carefully designed, but writing a line at will. However, if we change our thinking, we can only call several top-level methods in the entry function, such as findxmlfile (), readxmlstream (), and buildfactory (), and then implement these top-level methods in sequence, the program structure becomes clear and easy to read. See the sample code below:

1 public abstract class xmlbuildfactorytemplate {2/*** 3 * initialize the factory. Read the XML file according to the path, and load the data in the XML file to the 4 * @ Param path in the factory. The path of the XML file is 5 */6 Public void initfactory (string path) {7 // find the XML file and read the data stream 8 inputstream = findxmlfile (PATH); 9 // parse the XML file and return the root 10 element root = readxmlstream (inputstream ); 11 // create a Class Based on the XML file and put it into the factory 12 buildfactory (Root); 13} 14/** 15 * to read an XML file, output the data stream 16 * @ Param Path of the XML file 17 * @ return inputstream file input stream 18 */19 protected inputstream findxmlfile (stringpath) {20 ...... 21} 22/** 23 * read and parse an XML file input stream, and get the XML root as an element, return 24 * @ Param inputstream file input stream 25 * @ return elementxml root 26 */27 protected element readxmlstream (inputstream) {28 ...... 29} 30/** 31 * build a factory with data read from an XML file 32 * @ Param root the root 33 */34 of the data read from an XML file protected abstract void buildfactory (element root ); 35}

When implementing these top-level functions, we will break down some relatively independent functions to form classes and interfaces, such as findxmlfile (), it may search for XML files in various ways. In this case, these functions are extracted to form the resource interface and its multiple implementations (as shown in 1.1), which are called by findxmlfile. If we design this complex feature like this, there is no doubt that the system readability will be greatly improved.

Figure 1.1 design diagram of a factory Template

In addition, in the object-oriented world, the classes, methods, and associations we design should correspond to the things, actions, and their relationships in the real world. What are the things in the real world, what actions should these things have, and what is the relationship between them, in the software world, we should design classes, methods, and associations between them. Only such a design is the most understandable design. This is the idea of "domain-driven design" [1]. In system restructuring, we will use the "Extraction Method" to break down the big functions that are difficult to read and maintain, and use the "extraction object" to break down the omnipotent large objects.

Another task for system restructuring is to make the software easy to maintain and change. Software requirements always become increasingly complex, which is an objective fact that cannot be changed. When adding new functions, we must ensure the validity of the original code and reuse the original code effectively. What a conflict! What should we do? Let's see, I will break it down for you in the next step ......

[1] domain-driven design (DDD: domain-drivendesign) originated from the design idea proposed by Eric Evans, a software theoretical master, in his book of the same name published in 2010.

Big talk rebuilding serialization home: http://www.cnblogs.com/mooodo/p/talkAboutRefactoringHome.html

Note: I hope that the author or source should be noted to show my respect for the author when I reprint this article. Thank you!