曾经有次架构评审，两位其他部门的同事问我架构设计有什么特别思维，要掌握哪些不为人知的高能技巧。

我当时心思还在方案上，顺口回答其实跟编程做开发都是一脉相承的，该怎么拆分解耦怎么抽象聚合，道理上都是一样一样一样的啊。

大概这个答案不符合两位同事的预期，他们脸上有些失望，还有些不以为然，可能认为我在敷衍或者是本身就其实难副，就没再继续交流下去。

似乎不久之后，他们都离开了那个公司，不知如今是否找寻到了满意的答案。

如今再想，当年的确回答得太狭隘了，架构设计还要考虑很多其他方面。

架构评审、跟技术方案评审、CodeReview一样，都是项目流程必要环节，是指对架构设计方案进行评审。

在传统的软件工程理论中，设计阶段产出物就是设计文档，包括概要设计/详细设计，但不分产品和研发，所以文档既包括功能描述，也包括技术实现，有些对日外包的项目，甲方发过来的文档里连伪代码都写好了，就等着你翻译成代码，外包工程师纯粹就是一个翻译机器。

而到了互联网时代，提倡敏捷迭代，总嫌传统方式太重，流程复杂，影响效率，什么都希望短平快，在扁平化的组织中，经常是需求火速分发到一线研发，然后就靠个人折腾去了。

实际上达到一定规模的公司多半会进行架构评审，即由架构评审组织（架构评审委员会之类）制定架构设计文档规范，设计人员根据规范编写方案，设计人员当面向评审人员讲解方案，回答评审人员问题，评审人员提出意见和建议，双方进行讨论以充分沟通，最终由评审人员决定是否通过，一次评审不通过可以修改后再次评审。

本质上架构评审跟测试相同，都为了保证质量，也没见谁对测试有多反感，宣称不需要测试通过就可以直接上线的。

由于技术人员普遍存在文人相轻的心理，对于参加评审被人挑毛拣刺的活动容易有所抵触。

评审过程中会讲到实现的关键点，因此有些相关人员也会参与了解，比如测试、数据、安全等，可能在无形中增加了被审者的心理压力。

毕竟架构设计代表着更高阶的技术能力，当面当众被指出问题要求修改，惯于“一人我撸代码”的研发人员容易自尊心受伤，面子上挂不住。

有强烈的技术个人自由主义倾向的同学，并不适合团队作战。

只注重研发实现，技术新潮，不关注线上性能、持续运维、故障应急的程序猿，再牛也不是好攻城狮。

自己的设计被指出问题，提出改进建议，不喜反恼，则是心态不成熟的表现。

架构评审的目的是什么？

把关，确保方案合格，各方面都考虑到了，避免缺陷和遗漏，不求方案多牛，至少不犯错。

保证架构设计合理和基本一致，符合整体原则。

维持对系统架构的全局认知，避免黑盒效应。

通过评审发掘创新亮点，推广最佳实践。

以上四点重要性从高到低排列。

可见，评审都是对事，而不是对人，参与评审的各方是平等的，各司其职，而项目是服务于公司业务的。

有人会自信满满拍着胸脯说自己的设计已经足够完美，不需要再费时间给别人讲，你敢保证别人的也跟你一样完美么？这次完美了，下次也会么？

方案设计不仅仅是考虑功能实现，还有很多非功能需求，以及持续运维所需要的工作，需要工程实践经验，进行平衡和取舍。

架构设计往往没有想象中那么简单纯粹，甚至一多半的精力要关注非核心的方面。

随便举几个例子：
互联网金融公司的系统没有对账机制——你还敢投钱在里面么？
有的人号称玩转高并发多线程，扣减积分/余额程序就是先查询，再判断够不够，够的话就减掉后更新。——不知道被人白刷掉多少呢，刷多了应该能发现，拜托，对账都没有，你怎么发现？
对异常情况考虑不全，数据流断了，数据就丢了，逻辑要是再复杂点儿，时间再久一点，再想修复？愁死你。
核心业务应用，方案设计很费心思，但没考虑过性能指标，也没想过怎么监控告警——这都是没吃过亏，捅过篓子的。
有人对着自己的完美方案讲着讲着，不等别人指出，就发现了数据逻辑没有完整闭环的问题。

有人会说经验都是趟坑积累出来的，否则没法成长，你问问老板愿意拿业务系统当练手的试验田么？

于是有了架构评审，更多有丰富经验的人花较少的时间成本，快速的过一遍方案设计，三个臭皮匠赛过诸葛亮，更何况有资格做架构评审的，都是见识过各种情况的。

但不代表评审的人就高人一等更权威，再牛的人，讨论技术方案，也要以理服人。

有些做评审的，认为浪费自己时间，因为总是那些常见问题，还要耐心听完，自己似乎没有得到什么提高，请注意，能避免犯错，系统不至于三天两头到处冒烟，这就是莫大的光荣。

有些被评审的，在评审时感觉低人一头，仿佛被人审判，进一步会想“凭什么你来评审我，你算老几啊，这业务你没我懂啊！”对不起，这真不是业务百科知识大赛。
身边的人牛就不爽，觉得没啥了不起，碰到业界大神又惊呼真平易近人！
其实大神本来就平易近人，不会觉得自己高高在上，心智成熟，有自知之明。
大牛之所以成为大牛，也许就因为人家不飘飘然，脚踏实地，勤于做事，虚怀若谷，空杯心态。

系统是满足需求，实现业务功能的，大家都是为了能查漏补缺才坐到一起。
良好的心态才能合作，才能共赢。功劳是大家的，出了问题，共担责任，不能置身事外。

本文转载自 IT民工闲话公众号。

原文链接：https://mp.weixin.qq.com/s/LAvimLyIgF9NjQO9PvMUzA

创作场景

架构评审的意义