How to improve the level of software reuse in project delivery

Introduction: Software reuse is a very important topic in the field of software engineering, but how to use it effectively and reasonably requires an understanding of the nature of reuse and some top-level designs. This article introduces different software reuse forms, their advantages and disadvantages, and discusses the reasonable reuse forms in the project delivery scenario.

1. Software reuse is a key factor in improving project delivery efficiency

1.1 What is software reuse

Software reuse (Software Reuse) refers to the use of various related knowledge of existing software to build new software to reduce the cost of software development and maintenance, and is an important technology to improve software productivity and quality.

Software reuse is a common thing for programmers. We may have been in contact with reuse since programming assignments in school. The early software reuse is mainly code-level reuse, and the reused knowledge refers specifically to the program. However, in fact, the precipitation of domain knowledge, architecture design, technical documentation and other knowledge types is also applicable to the above definition, which also belongs to the category of software reuse.

According to different levels, software reuse usually has the following forms:

1. Code Copy: the simplest and most direct way, and the most common

2. Component reuse: In an application project, some functions are realized by using existing components. For example, fastjson widely used in Ali, such as Spring Cloud engineering scaffolding.

3. Application reuse: Going further than component reuse, using existing services through APIs, such as a microservice that provides the ability to send text messages. This service is a black box to the consumer, and no modification to the source code of this service is required.

4. Product-level reuse: This means that it can be used out of the box and can be adapted to the individual needs of customers only through configuration. It usually refers to SaaS products, which means a high level of scene abstraction and is also related to business scenarios and positioning.

As the level of reuse increases, the efficiency of reuse will also increase, but at the same time, the flexibility to adapt to different customer scenarios will decrease, which is a bit like overfitting in machine learning algorithms. Therefore, it is not enough to blindly pursue high-level reuse, which will be highlighted below.

1.3 Features of Software Reuse in Delivery Projects
In the context of project delivery, the essence of reuse is to improve the efficiency of delivery, speed up the time from the customer's idea to the actual delivery of the project to the customer, and reduce the cost of human resources. In project delivery, the most critical constraints are cost and time. Without these two factors, software reuse may not be so critical. But for our project delivery, these two points are the most sensitive.

In addition, in the cloud computing era, developers are the main object of software reuse (contribution & consumption) in delivery scenarios. Cloud products are very powerful, but most of them are PaaS products that require technical processing to meet the specific business needs of customers. Usually developers will be deeply involved in an industry, continue to accumulate delivery experience, and have the opportunity to settle. The precipitation here is the source of software reuse.

In this context, software reuse needs to consider the characteristics of developers, including how to exchange technical assets between different organizations; including whether the software has enough documentation, demos and technical support to help weaker technical skills. of developers can also reasonably reuse.

2. Difficulties in software reuse

Software reuse is one of the core means to improve delivery efficiency, but there are many difficulties to implement, mainly due to the following three points.

2.1 "Not My Creation" Syndrome

"Not Invented Here Syndrome" refers to a cultural phenomenon in society, companies and organizations where people have an inherently irrational sense of dismantling software that is not created by themselves.

The so-called phenomenon of programmers reinventing the wheel also has the influence of this factor. There are always reasons to refuse reuse, such as criticizing the API design of an open source project for not being elegant enough. In fact, in retrospect, I also had this mentality in the past, and sometimes I had the urge to implement it according to my own ideas.

For the core business module, it may be understandable to choose to build it by emphasizing control. In scenarios where time and cost are emphasized, reuse is obviously more important.

2.2 Software complexity affects reuse

The technical architecture can simplify the complexity of the software, but no matter how good the architecture design is, it is "clean" when it is just completed, and its complexity gradually accumulates with the increase of functions as the implementation progresses.

In fact, if the entire system is transplanted by means of code copy, it means that all the complexity of the original system is copied. Modifying the code originally developed for the scenario of customer A to meet the specious needs of customer B will greatly reduce the benefits of software reuse at the cost of development and testing.

Compared with the method of code copying, if the software is sufficiently modularized, each module is designed according to the rules of high cohesion and low coupling, and only realizes atomic functions. Modules can be in the form of components or services, providing SDKs or APIs to the outside world. Then when software is reused, you can only reuse these modules, and discard the business code used to glue each module in the original project (usually focusing on customer-customized requirements, corresponding to the so-called anti-corrosion layer in the clean architecture)

Of course, these modules are black boxes to the caller, so the design of the component and the degree of openness to the internal implementation will determine the degree of software reuse.

2.3 Difficulty in obtaining technical support

If it is open source software, when we open source its source code for people to reuse, it will not be mandatory to provide technical support SLA. This is why many open source software has a community edition and a corresponding enterprise edition, the core of which is to provide professional technical support.

Therefore, when deciding whether to reuse software assets, in addition to the function and quality of the software itself, whether to obtain technical support is also a decisive factor. For open source software, it is to see whether it is continuously updated and whether the community is active.

3. Software reuse forms suitable for delivering projects
Architectural Design vs Civil Engineering

In some business scenarios, SaaS-based software can be used to achieve "check-in". However, the large-scale projects of Alibaba Cloud Collection are characterized by the fact that the customer's scenario is not so "standard", or it is essentially an exploration of digital transformation, and the boundaries of requirements are relatively blurred.

The delivery of the project at this time is actually very much like building a building. First, a technical architect is required to draw a blueprint, focus on the macro architectural design, and confirm with the customer. The architectural design determines the upper limit of the building and whether it can become a landmark building (the so-called landmark is different and cannot be copied as a whole).

Then, when it comes to the implementation stage, software reuse is like civil engineering, focusing on the details of the implementation process. Software reuse is like moving and placing civil bricks. It determines whether the building can be completed on schedule, and how long it will stand after it is built.

Modular software reuse

Ideal software reuse is similar to building Huoshenshan and Leishenshan hospitals. Pre-built modules are prepared in the factory, transported to the construction site, and assembled. In this way, the construction period can be greatly shortened.

The greater the granularity of software reuse (corresponding to the higher level of reuse mentioned earlier), the higher its complexity, and the greater the cost of on-site adaptation and adjustment. It may even require users to cut their feet to fit. On the other hand, the more cohesive the function of an independent module and the less external dependencies, the easier it is to be reused.

Therefore, the reuse of suitable delivery scenarios is to do a good job of modular splitting, and create prefabs in the form of components or services. Just like Lego bricks, the particles are as small as possible so that they can be easily plugged and reassembled in various places. As for how to call the components through the "glue" code according to the customer's customized needs, the assembly work is left to the delivery site.

4. Build an asset market and improve software reuse

4.1 Construction asset market
As mentioned earlier, the individual needs of customers are complex and changeable, and in most cases, out-of-the-box products cannot meet them. In comparison, prefabs that fulfill specific functions and are available on-demand for delivery projects are more suitable.

Knowing what assets to build, we also need an online asset market to host them. Assets can be centrally managed and browsed and discovered by potential users.

For example, we all know that application security is important, but in project delivery, it is sometimes easier to ignore, and prevention is not in place. At this time, if there is a good general security component and provide it for developers to use, it will help most projects to raise security to a passing level.

4. Summary

In delivery scenarios, customers have a lot of customization requirements. No two projects have exactly the same customer needs. It is difficult to solve customer needs through simple product reuse. Custom development is essential. Here, we focus on civil engineering, improving the efficiency of delivery through high-quality prefabricated parts. By building an online asset market, the standards of assets can be unified, and through the operation mode of an open source community, partner developers are also brought in to build together.