写点什么

架构评审的意义

2020 年 4 月 09 日

架构评审的意义

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


架构评审的目的是什么?


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


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


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


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


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


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


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


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


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


随便举几个例子:


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


2020 年 4 月 09 日 16:00702

评论

发布
暂无评论
发现更多内容

最通俗易懂的 Redis 架构模式详解

哈喽沃德先生

redis 架构模式 redis集群 redis哨兵 redis主从

闲聊胡扯

C语言与CPP编程

随笔杂谈

AtmoicXXX与AtmoicXXXArray源码分析

Darren

源码 内存布局 CAS java 并发 AtmoicXXX

甲方日常 7

句子

工作 随笔杂谈 日常

微服务下数据一致性的几种实现方式

xcbeyond

微服务 BASE理论 数据一致性

Flink检查点存在的性能影响-16

小知识点

scala 大数据 flink

oeasy教您玩转linux010203显示logo

o

Java集合源码学习笔记,Java程序员面试必备基础知识

Java成神之路

Java 程序员 面试 集合 架构师

Pod安装神策SDK报错Remote branch v2.1.3 not found in upstream origin

凌宇之蓝

ios 小程序flutter, 跨平台 CocoaPods pod React Native

架构师训练营0期 第十二周作业

WW

C语言与C++常见面试题

C语言与CPP编程

c++ 面试题 C语言

你真的了解 Base64 吗

hepingfly

Java base64 编码

mPaas 厂商push不通排查指南

阿里云金融线TAM SRE专家服务团队

android push

浮点数比较的精度问题

C语言与CPP编程

c c++

Docker 安装和简单使用

枫林

Docker

关于MySQL参数,这些你要知道

Simon

MySQL 参数

话题讨论 | 你的桌面上会放哪些有趣的小摆件?

InfoQ写作平台官方

工作 话题讨论 办公室

面试官问:Spring Boot中Tomcat是怎么启动的

Java小咖秀

tomcat 面试 springboot

终端传感了解吗?18个知识点为你扫盲

华为云开发者社区

IoT 信息化 传感器 传输协议 无线传输器

再爆安全漏洞,这次轮到Jackson了,竟由阿里云上报

YourBatman

Jackson Fastjson 安全漏洞 CVE-2020-24616

Docker -快速安装Elasticsearch

枫林

百度被绿了?

程序员生活志

百度 互联网 头条

Elasticsearch初步认识

枫林

Java elasticsearch ES

《我要进大厂》之mysql夺命连环13问

艾小仙

Java MySQL 面试题 Java 分布式 大厂

你真的懂AQS吗?透彻理解AQS源码分析系列之AQS基础一

InfoQ_d2212957090d

AQS

我们一起学程序-五子棋

叫练

Java 多线程 游戏 websocket

欢迎观看 AzureShow

亮小猪

云计算 开源 技术社区 azure 视频

深挖 Redis 6.0 源码—— SDS

yanglbme

redis 源码 源码分析

指针变量的传值和传址

C语言与CPP编程

c++ 指针 C语言

在Alibaba广受喜爱的“Java突击宝典”简直太牛了

Java成神之路

Java 阿里巴巴 程序员 面试 架构师

联盟:互联网时代的人才变革

非著名程序员

互联网 个人成长 人才 人才发展 突破圈层,个体崛起

新晋管理者都会遇到的6个问题

新晋管理者都会遇到的6个问题

架构评审的意义-InfoQ