查好友ios1.0总结II：开发节奏的把握

写了第一篇总结之后，发现更细节的展开比自己的想想要麻烦多了....

不过习惯的养成本就不是容易事儿。于是，还是开始写下来吧....

这是真实的故事，并非来自枯燥的软工课本：

----------------------------------

查好友iOS1.0版的开发开始的很匆忙。

我和LL两人一起接手开发。在此之前，我有两个月的iOS开发经验，而LL则是刚开始学习。

缺少对商业产品细节的把握，最初我乐观的预测开发周期为两三周。

8月26日，粗略了解了产品形态后，就一头扎进了代码的编写中，忽略了详尽的需求采集和设计。

之后的时间里，靠着android的源代码和在虚拟机中跑出的app作为原型，我和LL不停地摸索前进，遇到不了解的功能或交互再询问主管产品的YY，遇到不了解的接口再询问负责后台开发的LP。

两周多的时间，我们确实完成了一个demo版。实现简单的UI和功能逻辑的过程总，代码的编写进度飞速，就我个人，平均每天产出600+。demo版能登陆注册，能联网，能展示和更新组织列表、成员列表。但由于缺乏对需求的把握，很多细节功能都非常薄弱。比如如何连网服务器以在中国贫瘠的移动数据网络中保持较好的容错性和用户体验，比如如何实现登录入口处的下载更新逻辑，更不用说后来改的面目全非的UI元素了。

之后的两周，进度不再疯狂。我们开始陷入到亲手挖的坑中：无休止的修改原有逻辑，将一款无指挥的app拉回到最初的设计意图上来。但另一方面，燃烧了两周激情过后，自己反而有些放松了心情，没有警惕到开发进度的迟缓。8月26，公共群组和创建组织的逻辑被提上版本功能点，我和LL又花了几天的时间来完成这部分变更需求的代码。

9月1日是原计划的app提交日，在完成了新增功能的代码之后，我和LL也一直抱着这个信念，开始紧张的debug。但这个过程并没想象中顺利，甚至于许多功能需求仍然需要更改，比如对数据的更新处理逻辑。9.1终归没有完成手头所有工作。之后的一周多时间里，我一直在超时的挫折感和忙碌的debug中度过，期间又有好几次，我以为能在当天完成它了，而通宵到两三点，愿望落空。

9月11日，终于向appstore提交了app。9月12日，发出了第一个越狱版ipa。整个工程去空行代码量1.8W。

----------------------------------------------

回顾一个半月的开发历程，我和LL所燃烧的激情足以称道，但计划性的缺失让我们走了很多弯路，对开发节奏把握的不够让我们在后期陷入了疲劳的困战。

根据个人的代码经验，我将适合自己现阶段的开发过程抽象为一个ReCERD模型：

Requirements：根据原型和用例，明确产品功能，尽量理清代码架构逻辑，区分开C和E模块。因为缺乏对架构的认知和经验，在这一步上，或许没有办法拿出足够完备的架构设计，好在不断重构的方法能很大程度弥补这一步的过失。

Comfort：这部分的代码实现逻辑相对常规和简单，甚至有已有的代码做支撑。这是代码产量最大的时期。

Explore：实现所使用的技术没有使用过，需要先做测试，再应用到开发中，需要花较长的时间周期，并有更多的debug隐患。最需要慎重的时期，较大的学习成本。

当然，E和C并不可能完全区分开来，比如加入一段曾经没写过的业务逻辑，可以将它理解尚未实现过的E，也可以是无新技术元素支持的C。当然，不论怎样，这样的区分原则，是为了协调好整个开发周期中的精力分配，保证良好的开发势头。实际的执行中，E和C应该细分为更多小块，在不打破局部性原则的情况下，让E和C交叉执行，并保证总体上E处于C的优先级之前，避免开发过程中todolist过于干瘪或太过饱和，那样会直接影响到开发组的心理状态和编程效率。

Refactor：增加新功能时，发现原有代码扩展性不够，时间允许的情况下，可以理解执行重构，一方面增加软件的扩展性，另一方面增强对代码的理解把握。需要将这一步提到与其他开发步骤平齐的位置，是为了弥补之前设计时的不足。

Debug：最后阶段的测试debug是为了过滤设计时没有考虑到的特殊情况。程序员需要为自己的代码负责，在测试debug之前需要确认已实现了需求的功能点（自己对代码的单元测试等不属于测试debug的范畴）。测试debug需要分配充足的时间，否则极容易出错。