写这篇文章的想法产生在昨天晚上读《面向对象分析与设计》的时候，我渐渐发现我们这个小组不知不觉地贯彻了很多非常有价值的实践经验，这些点点滴滴都对我 们的终的产品质量产生了或大或小的影响，保证我们的系统不会出现重大的故障。我想有必要将这些“隐性知识”稍微总结一下，以供参考和记录。

　　从过程的连续光谱来看，我们大概处于中间位置偏左的位置，更偏向一个轻量级团队的敏捷过程，但是也包含计划驱动过程中的因素。我们的小组是自管理的，没有 专门的QA和SA，我们自己去想出好的工作方法，但是在执行中我们的计划还是相对确定的，每个季度做什么都会有一个比较明确的计划和里程碑，并且对问题 领域都相对熟悉；我们的过程是迭代式，一般一个季度至少会交付一个稳定可执行的新版本，我们在文档上做的不是特别好，很多都依赖于团队成员之间的“隐性知 识”；同时我们对问题的改进基本还是有一个流程和机制，会持续的跟踪问题并改进。

　　下面分阶段总结下我们的一些实践经验。

　　一、分析和设计阶段

　　1、在这个阶段，我们会明确准备做什么，界定问题的边界，对功能进行一个取舍。一般在一个版本完成之后会马上开始这个过程。大家都想一想接下来做什么，经过几轮PK后确定重要紧急的事情优先做，定义下一个版本的功能列表 。

　　2、功能列表出来之后，我们会针对每个功能提出各种方案做比较，在此期间，我们会邀请更大团队范围内的专家参与方案和设计的评审 ，剔除不切实际以及明显有缺陷的方案，针对一些风险点提出改进建议和防范措施。

　　3、在设计方案出来之后，我们会分配功能的开发任务，根据每个开发人员熟悉的领域，自主领取或者被动分配任务 。这个过程不是一成不变的，考虑到团队内部知识交流的必要性，也可能让不熟悉某个领域的人去做他不熟悉的事情。

　　二、构造阶段

　　1、整个系统已经有一个关键的抽象机制 ，针对我们的服务器有一个核心的pipeline机制，针对我们的客户端，有一个核心的发送消息流程。将所有的功能模块组织在这个关键机制周围，形成一个强有力的整体。

　　2、开发完成不仅仅意味着功能代码的完成，还包括测试代码 ：单元测试和集成测试。如果你没办法做到全面的覆盖，那要求必须覆盖运行的关键路径和极端场景。

　　3、单元测试我们使用JUnit，适当使用Mock可以简化测试。但是Mock对象如果太多，也许会失去测试的价值，这里有一个权衡。

　　4、在整个构造过程中，我们贯彻每日构建、持续集成的原则。使用hudson做持续集成，时刻关注测试状况 ，有问题及时反馈给开发者。

　　5、有一个功能强大的集成测试框架，模拟实际环境做各种测试，它的目的是尽量在接近真实状况下去执行系统并尽早暴露问题。

　　6、每个功能完成之后，立即发起review，请同事和你一起复审代码。复审代码的作用不仅是发现bug，改良设计，也是一个知识交流的佳途径。我们经常能通过代码审查 发现一些设计上的缺陷，以及功能实现上的BUG。我们团队应该说是非常看重代码审查的作用。

　　7、使用findbugs和clover等工具 ，分析代码质量并改进。

　　8、在发布之前，做一次集中的代码review ，每个人介绍下自己的功能实现代码和设计，一般我们会申请一个会议室和投影仪，并邀请团队之外的人加入review。

　　9、在发布之前，有一个系统的压测流程 ，针对每个版本更新压测方案，并预留一到两周的时间做性能压测。压测不仅能尽早暴露性能隐患，还可以发现系统在特殊情况下的一些BUG。压测除了关注系统的吞吐量、GC情况之外，还应该关注硬件的性能指标。

　　三、发布和总结

　　1、发布之前，好让使用我们系统的用户使用新版本做一个回归测试 ，一方面是测试兼容性，一方面也可以及早发现BUG。

　　2、我们的发布流程：线下、beta、线上。每个阶段通常都持续一到两周，才会进行到下一阶段。并且是从相对不重要的系统，到关键系统的顺序进行发布。

　　3、发布之后，通过日志、运行时监控、用户反馈等方式收集系统运行状况，发现BUG，修正BUG，补充测试，测试通过，重新发布。

　　4、每个版本发布后，需要总结下本次发布过程中遇到的所有BUG以及经验教训，并提出可能的改进建议。

　　5、需要一个跟踪线上问题的BUG跟踪系统，可以用JIRA之类的trace软件。跟踪不仅是记录，好列出解决的时间点，在哪个版本确定解决，甚至确定交给谁去解决，并持续跟进。