[查好友ios1.0版发布总结V]开发流程规范化

经过了查好友ios1.0版第一阶段的开发（也是查好友产品的第二个milestone），开发流程中的许多问题已经跃然纸上。本文对部分关键点做了简要总结。

瓶颈一：产品设计与开发实现的衔接

产品设计阶段，递交给开发组的产出以 产品原型 和 用户用例、场景 为核心。传统的软件工程实现中，在开发之前需要做好需求调研，并完成SRS（Software Requirement Specification），作为开发的指导。互联网产品要求有更高的迭代开发速度，为了达到这个目标，摈弃不必要的设计、文档相当必要。这里我们做出的最大让步界限暂定为产品原型 和 用户用例、场景。产品与开发的交接，要求开发者认真理解原型的功能和交互，这些步骤的完成需在写代码之前（准确的说是代码结构设计之前）完成。

1.产品原型不以文档或图形来限制形式，以让开发者明确实现为目的。

2.用户用例、场景是产品原型的功能交互的详细解释。这是传统软件工程开发过程中需求采集的重要步骤。用例在软件开发的前期，可以集中、整合需求，规范设计。在测试阶段，用例可以驱动系统测试行为。简单讲，用例就是对全部用例场景的抽象，用例场景就是从用例中实例化出来的一组活动。这部分过程可以大家共同设计完成。

瓶颈二：代码设计

在严格规范的软件开发流程中，CRC卡片（类—职责—协作）可以用来更清晰的展现各个部分之间的职责关系，有助于在设计阶段思考一些关键问题。不过这种方法的复杂性在我们的开发经验限制下，并无法展示其优越性：对面向对象编程和设计模式的经验不足，我们的代码经常试探性的尝试各种形式编程，这也意味着无法在设计期间构建良好风格的类设计，而CRC正是导出类设计的前置步骤。代码设计时，还可以借助许多的UML工具。比如绘制泳道图、时序图等。

现阶段我们可以跳过这些规范化的设计阶段，直接在现有的经验的基础上粗略设计模块，节省设计时间，用之后的重构来替代设计的劣势。当然，这并不代表着永久的放弃这种规范化的操作，到了某个阶段，如果有必要，我们也可以拾起这套方法。档案，也有一直听到一种声音，“即使是大公司，也很少使用到软件工程的那一套流程”。鉴于此，长期来说，我们需要进一步调研，吸取其他开发团队的经验，来持续改进开发流程。

瓶颈三：代码实现过程中的流程规范化

代码结构设计完成后的重要后续是项目排期。参照《查好友ios1.0总结II：开发节奏的把握》，并结合人员配置，合理的分配模块，进行任务分派。

由于交流的仓促，在之前的开发过程中，我们遇到过很多不的不顺利。这些不顺都是计划性和规范化的缺失的结果。

具体来说，协同开发的计划性和规范化包括：

1.设计步骤确定后，方可进行项目排期以及任务分派；

2.分派任务时，需要结合原型和用例，给出规范的SRS说明；

3.获得任务分派后，在提交代码到SVN trunk之前，需要通过自己的单元测试，以确保功能实现完备。提交时，需要在log中记录下自己的更新模块的描述，一来作为开发日志的反应，二来以备不时之需（新代码污染了原来的代码，需要找到原来的回滚点等）。

[附一篇使用的svn使用指南，讲到了很多基础概念。来自 http://www.cnblogs.com/tidy/archive/2007/07/09/811850.html]

[另附一篇博文，其中介绍了svn中branch的使用。这在开发过程中会经常遇到，比如用来备份自己还未完成的代码而不影响主版本库的代码。http://fireinwind.iteye.com/blog/724984]

瓶颈四：测试

总的来说，一个半月递交审核对于一个刚组建的二人无经验ios开发小组是很有挑战的。仓促之中，测试环节做的有欠妥当，以致第一次提交后的三天又发现了相对严重的bug，不得不修正后重新提交。在规范了开发的整体流程后，测试也获得了一个较好的开展空间：

首先是功能测试：

1.单元测试：模块代码提交之前需经过程序员的

2.设计时的用例场景可以驱动测试：包括回归测试和探索性测试。其中，回归测试指对一个新的版本，重新运行以往的测试用例，看看新版本和已知的版本相比是否有退化 (regression)，这些都可以依靠现有的用例来驱动实现（这也是之前我们所缺少的，即每次更新、debug后对整体进行回归测试，而这个测试成本相对较大，也就对每次测试、修正的节奏提出了要求：不可太过频繁的提交产品到测试，要慎重）。

3.正式发布之前，应进行alpha测试（软件测试人员在真实用户环境中对软件进行全面的测试）和beta测试（公测）。

其次是非功能测试，也叫服务质量测试（Quality of Service requirement），这些测试是建立在软件已实现了基本功能。

1.压力测试；2.负载测试；3.性能测试；4.兼容性测试；5.安全性测试

----PS-----------------

除此之外，对于整个项目的规范化，这里也抛砖引玉的陈列几点：

1.线上回归。这一点是我请教百度的同学后得到的。他们的产品在发布之前会定好feature，发布之后，会验证这些新feature是否达到了预期收益。

2.项目管理：项目管理的必要性在我上课的那一个学期里着实没有发现，到了实际应用中，却暴露无遗。8个人的团队也构成了项目管理的最小规模了。

也就不套条条框框了，一些项目管理的要素在小团队里不需要，但这类需求也得根据团队的变化而即时变化。比如，绩效考评、进度管理、风险控制等。

之前的很长时间里，我用开发日志的形式来记录工作，后期由于时间太紧，就放弃了。开发日志记录的问题在于，如何统一管理。