迭代复盘之三员管理

前言

本次迭代做的工作主要是回收项目能力，具体做法是把 fork 出去的代码合并回来。

这次迭代因为各种原因，延期了快一个星期（周六还加了班）。

那么，我从工作流、方法论的角度，反思了自己可以改进的点，期望在这种迁移旧代码的实践中，抽取出能复用的经验。

动手前，至少梳理出接口清单

太轻信旧代码了，抱着代码迁移过来，跑起来就能用的态度，没能及时发现功能遗漏点，到了提测才发现有功能未实现，这是可以避免的。

更优的工作流应该是：

1. 先进行业务梳理
2. 整理出接口清单
3. 再进行代码迁移
4. 根据接口清单，逐个验证迁移的代码是否符合需求

迁移时，采取结队编程

看到有 500 个文件要迁移，觉得用分治的思路去实现会更高效，但这种思维有一个误区：做得快不等于有效率，因为效率需要的是有用功，而不是无用功。

实践表明，初期对业务的理解、代码的熟悉程度还不够深入，迁移代码遇到分歧点时，个人在独自处理时容易产生错误——而这种错误并不自知，这才是最蛋疼的地方。

所以，我才建议，采取结队编程实践，两个人一起来迁移代码，这样子遇到分歧时可以讨论，而不是贸然行动。表面上看，这样的进程慢了，实际上却能提高对代码、业务的理解，提高了迁移的正确率，真正地提高效率。

迁移后，需要对自己负责的功能设计测试用例

这里的本质，是不能完全依赖别人。虽然测试人员会编写测试用例，也会进行用例评审，但这里会有两个问题：

1. 前期评审时，自己的心思可能在理解业务、功能设计与改造以及代码迁移，没有多少心思能去 debug 用例的精细程度
2. 测试也是人，也会有遗漏，并且没有接触源码，有些特殊的、极端的边界场景，自己作为研发人员，更容易发现

可以看成，我们自己设计的用例是对测试人员给出的测试用例的补充。

当然，由于时间的关系，做完善的测试一般都不太可能了。
对于 legacy code，想补充 service 层的单元测试成本是很高的。写 controller 层的测试，可能也没有太多时间。
但至少应该用 postman 进行调试，或者在用户界面上点几下，不能完全等着前端或测试人员反馈，认为没有反馈就是没有 bug。