by Richard
20. October 2009 23:39
目的：
建立和维护一个公司级的可复用公共库，主要为了3个目的：
- 提高开发效率，让开发人员从系统级功能的开发中解放出来，把工作重点放在业务级功能的开发。
- 提高代码质量，开发人员写的代码越少了，问题就越少。
- 改善不同团队，不同项目之间代码风格的一致性，促进团队之间的交流与合作。
内容：
主要包含这几种类型：组件、控件、函数库、工具、示例，以及从项目中抽象出的可复用模块。
其实可以考虑把公司的开发规范，代码检查标准也纳入Common Library中一起管理。
开发：
当识别出有新的可复用的item，Common Library管理小组要进行讨论，确定基本方案；然后指定负责人，按照要求完成开发，并对验收检查后才能入库。
测试：
Common Library中的每一项都是要经过严格的测试后才能发布出来的，测试用例和测试报告都要保留存档，方便检查和以后参考。
可以借助一些单元测试工具，使得测试用例可复用，并自动执行大部分测试，提高测试效率。
文档：
主要包含4个文档：
- 功能文档：实现了那些功能和特性(feature)，还有哪些没有完成的功能(to do list)，还有哪些bug没有修复(bug list)，版本历史记录(history)。
- 使用手册：什么情况可以使用(when to use)，从哪里获取最新版本(where to use)，如何使用(how to use)，和一些注意事项(tip)。
- 设计文档：包括Class Diagram，Class Reference，Database ER Diagram。
- 测试文档：主要包含测试用例和测试报告。
维护：
配置管理方面也应该分开两个代码库：开发库和产品库。 开发库只有参与Common Library开发的人员可以访问，而产品库是公开只读权限给所有人。只有测试通过的代码，而且相应的文档也同时更新了，经过管理组的同意才能更新到产品库。更新产品库后要发布消息给大家，并告知更新的内容。
要建立一个查询系统，让大家可以方便的查找想要的内容。
定期检查，了解使用情况，收集新需求：在Code Review Checklist中加入对Common Library使用的检查，在项目总结中加入对Common Library使用情况的总结、改进意见、以及推荐项目中可被纳入Common Library的新内容。
风险：
执行前需要一个深远的考虑和计划。否则不易执行或不能长久坚持下去。
如果Common Library有更新或发布了新版本，要考虑是否对已经在运行的系统有影响，再决定各个系统是否应用更新。
职责：
从上面看下来，要把Common Library建设好，需要做很多的工作。公司应该有专门的人员来做这个工作，建立起相关的组织来管理和维护它。
公司越大，Common Library的意义就越重要，同时也越难管理。如果公司真的要扩大3倍，安排一两个人专门做这个应该不过分。
其实Common Library的关键不是建立一个代码库，而是需要相应的管理流程和公司气氛才能使Common Library变得有生命力和发挥更大的效力。
Subscribe