我看书斋

第14部分（第3页）

阿朱上次跟阿捷谈过持续集成后，第二天就召集所有的人开了一次会，把自己的想法跟大家讲了一下，大家纷纷说好！并当即进行了分工，阿朱和阿紫负责产品自动安装和验收测试中的自动化，大民、小宝负责自动编译、自动UT、自动打包部分，最后再由阿朱进行总的集成。因为TD的OSS　产品很庞大，再加上历史积累下来的回归测试用例很多，大家决定将持续集成、自动测试的频率设为每天进行一次。大家还为整个过程起了一个很好听的名字　——“AutoVerify”，意指自动进行产品的验证。同时大家还讨论了一些实现细节。

大家晚上下班之前，把自己Check　Out出来的代码Check　In到代码库中。AutoVerify程序会在每晚8：00自动从代码库中提取最新的代码，自动进行编译，编译成功后同时启动两项任务：一个进程进行自动UT，另外一个进程进行打包并自动部署到测试环境中。这是因为UT的时间非常长，需要两个小时左右才能跑完全部的868个测试用例。这样二者并行进行，可以节省两个小时的时间，多跑一些回归测试用例。虽然也有可能UT测试用例失败，但应该是不影响产品在测试环境下运行的，可以打包并安装。安装成功后，开始自动回归测试。

因为历史遗留下来的测试用例太多，一个晚上不可能跑完所有的测试用例，应该只跑一些核心的最重要的测试用例，这个筛选工作由阿紫负责。只有在周末的时候，利用两个整天的时间，才把所有的测试用例全部运行一遍。AutoVerify需要自动收集统计信息，譬如运行了多少个测试用例，通过率是多少等，把这些结果汇总下来。在第二天早上　9：00，AutoVerify自动把一个晚上自动验证的结果通过邮件发给阿朱和阿捷，由阿朱负责检查。为了减少垃圾邮件，只有在任何一个环节出现问题的时候，AutoVerify才会把邮件发给大家。此时，阿朱负责把出错日志转给相应的人，收到该邮件的人要第一时间解决。

在讨论完AutoVerify后，大民利用剩余的时间，把XP提上了议事日程。

“我们这次实际上一次性地用到了XP的两个重要实践：持续集成和自动测试。其实，XP还有一些其他的很好的实践，有些已经通过Scrum这个框架体现出来，譬如小发行版（Small　Releases）等，但是XP其他一些编程实践也还是值得我们尝试的。”

“嗯，我赞同这个观点，Scrum本身没有规定具体的编程实践，我们正好可以用XP来补充！大民你接着说一些适合我们自己团队的XP实践吧！”阿捷说。

“第一个应该是结对编程，其次是编码标准、简单增量设计、重构、测试驱动开发等，还有代码集体所有权。”

小宝插了一句：“关于代码集体所有权，其实咱们已经做得很不错了！大家看，咱们因为模块多，代码多，一直也没有也不太可能规定具体哪块的代码归谁拥有，而是任何一个人都有权修改任何一段代码。谁破坏某个模块，谁要负责进行修补。”

“嗯，这点我赞同。不过我想明确提出来，强调一下，我们应该继续保持这个优良传统！同时因为代码归集体所有，所以大家就都要遵循统一的编码标准才行。”　。　想看书来

第11章　你开车，我导航（2）

“没错，我们历史遗留下来的代码太多太杂，这里面既有老美写的，还有印度人写的，再加上咱们自己写的。真够百花齐放的！”

“是啊！短时间内，我们是不可能吧所有的代码都统一起来的。虽然也有一些类似aStyle等自动化代码美化工具，可以一次性地把所有代码整合成符合统一编码标准的形式，但这样做的风险实在太大！万一出了问题，因为所有的代码都改动了，反而没办法跟踪，不容易解决。”大民显然仔细分析过这个问题。

小宝点了点头：“我想我们可以一步一步来，只有我们需要改动哪个文件时，才对该文件按照编码标准进行一次优化。不过话又说回来，我们现在的编码标准有点乱，也有点过时了，需要重新整理一下才行。”

“要不这个任务就交给你？”阿捷问道。

“行啊！其实我已经整理了一半了。”小宝的积极主动性还是挺高的，“我们原来有一个基础版本，但有些东西已经过时了，另外还要加些新的规则进来。”

大民接过话头：“关于增量设计和重构这块我们做得还不够，当然这也是有历史原因的。咱们以前一直都是瀑布式开发，非常重设计的。仅仅针对设计，咱们以前的流程会产生概要设计文档、外部接口文档、详细设计文档、测试策略、测试计划等，从敏捷的角度来讲，我们应该做一些简化。”

“嗯，是有必要精简，但应该精简到什么程度呢？”阿朱问道。

“我觉得……”大民稍微顿了一下，似乎是故意为了强调：“够用就可以了！就是说不应该太多，但也不能没有。我们需要找出来对我们真正有用的文档，真正值得花精力的文档，然后做增量设计。”

“话虽如此！问题是咱们在大的流程上还必须按照公司的产品生命周期走，这中间会涉及很多的里程碑，而每个里程碑都要求有完备的文档，才能通过检查，进入下一阶段。”阿朱接着说。

“那我们先来看一下公司的PLC（Product　Life　Cycle）好了。”阿捷边说边在白板上画出公司的产品生命周期。

“虽然整个周期很长，但咱们必须通过的CheckPoint只有DEV和SHIP。咱们Team目前自己实施敏捷开发，也就是在DEV到SHIP之间。其实，这也正是敏捷软件开发跟CMMIISO　000等流程相互补充的最有效方式。其间的SQ虽然很重要，但不是必需的，公司强制得并不严。所以咱们只要在DEV和SHIP这两个CheckPoint上提供完备的文档就可以了。”

“DEV　在我们开发的启动之初，可以周旋的余地不多，这个念头就不用想了，该准备的文档还要准备好。不过，这个CheckPoint更多的是针对Marketing、Product　Planner等除R&D以外部门的，对于我们R&D来讲，只需要给出一个项目计划文档和一个软件总体架构文档即可，所以问题不大。而SHIP是在后期，可操作的余地比较大。”

“这样的话，那我们是完全可以按照尽量简化、增量设计的思路来做的！在每一个Sprint，我们都只做简单设计，产生对于当前Sprint所必需的文档，而没必要一次性给出大而全的设计方案，写出非常完备的文档来。这样也不现实，因为最终还是要不断地修改的。完全可以通过后继的Sprint，不断完善，不断重构，直至产品发布前，给出最终版本。当然，每次的设计都应该是可以扩充的，而不是走入死胡同，以后没法重构。大家觉得如何？”。　最好的txt下载网

第11章　你开车，我导航（3）

“应该是可以做到的。关键还是度的问题。设计要适度，文档要适度，不能成为我们工作的累赘，又要做到出现争议的时候有据可查。我觉得有些文档还是一开始就要有的。”大民回应道。

“可哪些文档是必须要有的呢？”小宝还是很关心具体的东西。

“在我看来，至少有两份文档是必需的：需求文档和概要设计。需求文档的目的是告诉大家，我们开发的软件要做成什么样子、要实现哪些功能，这份文档应该是经常更新的，记录?

https://www.cwzww.com https://www.du8.org https://www.shuhuangxs.com