Contribution programming (Summary)

Several previous articles aim to introduce a way of thinking about contribution programming. For now, call it contribution-driven-Development (CDD.

1. Contribution programming (1)
2. Contribution programming (2)
3. Contribution programming (III)
4. Contribution programming (4)

Summary purpose

The abstract ability of programmers is usually accumulated through the practical experience of projects, and may be abandoned in the process of accumulation. In my personal experience, there are not many people with abstract and modular capabilities, and the programs produced are not scalable. Therefore, we propose the so-called CDD approach to help you.

CDD is not a new thing, but a summary of some experiences and techniques used in many projects. When I first came into contact with Eclipse plug-in development, I was deeply attracted by this way of thinking. All parts have reserved space for other plug-in developers to play.

Procedure

To sum up this way of thinking, you can refer to the following steps:

1. Instance analysis: we need to start with an instance for any modifications to analyze the extensions that may be needed.
2. Define contribution units
3. Select the basic framework that provides contribution. Generally, it is a Dynamically Loaded framework.
4. Technical restructuring of the basic framework construction and contribution units respectively
5. The contribution size of continuous optimization is too small or too large.

Principle

Contribution programming embodies the Hollywood principle (don't call me, I'll call you ). Contribution is only contribution. In principle, contribution is passive. Therefore, the fundamental thinking is compatible with the general IOC framework.

The infrastructure construction of the system is responsible for loading various contributions, and how the organization calls each contribution is the main body and the portal to start the system.

We also embody the actual operations of divide-and-conquer to turn development of large systems into Multiple widgets.

Benefits

1. Modular system components, management and personnel allocation have formed the benefits of natural division of labor
2. Each contribution is highly testable, and TDD can be smoothly introduced.
3. The dependency between modules is clear. You can handle module upgrades separately or isolate errors of a single module.
4. It is easy to contribute and form your own system Ecosystem
5. It is relatively easy for developers to get started, without having to look at a large area of documents and code.
6. Rapid system upgrade with continuous delivery

Background

The scalability of a system is the vitality of the system. It is easy to expand, easy to modify, easy to contribute, and endless. We hope this way of thinking can become an important standard for training programmers.

Contribution programming (Summary)