开发——关于评审的看法

今天聊聊关于程序员开发之评审看法。
        评审——主要针对的是交互、视觉、测试三种评审而言。可能还有产品的需求讲解和串讲。这些看似与程序开发关系不大的评审，我觉得很多程序员没有做好这一点，包括我自己在内，我觉的非常错误，非常不好的习惯，我觉得这些评审就像是合作成员之间的交流，如果连这仅仅的交流都没有，后面只会有更多的不得已的沟通和繁重的工作。
        当产品把需求传达给交互和视觉后，交互会按照产品的意思去出交互图，出完后会号召所有开发人员进行交互评审，看看有什么不正确的地方和其他疑惑的地方，大家一起去讨论。其实这个时候，如果之前没有产品进行需求宣讲，一些很看重技术的开发人员这个时候几乎是什么都不知道的，处于一个懵逼的状态，基本上全程下来不发话，或者根据一些之前积累的业务知识去揣摩一些不重要的可能不正确的地方，那这个评审其实就失去了其意义。假如这个时候开发人员还没有很了解需求背景和需求真实意图，后面会带来非常多的问题，经历的人都懂的。因为接下来，就是视觉评审，视觉就是交互的具体表现形式，当视觉出来后，也会发起评审，当然了，一些很重技术的人在这个会估计也没有什么表述，假如视觉和交互是一起评审的话，那这个时候开发就要进入coding阶段，这个时候你会自己独立系统的研究需求，你会发现你有n多的问题，需要产品和交互去定。随着你开发的深入或许需求方面的问题会继续暴漏，这个时候还会产生各种其它问题，假如说你们的沟通成本不大，还能接受，如果沟通麻烦，那就有很多问题了，沟通后还要同步测试，这些都是因为前面的工作没有做好造成的。
        所以，我觉的我们一线开发一定要转变观念和看法，把源头做好，后面一切都会顺利。我认为在公司中都要找到一种方式尽最大的可能发现评审中的问题，不然后续会带来的更多问题；来分析一下造成的原因：
1. 需求的定义不清晰，交互有时候也是以一种完成工作的态度，没有考虑全面，评审的时候未当初确定，则造成开发和测试理解不一致；
2. 提需求时和已有的方案冲突，但开发人员并不熟悉产品细节的方方面面，导致不能及时发现，而实际开发的时候造成困扰；
3. Android和iOS两端的之前实现不一样，在此基础上继续开发，造成后续的困扰；
4. 交互、视觉通常以iOS为标准，没考虑Android 系统的差异性；


遇到这些问题后，我认为开发过程中遇到这些问题后开发往往很被动，因为这些问题为啥在评审过程中没有提出来，这时交互往往就一句话：我按照产品需求来，两端保持一致，产品也通常一句话：按照需求来；其实很多时候，我觉的开发站在用户的角度和产品多打交道，有时候产品只关注需求的价值，换个实现方式也许是一样的，并去引导交互，用更简单和实用的方式去实现；所以开发一定要理解需求及背后的原因，这样或许海阔天空。