之前的几篇文章，目的是介绍一个贡献式编程的思考方式，暂时姑且叫Contribution-Driven-Development（CDD）吧。

1. 贡献式编程（一）
2. 贡献式编程（二）
3. 贡献式编程（三）
4. 贡献式编程（四）

总结

目的

程序员的抽象能力通常透过项目的实战经验累积下来的，可能在累积的过程中途放弃了。在我个人经验中，能有抽象能力和模块化的能力的人不多，所产出的程序也不具备可扩展性。所以提出所谓 CDD 的思维方式来帮助各位。

CDD不是什么新鲜的事物，只是一些经验的总结，在很多项目都会使用的技巧。我在当初接触 Eclipse 插件开发的时候，就深深被这种思维方式所吸引，任何部分都预留空间让其他插件开发者发挥。

步骤

总结这个思维方式，有几个步骤可以参考：

1. 实例分析：任何修改我们都需要用一个实例开始，分析可能需要的扩展
2. 定义贡献单元
3. 选择提供贡献的基础框架，一般是动态加载的框架
4. 分别基础框架建设和贡献单元，进行技术重构
5. 持续优化贡献的粒度大小，太小太大都不理想

原理

贡献式编程具体化了Hollywood Principle（Don‘t Call Me, I‘ll Call You）。贡献就只是贡献，原则上贡献是被动的，所以根本的思维上和一般 IoC 框架兼容。

系统的基础框架建设负责加载各个贡献，组织如何调用各个贡献，是主体、是启动系统的入口。

我们也具体化 Divide-and-Conquer 的实际操作，让大型系统的开发变成多个小部件。

使用好处

1. 模块化系统部件，管理上、人员分配上都形成了自然分工的好处
2. 每一个贡献的可测试性很强，TDD等可以较顺利切入
3. 模块的依赖关系比较清晰，可以单独处理模块升级，也可以隔离单个模块的错误
4. 贡献变得容易，形成自己的系统生态圈
5. 开发者入门相对容易，不需要看大面积的文档和代码
6. 结合持续交付，能快速实现系统升级

后语

一个系统的可扩展性，是这个系统生命力的所在。容易扩展，容易修改，容易做出贡献，生生不息。希望这个思维方式能成为培训程序员的一个重要标准。

贡献式编程（总结）