许多公司的项目流程中都有架构评审环节，却鲜少有人提起，大概对于参与者来说都并不是多么愉快的经历，一提都要皱着眉头，各有一肚子苦水涌上心头，慨叹不堪回首。
被评审的同学感觉像是过堂，冥冥中有人在高声呼喝“升堂~~威武~~”，生怕自己一句话没说明白，对面的黑脸胖子就会蹦起来叫“开铡”，没通过评审连死的心都有。
依我看，这源于认知冲突(这个词儿是从《架构即未来》里学的)，参与各方的认知不一致，甚至引发情感冲突。
今天简单说说我对架构评审的认识，主要是评审的意义所在，理解了意义，目标一致，自然同心协力。
曾经有次架构评审，两位其他部门的同事问我架构设计有什么特别思维，要掌握哪些不为人知的高能技巧。
我当时心思还在方案上，顺口回答其实跟编程做开发都是一脉相承的，该怎么拆分解耦怎么抽象聚合，道理上都是一样一样一样的啊。
大概这个答案不符合两位同事的预期，他们脸上有些失望，还有些不以为然，可能认为我在敷衍或者是本身就其实难副，就没再继续交流下去。
似乎不久之后，他们都离开了那个公司，不知如今是否找寻到了满意的答案。
如今再想，当年的确回答得太狭隘了，架构设计还要考虑很多其他方面。
架构评审、跟技术方案评审、CodeReview一样，都是项目流程必要环节，是指对架构设计方案进行评审。
在传统的软件工程理论中，设计阶段产出物就是设计文档，包括概要设计/详细设计，但不分产品和研发，所以文档既包括功能描述，也包括技术实现，有些对日外包的项目，甲方发过来的文档里连伪代码都写好了，就等着你翻译成代码，外包工程师纯粹就是一个翻译机器。
而到了互联网时代，提倡敏捷迭代，总嫌传统方式太重，流程复杂，影响效率，什么都希望短平快，在扁平化的组织中，经常是需求火速分发到一线研发，然后就靠个人折腾去了。
实际上达到一定规模的公司多半会进行架构评审，即由架构评审组织(架构评审委员会之类)制定架构设计文档规范，设计人员根据规范编写方案，设计人员当面向评审人员讲解方案，回答评审人员问题，评审人员提出意见和建议，双方进行讨论以充分沟通，最终由评审人员决定是否通过，一次评审不通过可以修改后再次评审。
本质上架构评审跟测试相同，都为了保证质量，也没见谁对测试有多反感，宣称不需要测试通过就可以直接上线的。
由于技术人员普遍存在文人相轻的心理，对于参加评审被人挑毛拣刺的活动容易有所抵触。
评审过程中会讲到实现的关键点，因此有些相关人员也会参与了解，比如测试、数据、安全等，可能在无形中增加了被审者的心理压力。
毕竟架构设计代表着更高阶的技术能力，当面当众被指出问题要求修改，惯于“一人我撸代码”的研发人员容易自尊心受伤，面子上挂不住。
有强烈的技术个人自由主义倾向的同学，并不适合团队作战。
只注重研发实现，技术新潮，不关注线上性能、持续运维、故障应急的程序猿，再牛也不是好攻城狮。
自己的设计被指出问题，提出改进建议，不喜反恼，则是心态不成熟的表现。
架构评审的目的是什么?
把关，确保方案合格，各方面都考虑到了，避免缺陷和遗漏，不求方案多牛，至少不犯错。
保证架构设计合理和基本一致，符合整体原则。
维持对系统架构的全局认知，避免黑盒效应。
通过评审发掘创新亮点，推广***实践。
以上四点重要性从高到低排列。
可见，评审都是对事，而不是对人，参与评审的各方是平等的，各司其职，而项目是服务于公司业务的。
有人会自信满满拍着胸脯说自己的设计已经足够***，不需要再费时间给别人讲，你敢保证别人的也跟你一样***么?这次***了，下次也会么?
方案设计不仅仅是考虑功能实现，还有很多非功能需求，以及持续运维所需要的工作，需要工程实践经验，进行平衡和取舍。
架构设计往往没有想象中那么简单纯粹，甚至一多半的精力要关注非核心的方面。
随便举几个例子：
- 互联网金融公司的系统没有对账机制——你还敢投钱在里面么?
- 有的人号称玩转高并发多线程，扣减积分/余额程序就是先查询，再判断够不够，够的话就减掉后更新。——不知道被人白刷掉多少呢，刷多了应该能发现，拜托，对账都没有，你怎么发现?
- 对异常情况考虑不全，数据流断了，数据就丢了，逻辑要是再复杂点儿，时间再久一点，再想修复?愁死你。
- 核心业务应用，方案设计很费心思，但没考虑过性能指标，也没想过怎么监控告警——这都是没吃过亏，捅过篓子的。
- 有人对着自己的***方案讲着讲着，不等别人指出，就发现了数据逻辑没有完整闭环的问题。
有人会说经验都是趟坑积累出来的，否则没法成长，你问问老板愿意拿业务系统当练手的试验田么?
于是有了架构评审，更多有丰富经验的人花较少的时间成本，快速的过一遍方案设计，三个臭皮匠赛过诸葛亮，更何况有资格做架构评审的，都是见识过各种情况的。
但不代表评审的人就高人一等更权威，再牛的人，讨论技术方案，也要以理服人。
有些做评审的，认为浪费自己时间，因为总是那些常见问题，还要耐心听完，自己似乎没有得到什么提高，请注意，能避免犯错，系统不至于三天两头到处冒烟，这就是莫大的光荣。
有些被评审的，在评审时感觉低人一头，仿佛被人审判，进一步会想“凭什么你来评审我，你算老几啊，这业务你没我懂啊!”对不起，这真不是业务百科知识大赛。
身边的人牛就不爽，觉得没啥了不起，碰到业界大神又惊呼真平易近人!
其实大神本来就平易近人，不会觉得自己高高在上，心智成熟，有自知之明。
大牛之所以成为大牛，也许就因为人家不飘飘然，脚踏实地，勤于做事，虚怀若谷，空杯心态。
系统是满足需求，实现业务功能的，大家都是为了能查漏补缺才坐到一起。
良好的心态才能合作，才能共赢。功劳是大家的，出了问题，共担责任，不能置身事外。
***一句，既然都来了，放下那些有的没的，好好琢磨方案才是正道!
【本文为51CTO专栏作者“史海峰”的原创稿件，转载请通过作者微信公众号“IT民工闲话（ITCrossTalker）”获取联系和授权】
