Analysis of multi-version software construction strategy

Original: Multi-version software construction strategy analysis

A software building strategy that focuses on analyzing multiple versions of features. Multiple version features in some cases only correspond to the localization of software, the complex situation is that different versions of the module's business logic, rendering policies are not the same. This not only increases costs in the product development process, but more costs are reflected in the maintenance phase. Therefore, it is important to choose a suitable construction strategy to reduce the cost of development and maintenance.

First, the traditional software construction strategy

Different versions use different code, either by derivation or directly using different code implementations. Each version corresponds to a copy of this version-related code. When the code is released into the product, we also need a build process to publish the source package as an executable file.

The code that embodies the multi-version feature may be simple and complex, and the key is to see how the software as a whole is designed to support multiple versions.

1.1 Implemented with Strategy mode

Module A can access local policies, implement LOCAL1, Local2 to achieve specific user requirements according to different versions of the differences.

There are a few problems here.
First, the hierarchy in the system is very complex, if the module e also needs to determine its own behavior according to the version characteristics, there may be two ways: pass the ilocal layer, from a to C to E, the use of singleton mode. However, both of these methods undermine the encapsulation of the object.
There will be a lot of methods in ilocal. All version differences in the system will be placed in the Ilocal method, and soon these methods will be out of control. Is it possible to classify the attributes, and putting a certain class of features into an interface can reduce the administrative cost of ilocal, but does not fundamentally solve the problem.
The local implementation class will become bloated as the project progresses, or during the maintenance process. After a few years in the project, this becomes a stubborn disease.

1.2 Using compilation directives

Compiling instructions is a very lightweight way. It appears in many famous commercial products, especially when dealing with different versions of the operating system.

Using a compile directive does not occur in the strategy mode, but you need to take care to control its scope of use. A more serious problem is that when there are very many versions (such as dozens of) the compiler commands become the killer of readability. It also increases the cost and error rate of the build process. In short, it must be carefully considered before choosing this approach.

Second, configuration-based software construction strategy

Different versions use the same code and build to get executable files. But the executable file you get here isn't the final release product. The executable file plus the configuration information to meet the user's needs. In this case, developers need not only develop code, but also design the format of the configuration file (the configurable capabilities of the module).

Configuration-based software construction also needs to be considered in the overall design. And there are many ways to implement it.

2.1 Using the Local class

The local class reads the configuration file and returns the configuration element from the configuration file to the program module. The problem with this approach is very similar to using strategy mode. In addition, the use of the local class can only handle relatively simple logic, such as control interface display.

2.2 Plug-in-based implementations

Plug-ins are an efficient way to separate code from configuration. Compared with the local class above, the mechanism of the plug-in is more granular in configuration granularity.

The configuration of the plug-in system can be divided into two categories: structured configuration, differentiated configuration.

A structured configuration specifies the relationship between plug-ins and plug-ins, and plug-ins collaborate with each other. A differentiated configuration embodies the configurable capabilities of a single plug-in. The system is divided into multiple "code + plugins" executable modules.

2.3 Trade-offs between code and configuration

In a configuration-based software build model, there is a watershed between code and configuration. How to divide the boundaries of code configuration affects the detailed design of all modules.

What is the purpose of the configuration and what effect do we want to achieve? Before analyzing these issues, let's start by explaining the two extremes of using a configuration file.

"Configure the points that must be configured" is the minimum configuration file. The way to judge whether this minimum standard is met is to see if there are multiple versions of the code that are caused by the multi-version feature on the system.
"Configure all the points that can be configured" is another extreme, and the ultimate effect is to complete a configuration language running environment.

The module reuse is low on the left, but the configuration file is simple and easy to maintain. The right side of the module is highly multiplexed and the configuration file is complex. Specific projects need to find a balance between these two extremes.

2.4 Consistency of design

First, how to find the balance between the code and configuration, the best case is the architect set a judgment principle, guide the designers to carry out detailed design. This is critical for maintaining product design consistency.

Second, in the case of high degree of configuration, different modules define the specific configuration file rules. The harmonization of these rules is also a challenge to ensure consistency.

Third, join the tool support

Good tools can improve productivity and reduce the cost of repetitive labor.

3.1 Traditional software building strategy

In the development of base and multi-version code, the tool can do is code generation work. Includes framework code and simple control code. More cases still need to manually modify the source files.

With regard to code generation techniques, a series of classes are provided in the. NET Framework (System.CodeDom namespace, etc.), which can be referenced in the relevant data. It is not complicated to realize that the technology itself is relatively simple.

3.2 Configuration-based software building strategy

In the base and configuration software building strategy, the main objectives of the tool can be placed on the management and generation of configuration files. The code is written by the developer, and the tool generates the configuration file and is tested to publish it.

The dividing line between the code and the configuration will affect the complexity of the tool. It is necessary to coordinate the cost and benefit of code writing, configuration file Management and tool writing.

Iv. adding dynamic languages

By adding dynamic language technology to the system, the boundaries between code and configuration become blurred. The use of dynamic language as a configuration file can take full advantage of its language features to improve configuration capabilities, eliminating the process of designing configuration format and parsing configuration.

The above said that the module custom configuration rules in many cases, will undermine the consistency of system design. In the case of a dynamic language, this rule is actually the syntax of the language and helps developers understand each module. However, the complexity of the generation tool is increased, which is essentially a code generator for dynamic languages.

Analysis of multi-version software construction strategy