@ironzhang
2017-03-07T13:52:46.000000Z
字数 1417
阅读 286
工作
回顾MQTT一期项目，特别是在接入原有业务的阶段，实际工期远大于预期工期，细思原因，觉有以下几点可以改进。
如果我们将设计工作分为以下几个阶段：
物理设计
这个阶段主要考虑如何满足需求(包括功能性需求和非功能性需求)，如采用何种算法和数据结构，用mysql还是redis来存储数据，数据库表格如何设计等都属于这一阶段的需要考量的，总之就是考虑解决方案的物理可行性。
模块的职责设计
这个阶段主要考虑这个模块在整体系统中的价值。如模块对上游系统提供哪些接口及接口行为，上游系统是如何调用这些接口的，以及依赖下游系统的哪些接口，这些依赖之间是否存在重入风险等。
模块内部的层次设计
这个阶段主要考虑如何分层，如接口层、逻辑层、核心数据层、对外接口层等等。此外，还需考虑各子模块之间的如何调用、调用依赖关系、以及各个子模块的可扩展性等。
模块的核心数据结构，核心算法，技术难点如何实现的细节确认
对核心设计的细节确认，确保不会有疏漏，大多数系统中这部分工作不会有什么挑战，如果不是这种情况，核心设计还有很大不确定性的话，需返回物理设计阶段，确认该模块的物理可行性。
合理粒度的职责切分
在每个子模块内部以类或函数为单位划分职责，明确每一个类的职责，以及这些类如何组合起来共同完成工作。
在第二阶段后，我们可以评估出大致的一个工作量，在第四阶段后，我们可以评估出一个更准确的工作量。而我们在讨论设计时，更多的是讨论解决方案的物理可行性，有时也会讨论模块需要对外提供的接口，却很少关注后面几个阶段的工作。
以本次MQTT项目为例，我们将目标分为了三个阶段的小目标
第一阶段目标 ，实现一个纯MQTT服务
前期我们针对解决方案和模块的对外接口都做了比较详尽的设计，在前期对内部的模块划分也做了比较仔细的规划，故而可以比较准确的评估出工作量。
第二阶段目标，安全协议的实现
这一阶段前期在协议设计上花了非常多的时间，但最后又决定使用老协议。这其实就是在还没确定物理设计的情况下，提前进入第二阶段的模块职责设计，导致做了许多无用功。
第三阶段目标，业务逻辑的接入
这个阶段其实是没怎么做设计的，只是评估了方案的物理可行性，对模块的职责确甚少考量，在实现时，基本是参照gateway的代码来移植的，因此对工期的预计就严重不足。
鉴于此，建议调整一下我们今后针对复杂系统的工作流程：先做物理设计，待讨论确定之后，再讨论模块职责，确认上下游系统相关接口。最后再做详细设计，以确认工期。
由于目标分阶段的关系，在开始我们只针对第一阶段的目标做了详细设计，对后面两阶段的目标，只是粗略思考了一下其方案的物理可行性。而在实际工作中，经常是在上一阶段的详细设计或编码状态时被打断，强行进入下一阶段的模块的职责设计阶段。
《人件》（peopleware）一书中有讲到：进入专注状态，需要15分钟连贯的工作，而一旦被打断退出专注状态，就像堆栈被清空，再次建立思维的缓存和上下文环境，需要另外的15分钟，在理想情况下。
个人觉得长期任务进入专注状态的周期更长，在打断后进入新工作，由于之前工作还未完成，心有挂碍，故进入新工作状态缓慢。而在完成新工作后回到之前的工作，又要重新恢复当时的思绪，阅读之前所写代码，又是一次缓慢的进入工作状态的历程。
个人建议，总体设计以第二阶段设计为界，即每个模块，都须明确其模块职责和对上下游的接口依赖后才能开展其他工作。