项目大到一定程度，为了代码复用，通常会抽象出一些公共的功能作为类库或函数库。建立这些公共设施本身是件利国利民的好事情，老大们也乐意有人做这样的事情，做的人也获得了Credit。但是公共设施建立以后，往往会陷入疏于维护的状态，久而久之，极有可能成为一个垃圾场。
这是一个发生在我们项目中的真实的例子，我们建立一个Python的库，来提供通用的功能，代码是从各个部分抽象出来的，刚刚开始皆大欢喜，各个部分的逻辑清晰了很多，代码库也作为亮点在项目内推广。随着项目的进行，问题开始逐渐地呈现了，新的需求不能被现有的库满足，又不能想开始一样安排专人维护这个库，如何维护这个库成为了一个难题。对库的改动有两种，一种是在库中加入新的代码来处理新的需求，就造成了库中重复代码，另外一种就在应用逻辑中处理新的需求，造成了库和应用之间重复代码。
今天开到一篇文章，Avoiding the OS abstraction trap, 文章提到了一个开发团队提交了driver patch给kernel，这个patch包含了一个抽象层以支持不同的操作系统，kernel审核的人认为这种抽象机制会增加kernel的维护成本，于是这个悲催的团队花了六个月的时间修改并提交了应外一个patch。文章的评论中有一些不明真相的群众开始讨论kernel的这种维护模式是不是合理，争论在于模式应该为内核开发者优化还是为驱动开发者优化，2.4的时候还是为驱动开发者优化，内核开发者非常悲催地硬撑了一段时间之后，2.6之后转变成为内核开发者优化的模式。除了这个抽象层之外，老的patch还是使用了workaround来修复、掩盖了内核中的若干“问题”，作者建议开发者应该积极地修复内核的问题，而不是提供workaround。
如果我们引申一下，公共设施就像内核，只有少数人花部分时间来维护，应用逻辑就像驱动，各个子项目（有资金和人力支持）都可以维护。我们的开发模式是不是也应该是为公共设施优化呢？如果是，什么样的流程可以保证这一点呢？
我个人的想法，公共设施的建立和维护都应该是一个持续的过程。
* 建立
1、Owner负责协调和推动这个建立工作，并负责编程风格、接口风格、文档生成等整体层面的事情。
2、各个应用模块（Stake Holder）和Owner一起分析公用的功能，贡献代码给公共库。
3、Owner和Contributor组成community，负责后续的改动审核。
* 维护
1、使用者查阅文档，使用相应的接口。
2、如果接口不能满足需求或者接口已经过期，使用者提交修改请求，由使用者（优先安排）或community的一员负责实现。
3、团队定期做DRY(Don't Repeat Yourself)分析，提取公共的功能到公共库。