举例

## 举例 我们做一个简单的修改用户信息功能的API。那么我们在某一个Java技术栈上可能的任务列表是长这样的： 1. 写UserController （10分钟） 2. 写UserDAO （15分钟） 当你真正开始做的时候，会碰到两种主要的意外： 1. 任务列表扩张 2. 时间估计不准 下面就这个例子，就讲一讲当我们遇到这两种意外，该怎么反思和处理。 ### 任务列表扩张 任务列表扩张，顾名思义，就是指我们所估计的任务数量会随着我们开始工作变的比预想的多，可能有两种主要原因： 1. 技术原因 2. 业务原因 技术原因： 比如在这个案例里面，第二项任务是“写UserDAO”，就是一个没想清楚的事情。我们还需要建数据库表，我们在一个有migration脚本支持的技术栈设计上工作，我们还需要写初始化脚本和回滚脚本。也许这是我的第一个表，所以我还得配置数据库，搞不好还要把ORM的基础代码都写完，所以这些导致了我可能任务估少了。 再比如，项目规范要求我们Controller不能直接调DAO，要在中间加一个Service，尽管我个人觉得这是一件很二的规范，然而规范就是规范，我对项目技术规范不熟悉，导致我的计划缺少了一些必要的任务。再比如，我们的项目采用了Jersey，根本没有Controller这么一个东西，那么不了解技术框架导致我的任务表从根本上就列错了。 这种情况属于我对技术了解不足，通过对任务列表扩张的原因进行Check，我会得出一些Action：去了解技术规范、项目的技术架构、现有的代码，以防止以后的任务画错。 业务原因： 也比如在这个例子里，在更新用户的API里不能更新密码，所以我们还需要一个专门修改密码的API。再比如，这是一个遗留系统，用户信息的修改会触发数据库里的一系列触发器，进而修改系统的其他数据，然而有些修改是有前提的，那么我就需要更多的任务去处理这些前提条件；或者当数据变化时，要求我去修改系统里的其他数据，那么我就需要更多的任务去完成这些工作。 这种情况属于我对整个系统的业务了解不足，通过对任务列表扩张原因的Check，我会得出一些Action：通读数据库表、通读代码、更全面的阅读需求，或者跟需求方更多的沟通，以了解业务。 ### 时间估计不准 时间估计不准就简单很多，在这个例子里，可能的主要原因也有三个： 1. 任务列表扩张了，但是我没意识到。比如UserDAO写起来没有我想的那么简单，所以多花了时间； 2. 单纯的技术不熟练； 3. 花了太多时间在纠结上； 对于隐藏的任务列表扩张，不准确的时间估计给了我们一个很好的线索去发现。一旦发现了，可以如前文所述去处理，也就不再赘述。  对于单纯的技术不熟练，正如前文所述，要设计刻意练习。比如我就曾设计过针对数据库的增删改查训练以提升自己的速度，使我即便使用TDD依然保持一个极高的速度。**我们或许不曾意识到，基础能力的薄弱对于我们的高级能力的限制有多严重，这种体验也只有基础能力已经熟练的人去教基础能力不熟练的人一些高级技能的时候才会发现。**这种视而不见的收益，使得大多数人都会轻视基本功的练习。哪怕已经获得收益的人，也容易鼓吹要更多的启发而忽略了基本功的价值。 **对于花了太多时间在纠结上，这其实也是一种不熟练，是对设计知识和能力的不熟练。**之前看的设计知识只能有一个大概的感觉，对于每个知识的边界、使用之后的发展、如何从一种设计过渡为另一种设计了解不清，从而害怕在那一刻犯错。实际上真正值得纠结的部分没有那么多，大多是自己吓自己，或者引入了过度设计。 **当然也有一种情况是暴露出了架构级的问题，比如我们对于应该提出的原则性规范没有提出，导致我们每个地方都要现想**，大家可以想象在没有RESTful之前设计Web API，我们可能真的是每一个API都现想的，有了它之后，我们的纠结时间就变少了。这种情况下，通过本方法，架构师也算是有了相应的数据支持，那么架构师也就有了发现问题的一种工具。