其他

架构评审的意义

2017-03-02 史海峰 IT民工闲话

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

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

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

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


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

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

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

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

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


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


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

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

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


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

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

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

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


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

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

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


架构评审的目的是什么?

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

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

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

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

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

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


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

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

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

随便举几个例子:

  1. 互联网金融公司的系统没有对账机制——你还敢投钱在里面么?

  2. 有的人号称玩转高并发多线程,扣减积分/余额程序就是先查询,再判断够不够,够的话就减掉后更新。——不知道被人白刷掉多少呢,刷多了应该能发现,拜托,对账都没有,你怎么发现?

  3. 对异常情况考虑不全,数据流断了,数据就丢了,逻辑要是再复杂点儿,时间再久一点,再想修复?愁死你。

  4. 核心业务应用,方案设计很费心思,但没考虑过性能指标,也没想过怎么监控告警——这都是没吃过亏,捅过篓子的。

  5. 有人对着自己的完美方案讲着讲着,不等别人指出,就发现了数据逻辑没有完整闭环的问题。


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

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

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

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

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

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

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

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


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

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

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



3月由中生代技术&iTechPlus发起的年度大会降临魔都,20+话题,6大主题,

干货专家悉数到场,学习是一辈子的事,坚持学习,成为优秀人才!


优秀人才不缺工作机会只缺适合自己的好机会。但是他们往往没有精力从海量机会中找到最适合的那个。

100offer 会对平台上的人才和企业进行严格筛选让「最好的人才」和「最好的公司」相遇。

扫描下方二维码注册 100offer,谈谈你对下一份工作的期待。一周内收到 5-10 个满足你要求的好机会

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存