史海峰:架构评审的意义

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

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

[[184623]]

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

[[184624]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

架构评审的目的是什么?

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

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

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

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

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

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

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

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

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

随便举几个例子:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

责任编辑:武晓燕 来源: 51CTO专栏
相关推荐

2022-03-02 10:32:41

架构师系统架构

2021-09-06 08:55:16

软件开发 架构

2021-03-26 07:47:18

单体架构程序

2021-06-09 08:09:05

架构软件整洁

2009-07-08 16:46:54

J2SE 5.0

2013-04-02 14:27:02

架构架构评审

2010-02-05 15:46:41

IBM Power

2022-07-01 18:30:32

架构IT人生

2016-08-08 13:59:02

MySQL架构数据库

2011-09-01 09:34:21

架构

2017-09-16 18:29:00

代码数据库线程

2018-08-22 17:58:01

数据平台数据仓库架构

2011-02-22 17:25:42

LinuxUnix

2021-04-12 09:48:50

MVCHTMLCSS

2017-09-12 17:56:06

腾讯云云+未来

2014-12-31 17:16:15

知乎架构变迁史

2015-06-02 04:17:44

架构设计审架构设计说明书

2021-04-30 09:16:08

软件架构命名

2019-02-15 15:14:53

服务器开发 架构

2009-11-13 05:30:38

PowerIBM
点赞
收藏

51CTO技术栈公众号