Dflying 陈黎夫谈《持续集成——软件质量改进和风险降低之道》
2008-03-18 16:00
239 查看
“当一个项目经理或一名开发者说已经完成了80%的任务,您必须保持审慎的态度。因为剩下的20%可能还需要80%的时间,甚至永远都不能完成。”
上面这段话来自于《持续集成——软件质量改进和风险降低之道》的译者序。仔细想想,此话说得相当有道理:程序员是一群自信而乐观的人,总是以为自己已经考虑到了方方面面,所编写的模块万无一失、无懈可击。哪怕遇到了问题,也总会找到理由:是不是需求或是别人出了问题——一句最为流行的Developer应对Tester的Bug Report的话就是,“It is not a bug, but it is a feature.”。
不过即使程序员有千万种理由为自己的模块洗清了一切的“罪名”,但客户需要的上线或发布时间却仍旧无声地等在那里,不以任何人的借口而改变。
回到本文开始的那段译者序文字中,那“剩下的20%”究竟要用来做什么呢?为什么“可能还需要80%的时间”呢?
答案就是集成。虽然流行的软件开发理论已经把模块/组件之间的耦合程度降低到了最低,且有无数种类似单元测试的“流程”保证这每一个独立模块功能的正确性,不过当把这些堪称“完美”的模块集合成一个整体系统时,还是会不停地出现各种问题?
OK,让我们停止探讨为什么会发生这样的情况之类无谓的探讨,而是去看看应该怎样解决这个问题,并最终保证产品的发布时间和质量——毕竟问题已经发生了。
——持续集成。
持续集成能够把最终的一次大规模的集成调试过程分散到项目开发时间表的每一周、每一天、甚至每个小时。让项目中的各个人员都能够随时掌握当前的整体进度,并迅速发现集成过程中出现的问题并进行解决。
这本《持续集成——软件质量改进和风险降低之道》的第一部分就详细介绍了持续集成的理念、相关流程以及做法。
目前来看,持续集成似乎看起来非常不错,不是吗?
可是,一次集成并不是说句话就能搞定的——构建、部署、测试、生成测试报告、反馈……种种操作将会占用大量的人工。难道还需要专门派人负责每天的集成吗?
因此,将所有的步骤自动化,就是实现持续集成中最为重要的问题。
《持续集成——软件质量改进和风险降低之道》的第二部分则给出了一个完善的自动化持续集成流程,让持续集成从一句空谈变为实实在在的、具有可操作性的规范。
不过是一本200页左右的小书,却已经毫无遗漏地将持续集成的点点滴滴娓娓道来。若你正在为这方面的问题苦恼,不妨尝试从中找到一些答案。
==================================================================================
陈黎夫个人作品集
2005年毕业于上海交通大学计算机科学专业 ·2005年作为软件开发工程师加入微软Windows Live Hotmail团队 ·曾参与开发了下一代Email系统Windows Live Mail,以及Windows Live Calendar等产品。 ·擅长ASP.NET、CSS、JavaScript等Web相关技术并有着多年的开发、设计经验。
上面这段话来自于《持续集成——软件质量改进和风险降低之道》的译者序。仔细想想,此话说得相当有道理:程序员是一群自信而乐观的人,总是以为自己已经考虑到了方方面面,所编写的模块万无一失、无懈可击。哪怕遇到了问题,也总会找到理由:是不是需求或是别人出了问题——一句最为流行的Developer应对Tester的Bug Report的话就是,“It is not a bug, but it is a feature.”。
不过即使程序员有千万种理由为自己的模块洗清了一切的“罪名”,但客户需要的上线或发布时间却仍旧无声地等在那里,不以任何人的借口而改变。
回到本文开始的那段译者序文字中,那“剩下的20%”究竟要用来做什么呢?为什么“可能还需要80%的时间”呢?
答案就是集成。虽然流行的软件开发理论已经把模块/组件之间的耦合程度降低到了最低,且有无数种类似单元测试的“流程”保证这每一个独立模块功能的正确性,不过当把这些堪称“完美”的模块集合成一个整体系统时,还是会不停地出现各种问题?
OK,让我们停止探讨为什么会发生这样的情况之类无谓的探讨,而是去看看应该怎样解决这个问题,并最终保证产品的发布时间和质量——毕竟问题已经发生了。
——持续集成。
持续集成能够把最终的一次大规模的集成调试过程分散到项目开发时间表的每一周、每一天、甚至每个小时。让项目中的各个人员都能够随时掌握当前的整体进度,并迅速发现集成过程中出现的问题并进行解决。
这本《持续集成——软件质量改进和风险降低之道》的第一部分就详细介绍了持续集成的理念、相关流程以及做法。
目前来看,持续集成似乎看起来非常不错,不是吗?
可是,一次集成并不是说句话就能搞定的——构建、部署、测试、生成测试报告、反馈……种种操作将会占用大量的人工。难道还需要专门派人负责每天的集成吗?
因此,将所有的步骤自动化,就是实现持续集成中最为重要的问题。
《持续集成——软件质量改进和风险降低之道》的第二部分则给出了一个完善的自动化持续集成流程,让持续集成从一句空谈变为实实在在的、具有可操作性的规范。
不过是一本200页左右的小书,却已经毫无遗漏地将持续集成的点点滴滴娓娓道来。若你正在为这方面的问题苦恼,不妨尝试从中找到一些答案。
==================================================================================
陈黎夫个人作品集
2005年毕业于上海交通大学计算机科学专业 ·2005年作为软件开发工程师加入微软Windows Live Hotmail团队 ·曾参与开发了下一代Email系统Windows Live Mail,以及Windows Live Calendar等产品。 ·擅长ASP.NET、CSS、JavaScript等Web相关技术并有着多年的开发、设计经验。
相关文章推荐
- 完成这最后的20%——《持续集成——软件质量改进和风险降低之道》书评
- 软件质量改进(一)------过程改进方法
- 软件项目风险管理——《与熊共舞》读书笔记(六) ——改进的风险管理处方
- 项目经理如何避免降低软件质量
- 嵌入式关联性软件流程推广理论培训文档-流程改进介入前思想灌输文档-3. 规避软件风险的方法
- 软件开发过程大观——软件开发过程改进为什么能帮助软件质量提升?
- 设计及编码质量改进之降低耦合度
- 实用软件测试技术与持续质量改进方法 培训课程
- 设计及编码质量改进之降低耦合度
- 如何降低软件项目的风险 -- 包括客户的风险,软件提供商的风险
- 基于软件过程改进的质量度量模型
- 过程改进是否一定提高软件质量?
- 嵌入式关联性软件流程推广理论培训文档-流程改进介入前思想灌输文档-1. 软件风险的表现
- 设计及编码质量改进之降低耦合度
- 设计及编码质量改进之降低耦合度
- 软件质量问题谁负责
- 软件项目风险控制-公益讲座视频,供大家学习参考。
- 三个哲理故事教会我(我想所有人都有必要看)如何降低技术创业的风险