曾经写过一点关于代码评审（code review）的文章，比如这篇和这篇，现在觉得关于它的认识又有了不少更新。软件工程的技术和实践分成两部分，一部分是和书本知识一致的，大约占一半，这部分基本上在大学里就可以学，自学只要方法得当、刻苦努力也可是途径；但是第二部分来自于实际团队、经验，内容通常无法从书本当中获得，而且难说对错，不同的人和不同的经历造就了不同的认识。代码评审就是第二部分颇具槽点，可以大加讨论的典型。

    关于需求评审的几个原则： 1、需求评审不是谁要说服谁，而是我们要就某一个具体问题寻找到最优的解决方案。 2、所有问题的讨论，都必须要先建立基本共识，然后基于这个共识再细化。 3、先不要在僵持不下的观点上浪费时间，先求同，后攻异。

    新年开始，大部分公司都在启动大量新功能的规划及设计、技术人员同时在设计对应实现方案、架构师或者技术主管则需要一天内穿梭在多个技术讨论中，评审并达成成熟稳定的设计方案。从架构师的角度来考虑，如何衡量一个技术方案的优劣呢？一、评审点从总体上讲，技术方案是衡量一个团队的开发成熟度重要一方面。技术设计是否围绕核心需求key features？模块依赖关系、兼容性是否得到充分清晰的描述及共识；设计上不同的方案是否得到了充分考虑比较？是否有正反的激烈的碰撞还是行政上的领导说了算？另外代码实现是否正确执行设计，还是代码实现边走边看，与设计方案基本脱节？从细节上来看，在软件企业内经常有不同形式的方案review，架构师在做review时候需要要考察哪些环节？从互联网系统设计的角度，总结到以下几点。简洁及可维护性从工程角度来看，避免难懂的方案。技术方案尽量象PPT那样，越傻瓜的方案越有生命力。当然

    在产品评审时是否有时候被一位高层打断，明确指出此产品与企业业务发展方向不符，不能实施？是否在讲解产品时，有些人员似懂非懂？是否产品评审太激烈时经常会忘记一些意见收集…… 相信类似上面这些情况在你在过产品时也遇到过，产品评审做为产品把关的重要环节，产品评审的重要性不言而喻。那产品评审到底是怎么一回事呢？ 评审，顾名思义就是关于审查和批准项目计划，产品变更和工作进展评价的一个步骤。 产品评审在产品过程中...