评审很重要
为什么说评审很重要乃？因为从各种各样的实践得知，评审能有效减少问题的存在，推动项目实施。
如果你经历过稍微复杂一点的项目就知道无论是从原型评审，ui评审，数据库设计评审等等，都可能存在各种各样的问题，我们需要评审来尽可能在某个阶段开始之前就发现问题，解决问题，并经过多方讨论达成一致。
1. 原型评审
当项目开始的第一阶段应该是原型评审，需求评审一般都是在产品内部就做了，所以我们就不做过多描述。
原型评审最容易出问题的就是逻辑关联性，比如一个字段的展示，这个数据从何而来？这个数据格式是怎么样的？这里的操作对其他页面功能的状态影响是什么等等。
如果原型逻辑是有问题的，经常就会导致数据库设计有问题，然后就是开发代码逻辑有问题。
所以，原型评审在这里就特别重要，即使原型上面有一点小的展示问题都不会存在特别大的影响，但是逻辑问题往往很致命。
2. UI评审
原型评审完就是ui评审，ui评审比较容易出问题的是和原型设计出入较大，交付逻辑不清晰，具体页面缺失等等。
甚至可能交付的变动就会导致接口等多方程序变动，如果在ui评审之前就已经进入开发或者完成了接口定义的，往往造成各种变动。
ui评审不足以有很大致命，但是会影响开发老师效率和测试老师的测试用例，所以我们非常有必要进行ui评审。
3. 数据库设计评审
有的公司项目是原型评审完直接就进入数据库设计，根据原型进行数据库设计。
数据库设计往往是研发的核心，数据库设计好了即使有部分逻辑变动，都能比较好的应对，如果数据库设计不太合理，改动就可以说天翻地覆，这是开发最不想看到的。而且我们曾经还出现过索引设计不合理，上线后运行一段时间大批量出现死锁问题。
所以如果想保证一个好的研发质量，那么技术leader应该发起一场数据库设计评审。
数据库评审主要针对字段设计合理性、索引设计合理性、表数据存储合理性、表关联设计合理性等几个方面做考虑。
4. 技术实现方案评审
在一些复杂度高或者难度大的项目，我们往往有多种实现方案,而且每种方案各有优缺点。
虽然技术实现评审比较少，但是依然具有很好的意义。每个研发的能力水平思考方式都是不同的，所以针对一个功能的实现可能会不同，如果增加一个技术实现方案评审，在开始之前就经过充分讨论考虑，后面出问题的情况也是非常少的。
5. 测试用例评审
有时候我们往往忽略测试用例评审，测试做为最后一个项目最后阶段把关人，我们更应该引起重视。
在一些项目中经常会出现研发测试产品三分理解的不一致，结果都快上线了，发现功能完全不一样。所以针对测试用例的评审就非常有意义了。
当然如果某些项目根本没有测试用例，甚至测试点，那也不存在测试用例评审了。
其他评审
除了以上几种评审外，有些公司项目流程多且复杂，还有一些其他评审，比如研发的代码评审。无论是哪种评审，其目的意义都是为了减少环节中的问题，让所有人达成一致或者形成较好的规范。
评审细则
每一种评审的着重点和要求各不一样，但是评审的时候务必要知道我们评审的一些细则要求是什么。我们拿测试用例评审举例：
- 测试用例是否完整，是不是存在没有覆盖的测试点
- 测试用例执行逻辑是否正确
- 是否存在和需要反向测试用例
- 单条测试用例描述是否和需求原型相匹配
- 测试用例是否有指定角色，指定环境等条件限制
- 测试用例是否覆盖了特殊平台的测试点
- 测试用例中的功能路径是否正确
- 该条测试用例是否为冒烟用例
以上只是大部分举例，所以我们需要清楚的知道每次用例评审需要评审一些什么内容，它的评审细则是什么。
注意事项
- 评审需要把握时间，如果一个简单的东西评审时间就是一天，就需要想想是不是哪里出了问题；
- 评审时应该做好会议记录，记录会议中的各个事项及问题；
- 评审要求相关干系人必须到位，不然评审结果会打折扣；
- 评审务必细致仔细，而不是草草了事；
- 评审之前应该所有人抽空浏览一下评审内容，有助于提高评审效率；
- 如果第一次评审结果就非常差，那么应该进行完善后再进行第二次评审。
总结
经过长期实践，这些评审在一个项目中能起到非常好的作用。如果我们存在这样的条件，都应该尽力去做评审，项目如果能做到每个环节可控，那么自然项目就比较顺畅。
