14.4 从任务到代码

　　14.4从任务到代码

　　14.4.1接到任务

　　小飞接到任务后，他会怎么办呢？他会做下面这几件事情。

　　（1）估计开发任务所需的时间，他会参考以前同类任务所需花费的实际时间，以及别的同事的时间估计。

　　（2）小飞会试着写一些快速原型的代码，看看效果会怎样。他在这一过程中发现了一些问题，通过和PM沟通，他们取得了一致意见。

　　（3）在看到初始效果和了解了实现的细节后，小飞开始写设计文档，写好之后，他可以请同事一起来复审设计文档 （复审可选，因为一般情况下任务都不大）。

　　（4）设计文档写好之后，小飞就会按照设计文档写代码。 在写的过程中，他又发现了一些原来没有想到的问题，通过和PM沟通，找到了解决方案。

　　（5）写好代码后，小飞对照设计文档和代码的指南作自我复审。

　　（6）创建或更新单元测试。

　　（7）进行单元测试（不仅要通过自己新创建或更新的单元测试，还要通过整个模块/系统的单元测试）。

　　（8）重构代码，如果必要的话。

　　（9）代码复审。

　　（10）把代码签入代码库中。

　　由上可知，开发者必须写自己代码的单元测试。开发环境必须能够很快地让一些小的修改通过（做一个代码修改的最低成本是多少？例如，如果我只改动一个无关紧要的功能，要多长时间才能运行所有的单元测试。要求：快速，自动化）。

　　14.4.2把修改集集成到代码库中

　　现在开发人员手头上有不少修改，分别属于不同的具体任务，那如何把这些修改签入源代码控制之中呢？

　　（1）根据场景和开发任务来决定集成的次序。

　　（2）互相依赖的任务要一起集成。

　　（3）在测试场景时，要保证端到端的测试。

　　（4）场景的所有者必须保证场景完全通过测试，然后把场景的状态改为“解决”。

图14-1 移山公司开发流程

　　14.4.3标准开发人员的工作流程

　　综上所述，我们就可以得到开发人员的工作流程（如图14-1所示）。