昨天项目组进行了一个设计评审，主要是对OpenExpressApp的AutoUI部分进行重构，我相当于评审人。大家也可以把这个评审过程当做与人交流你的设计思路的一个过程，以下从我评审的一些要素来谈谈与人交流设计思路时需要考虑的内容，也许对大家在实际工作中的架构、设计和沟通都有所帮助。
评审并不是审判，你直接说出结果之后，然后等着判官下笔，评审一定是基于特定主题进行的，所讨论的东西都围绕这个主题，那么如何让人先清晰你的这个主题是需要考虑的。对于不同人来说，每个人关注视角不一样，所以还需要针对这个主题，对于不同场合、不同参与者，你需要使用什么方式来讲哪些内容才能够让参与者都清晰。
影响我评审关注的一些观点
- 技术是为业务服务的，再考虑技术时一定需要想想为实际业务做了什么
- 你清楚的别人不一定清楚
一般自己做的设计会觉得很简单，可维护很好，但是没有做过的人理解起来很可能是相反的 - 你觉得简单的别人不一定觉得简单
就拿自己来说，我以前看些书觉得非常难，过了两三年后，再看之后发现这些书就像入门书一样。自己不同时期对难易理解不一样，更何况对于不同人来说呢 - 你对问题的理解不一定是对的
每个人对问题的深度挖掘能力是不一样的，有的人只看到表象，而有的人喜欢探索真正的问题，对问题的理解不一样会导致后续交流评审的内容完全不一样 - 你的比选方案选考虑因素不一定全面的
即使问题理解都一致，由于每个人的经验是不一样的，你的比选方案不一定是全面的 - 你的具体方案并不一定是最好的
即使你决定了具体方案，但也不一定是最好的，可能还可以在这个方案基础上再优化一些内容 - 评审也是沟通的过程
如何结构化的、从上往下或者从下往上、分块的阐述你的问题和设计？不要再还未了结需要讨论的内容以及必要性之前就直接进入细节，否则大家此时的沟通频道并不是在一个台
我的一些提问
- 问题是否正确？
- 由于是重构，所以我希望一开始看到的是罗列出来的现存的一些问题。
- 对这些问题，我们可以通过一句话的简单描述就都清楚，要是太长了估计就是多个问题。
- 把多个问题放在一起同时讲会导致沟通不畅。
- 对问题的正确性进行讨论
- 问题的深层原因？
- 问题描述清晰之后，我就会问为什么会出现这个问题？
- 是纯技术问题还是业务问题？如果是业务问题，必须拿出现有的实际例子来描述这个问题；如果是技术问题，就需要从质量属性去描述。
- 如果是有论据的一定拿出论据，如果是假想的一定说出是有待验证的
- 对深层次原因进行讨论
- 针对各个问题，逐个从上往下进行分析讨论？
- 总体讲完之后，我不喜欢跳跃式的逐层阐述每个问题，我更希望依次讨论完每个具体问题
- 针对具体问题你是如何思考的？
- 对问题的解决方案有哪些？
- 你是否有考虑过多个方案？
- 每种方案有何优缺点？
- 为何选择当前这种方案
- 开发人员如何使用你的框架？
- 对于做平台和框架的人来说，这个问题是必须问题。
- 如果是基于模型驱动开发的，还需要考虑你的框架是否可以支持模型驱动开发？
- 下一步的粗略计划？
- 优先级也是需要考虑的，特别是项目组中马上就开开发的情况下
- 可能你的方案需要几周或者更长时间，接下来三天你会做什么？接下来一周你会做什么？
