史海峰：架构评审的意义

许多公司的项目流程中都有架构评审环节，却鲜少有人提起，大概对于参与者来说都并不是多么愉快的经历，一提都要皱着眉头，各有一肚子苦水涌上心头，慨叹不堪回首。

网站建设公司,为您提供网站建设,网站制作,网页设计及定制网站建设服务,专注于成都企业网站定制,高端网页制作,对成都石雕等多个行业拥有丰富的网站建设经验的网站建设公司。专业网站设计,网站优化推广哪家好,专业成都网站推广优化,H5建站,响应式网站。

被评审的同学感觉像是过堂，冥冥中有人在高声呼喝“升堂~~威武~~”，生怕自己一句话没说明白，对面的黑脸胖子就会蹦起来叫“开铡”，没通过评审连死的心都有。

依我看，这源于认知冲突(这个词儿是从《架构即未来》里学的)，参与各方的认知不一致，甚至引发情感冲突。

今天简单说说我对架构评审的认识，主要是评审的意义所在，理解了意义，目标一致，自然同心协力。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

架构评审的目的是什么?

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

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

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

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

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

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

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

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

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

随便举几个例子：

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

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

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

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

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

有些被评审的，在评审时感觉低人一头，仿佛被人审判，进一步会想“凭什么你来评审我，你算老几啊，这业务你没我懂啊!”对不起，这真不是业务百科知识大赛。

身边的人牛就不爽，觉得没啥了不起，碰到业界大神又惊呼真平易近人!

其实大神本来就平易近人，不会觉得自己高高在上，心智成熟，有自知之明。

大牛之所以成为大牛，也许就因为人家不飘飘然，脚踏实地，勤于做事，虚怀若谷，空杯心态。

系统是满足需求，实现业务功能的，大家都是为了能查漏补缺才坐到一起。

良好的心态才能合作，才能共赢。功劳是大家的，出了问题，共担责任，不能置身事外。

***一句，既然都来了，放下那些有的没的，好好琢磨方案才是正道!

【本文为专栏作者“史海峰”的原创稿件，转载请通过作者微信公众号“IT民工闲话（ITCrossTalker）”获取联系和授权】

戳这里，看该作者更多好文

网站名称：史海峰：架构评审的意义
文章路径：http://www.gawzjz.com/qtweb/news43/204293.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联