专栏首页findyi我也曾对架构师的力量一无所知

我也曾对架构师的力量一无所知

镜头后的导演韩寒 虽说我和韩寒同年,但也算是“看着他长大”的。 韩寒成名于新概念作文,而后不断开挂,在作家、赛车手、导演等多个角色上都游刃有余且扮演的相当成功,如此色彩斑斓的人生一直让我艳羡不已。 而我,一介码农,初时随波逐流,醒时已亦步亦趋在架构之路上,艰苦非常。 因为,架构师的力量,我也曾一无所知。


1

代码执念

每个程序员对美的代码的认知不尽相同,但大多有个共识,那就是,架构师设定的各种条条框框简直是对美的亵渎!

其实,你可能对架构师的执念一无所知!

表面看到的:架构师成天没事找事,发布代码规范,设定评审标准。

执着于代码的洁癖,分层的固化、API的标准化、中间件的抽象化...

实际发生的:光秃秃(没注释)的形似被混淆过(儿戏的命名|对不齐的段落...)的千行代码,事务的注解可能在每一层都出现过。

逻辑代码散落在Business/Service/Dao各层,只是因为不喜欢Hibernate所以选择MyBatis,只是因为谷歌脑残粉所以选择Gson/Guava...

随心所欲的代码会带来维护的困难和各种技术债,不统一的技术框架会引入更多的学习切换成本和升级优化成本,评审口径不一致会导致团队聚焦散乱各自为战...

架构师作为团队的一个高攻厚血型英雄,着实操碎了心。

架构师的执念,就是尽最大努力,在低位面减少技术熵增,高位面寻求技术突破。

通过规范指定的标准都是低位面,不需要你在低位面上浪费任何时间扯犊子。而高位面一定是无法给出规范标准的,任你创新和发挥。 ”

同样是打印Hello World,就是有人会多渲染个ASCII字符画,让控制台输出不那么冷冰冰。

第一次看到架构师写出下面这种条件表达式的非常规写法时,

if ( 1 == iCount ) {}

if ( null != response && "SUCC".equals(response.getCode()) {}

年幼无知的我曾经“嗤”出了声:“写个等式都要颠三倒四,整噱头博眼球么?” 直到我写出了如下错误,

if ( iCount = 1 ) {}   
//漏了等号,永远为真
if ( response != null && response.getCode().equals("SUCC")) {} 
//少写判空导致的空指针异常

这种代码的反差犹如龙门客栈的老板娘金镶玉,看似风骚泼辣杀人越货,实则纯粹坦荡至情至性。

张曼玉版金镶玉

当你傻傻的写乘/除2的N次方时可还记得骚气的位运算...骚气的try-with-resource...骚气的Lambda...骚气的动态字节码...比比皆是。

这么些年我总结下来,架构师对代码的执念就是八个字:稳中带骚,骚中求稳

Python之禅 收个尾:


2

造物主思维

只活在IDE里写代码,是成不了架构师的。

某个风和日丽的下午,公司里一个小伙伴跟我说:他申请在一个月内重写消息网关系统(承载短信、微信、邮件、App推送四大渠道),原因是目前的系统太难用了。

我的第一反应是 “WOC,我一直盼望的那个救世主终于出现了么?!”

其实吧,那个消息网关系统曾经是我和架构组兄弟花不少力气设计的,本身并没有什么大问题,最多就是随着消息数量的指数级上升,需要做一些性能优化。

比如 分库分表数据归档 就能解决大部分问题,而这些升级所需的扩展性在设计初期就考虑过。

我生怕表现出对这位“救世主”的质疑而显得不礼貌,就小心翼翼的试探了两个问题:

“如何平衡上游业务的洪峰和下游消息通道的最大承载,最大化单位时间内的吞吐量?” ——微服务体系的流量控制 “个人交易消息和全局活动消息,如何存储和查询?” ——时间和空间的抉择

结果我得到的回复只是线程池、异步化和缓存的泛泛之谈,离真正的落地还差的很远。

除了上面2个问题,还有同步异步、时效、延迟、通道隔离、信息补偿、环境开关等的实现同样很重要。

造物思维就是从0到1需要的思维,这个1可不简单,它必须包含进化到100所需要的一切基础铺垫

女娲抟土造人只存在于神话中, 而架构师就是可以从0到1创造系统的“上帝”,只是翻船事故时有发生而已

不要轻视任何从0到1的创造性活动,这里所包含的知识或技能体量远超你的想象。

为了解释这个过程,请你单从数学的角度,告诉我 (0, 1) 这个开区间之中到底有多少个数

  • 如果是无穷,那么二进制的计算机如何运算这无穷的数字呢?有同学回答,计算机是使用离散的浮点数来表示这些小数的。是没错,而本质上,浮点数在坐标轴上也就只是很密集的点而已,根本就不是连续的线。
  • 既然全是点,更加疑惑了,计算机怎么画线呢?到这里就可以结束了,因为显示器的像素本就是人肉眼无法识别的小格子,足够密集的点足以呈现出线的效果。
  • 继续刨根问底,那得了解下什么是定点数了,才可以让密集的那些点更加的密集。

希望你能静下心来读读这篇浮点数, 读完你至少可以了解“取值范围”和“可表示的个数”之间、浮点数和定点数之间的区别等等。 《格物致知-Floating Point》

我想我应该从一个理科男的角度,说明白了创造需要的是什么:足够密集的知识点和它们之间的连接

也有人把它包装成了“知识体系”,说到底,一个意思。

创造本身已然不容易,如何创造更加五花八门。架构选型其实就是选择如何创造

同样是索引化的数据存储,Kafka是索引文件和数据文件分离,MySQL InnoDB却是索引和数据在同一个ibd文件里。

都说多线程吞吐量高响应快,Redis却选择了单线程模型(Redis6已经加入了多线程实现,主要用于处理网络IO上。命令的执行依然是主线程串行执行)。孰对孰错?

所以创造从来都不是千篇一律,也不是一成不变,而是量体裁衣

高明的架构师心里藏有无数的架构设计方案,但对于不同的场景,他会选择最合适的那个来实现。

因为架构更像一种艺术而不是科学。

你只看结论的话,或许最终方案并不怎么出色,甚至很普通。

但是它是经过N个方案PK胜出的The One,对其他你以为更好的方案所面临的未知,你可能一无所知。


3

面对未知的勇气

我有深海恐惧症,许多人都有。因为面对黑不见底的海水,我们充满了对未知的恐惧。

百度有时也挺人性的

IT行业的未知每天都在发生着,经常让我们手忙脚乱。

何谓"未知"?它可以是诡异的生产故障,可以是全新的技术,也可以是模糊的未来业务形态。

而架构师的核心职责之一就是从容的解决未知

对大家来说一样都是未知,凭啥架构师就有勇气从容应对?

原因很简单,架构师的身后哪里还有人?不得死撑哇!

许多诡异的生产问题有重启大法,但让习惯了SSH编程的你,使用Reactive来实现一套响应式服务端系统,这种未知领域你会如何应对?

更别谈连产品经理都看不清的未来业务形态,你又会如何设计系统的扩展性呢?

那么,我们如何对抗未知?谈以下两点:

1.草木皆兵

问:你这一生碰到过的最严重的生产事故是什么? 答:抱歉,从未碰到过。 ”

你会如何评价此人?架构师生而从容,不仅是做到泰山崩于前而色不变,更是因为严重的事故甚至细微的事故苗头都早已被扼杀在摇篮之中。

海恩法则指出:每一起严重事故的背后,必然有 29 起轻微事故和 300 起未遂先兆以及 1000 起事故隐患。

几年前有段时间我开车总觉得方向盘有点松动,一直没当回事,觉得可能车老了或者自己平时方向打太紧了。

某天预约做保养,车店老板小马哥把我车开走没10分钟,就给我来一电话:

“你的转向柱可能出问题了,方向盘有点松,你之前有发现么?” “我知道的,可能车老了吧,也没当回事。” “你小子,转向问题很吓人的,我都不敢开了,到店里马上帮你检查看看。” ”

后来结果你们也想得到,真的是转向柱断裂!幸好在事态严重之前,小马哥凭借专业素养发觉了这个隐患。

所以这到底是是我的无知无畏还是小马哥的小题大做

开车的同学都知道车的制动、转向是性命攸关的大事,但是你自问对 车跑偏、刹车异响、刹车发抖、转向沉重 都足够警觉么?

其实,架构师在评审会上表现出的“草木皆兵”亦是一种执念,他所看到的“尸横遍野”,你可能一无所知。

2.知道自己不知道

给你100W让你实现一个数据库,这活敢接么?就说这活本身,先别忙嫌钱多钱少。

把你所有的与数据库相关的知识拿出来,你看看能凑出下面哪些模块出来?

先搞清楚“知道自己不知道”的是什么,才有办法将未知变已知。解决未知就是不断的转化已知的过程

这也是为什么竞品软件都在造轮子,但是侧重点迥然不同,就是已知不同。

这个“已知”可以是商业产品、开源产品,也可以是论文报告,还可以是业务、技术痛点,不一而足。

RocketMQ当初参照了Kafka,在牺牲了部分性能的情况下优化了投递时效、消息顺序、消息轨迹等;

TiDB 是基于 Google Spanner / F1 论文实现的开源分布式 NewSQL 数据库;

开源调用链如Skywalking、Pinpoint都是基于 Google Dapper 论文实现的;

界面简洁、容量大、搜索强的 Gmail 横空出世,面对众多传统邮箱的狙击,依然成为人们最爱的邮箱品牌,顺便激活了半死不活的 javascript ...

未知? 不过尔尔。


4

架构师的天赋

只有天才的程序员,没有天才的架构师。

架构师靠的不是天赋,而是勤勉,要靠大量时间进行实战操练和经验积累。

身边水货架构师这么多,也是因为国内的技术氛围略显浮躁,留给架构师成长的那点可怜的时间和空间,时刻被公司项目挤压着,拔苗助长,不得不水。

热门吵架题目“架构师要不要写代码”,理性点的人会把架构师做个分类,摘出个比如 业务架构师,说可以不用写代码。

但是他不可能从石头缝里蹦出来,若没有对业务浸淫多年的历练(编码只是一个历练维度),如何能设计出合理的业务架构来?

所以别再问这种傻X问题了,何苦给自己的偷懒找借口还如此冠冕堂皇?宁愿换个题目讨论,“架构师的门槛是写多少行代码”。

所以,架构师并没有天赋一说,倒是要通过艰苦卓绝的奋斗逐步成长起来。

关于架构师的成长,说以下两点:

1.技术密度

程序员起步阶段的技术能力,通常是“蜂窝”状的,也就是存在大量的技术空洞,而这些空洞需要通过勤劳的采蜜,累积一点一滴的“蜂蜜”来填满。

科学爱好者都知道中子星的密度堪比黑洞,类比将地球压缩成中子星,直径只有22米,普通的原子都没办法在中子星附近停留,会被撕碎、经过引力坍塌后进一步压缩。

架构师就擅长这种吸收并压缩知识的套路。

硬要我给架构师的天赋定一个指标的话,那就是技术密度的高低。初二物理都学过 密度 = 质量 / 体积

对应到代码,同样质量的一个功能,你写一页,架构师寥寥几行,这就是高技术密度的直观体现。

2.有效练习

再来,假如已经部分交付如上图的一个“蜂巢”系统,现在需要你实现更多的“六角蜂室”以扩充这个蜂巢。

这个工作乍看起来像不像重复劳动? ”

其实不然。首先为什么选择六边形? 不是圆形不是三角形不是正方形?

经测量,六边形蜂室的所有钝角都是109°28′,所有锐角都是70°32′。曾有法国数学家研究过,如果要消耗最少的蜂蜡,制成更少间隙、更大容积和更坚固的容器,就只有这个角度的六边形。

其次蜂巢是倒挂的,为何液态的蜂蜜不会流出? 因为蜂蜜本身含水量不到18%,流动性比水要低得多,但低流动性不代表不流动。所以蜂巢要保持9~14度左右的倾斜,进一步防止蜂蜜流出。

实际结果是,你的“蜂室”交付了,但是你对角度,一无所知

只有真正的有效练习及背后的深度思考,才能促进一个程序员进化成为架构师。


最后的话

我生来觉得自己是个愚人,即使学习成绩一直算优秀,也会全归于自己的勤勉。

因为身边的天才好像真的不需要努力。

我能成为架构师,也是走上程序员这条不归路的不得已之选。

架构师之路漫长且艰难,而今我也只是摸到些许门路,大多时候对于自己的“不知道”依然惶惶不可终日。

你是否也曾对架构师的力量不屑一顾过?不管是立志成为架构师或已然成为架构师,都请谦虚并努力起来。

谁也不敢妄言自己掌握了架构的终极力量,因为:架构之路越走越无知,一如人生路。尊重架构师的力量,一如尊重未来的你。

作者:曲健 上海奥琪科技首席架构师 10年资深架构师 findy星球技术合伙人

本文分享自微信公众号 - findyi(gh_8766e6feadd0),作者:曲健Nicholas

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-05-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 聊聊时间管理,不是多人运动那种

    最近问我「时间管理」问题的洋友越来越多了。不少小伙伴问:你是如何在996的工作强度之下还能保持公众号持续输出的?还有小伙伴想知道我的日常工作安排,今天就写一篇文...

    用户6983566
  • 从微盟36小时故障,谈谈数据安全这点事

    很震惊!很震撼!吓得我赶紧召集全公司服务端小伙伴Review了我们所有的安全部署!!!

    用户6983566
  • 毕业4年年薪200万是怎样的一种体验?

    之前的一篇文章提到过自己毕业4年,年薪就超过了200万。最近有很多读者问我是怎么实现的,过程中有哪些经验可以分享。

    用户6983566
  • 架构师的成长之路

    Architect,即架构一词可以溯源到希腊语ἀρχιτέκτων , 指的是建筑的规划,设计和建造过程和结果。现在也用于指系统的网络,软件,硬件的规划,设计和...

    java乐园
  • 云架构师需要学什么?

    随着大数据云计算技术的发展,围绕这一技术也催生了很多的新的职业,比如——云架构师。何为云架构师呢?成为云架构师又需要学习和掌握什么样的技能?提出这样的问题,不免...

    用户3392176
  • 4年,从代码搬运工到架构师,成功的“催化剂”是什么?

    这也是我经常面试他人所问到的一个问题,很多人在听到这个问题后都会一股脑的说出来一大堆的专业名词,包括在座各位中一部分人也是这么认为的。比如一开口,架构师得会分布...

    Parker
  • 什么是架构师?

      很多的创业公司,一人身兼数职的情形还是很常见的。至少,我是经历过的,一个人包办了所有的开发过程,连测试我都做了,绝对的一条龙,但是经常踩钢丝、骑独轮车总会有...

    三哥
  • 什么是架构师?一 什么是架构师 二 架构师的职责三 架构师的误区四 架构师的基本素质五 架构师需要掌握的技术体系

    很多的创业公司,一人身兼数职的情形还是很常见的。至少,我是经历过的,一个人包办了所有的开发过程,连测试我都做了,绝对的一条龙,但是经常踩钢丝、骑独轮车总会有失足...

    美的让人心动
  • 码农从面试到架构师的进阶之路

    如何才能敲开BAT等知名互联网公司的大门?程序猿的职业生涯又是怎么样的?从码农到架构师,这期间要经历什么?以及如何才能在激烈的互联网行业中保持强大的技术竞争力?

    美的让人心动
  • 什么样的架构师才是真正的架构师?

      很多的创业公司,一人身兼数职的情形还是很常见的。至少,我是经历过的,一个人包办了所有的开发过程,连测试我都做了,绝对的一条龙,但是经常踩钢丝、骑独轮车总会有...

    java架构师

扫码关注云+社区

领取腾讯云代金券