知从何时开始,在 ‘烈火中烧’ 的日当午跑步,变成了我非常喜欢的一件事情,身边有人觉得这是种不可理喻的自虐行为,而且过于极端,不过在我看来这样做有 2 个好处,其一可以帮助有效的排毒,其二则帮助我有效的检测身体机能(如果 3 公里内就有中暑迹象,那就是个危险信号)。
身体机能 = 系统架构
通过引言,自然会有人问 “为什么 3km 内有中暑迹象就说明身体机能出现了问题?” 由于此话题涉及多项专业内容,欢迎有兴趣的读者通过私信与我交流
不过有一点需要说明的是,“3km 高温理论” 是我自己领悟出来的,那为什么不是 5km,而是 3km?
当然这需要有一个度量,就好比系统,设计的合理,给业务带来可持续的 ‘低投入,高产出’ 价值,这就是一套好系统、好架构
基础很重要,要 ‘多练练’
对于大部分人来说,想要取得某项运动的好成绩,除了天赋,基本都需要日复一日年复一年的刻苦训练,比起眼花缭乱的技术流,体能、肌肉及韧性的提升过程更加枯燥,但却至关重要,他决定了你能走多远、跳多高、拉多长
翻译下,系统的架构就好比 “体能、肌肉及韧性”,他不像业务功能那么直接了当、华丽取宠,但却紧握成败的关键钥匙
基础很重要,别 ‘练过头’
想起去年 “羽毛球汤姆斯杯” 某场比赛,‘前国羽队长-蔡赟’ 说到的一段话
“后场杀球很重的球员,通常出现在中国、日本与韩国,像印尼这样的东南亚国家很难找到,和他们交流过,他们基本不练力量,他们觉得光练力量会让人变笨,他们更注重实战节奏与落点,我认为这是我们需要向他们学习的地方”
翻译下,这段话其实反映了两国在训练方式上的一些区别,从某种角度看,架构设计的产出无非是让一个系统按某种训练方式进行执行,从而达到战胜各种需求的结果罢了
一桩由“过度设计”引发的惨案
说到这里,基本完成了主题铺垫,这是某次聚会中,我的好友(某知名互联网公司技术 VP)的酒后吐槽:
事件主角:好友手下的一名资深架构师(10+经验)
事件描述 - 上行篇:
某系统长久以来需求不断,80%都是“页面调整、数据规则变更、逻辑流程变更” 这 3 类
为了提升效率,避免重复编码,资深架构师利用一周时间,输出了一套 “可配置架构”
经过两天的评审,虽然有人提出 “担心由于后期维护能力或需求覆盖范围的风险担忧”,但总体上还是觉得相当出色的
评审最终通过,根据资源要求,技术 VP(我的好友)为资深架构师配备了 2 名资深开发,挑灯熬夜了近 40+个昼夜,系统顺利上线了
系统上线后,虽有少许 BUG,但总体运行良好,在经历了一个月的熟悉期后,开始发挥 “提升效率,避免重复编码” 的作用
事件描述 - 下行篇 :
上线仅一个月后,本系统对应的业务进入了创新周期,除了原有的需求外,部分超出架构覆盖范围的需求开始涌现
资深架构师提出了升级核心架构的方案,并在人力不足的前提下主动包揽了所有设计、开发的事项,仅用一周时间便升级成功
又过了几周,产品在创新上的不断探索,开始有大量需求由于系统架构无法满足,出现了排队、堆积的现象
资深架构师再一次提出了升级核心架构的方案,但这次要求除他自己,需之前参与过的两名资深开发加入,预计用时一个月
这样的要求,在强业务压力下,无论是风险还是资源要求,显然是无法满足的,所以技术 VP(我的好友)提出了绕过架构,采用硬编码的方式进行应对
就这样,这种方式延续了三个多月的时间,此期间系统架构升级过 2-3 个小版本(一周内能够升级的),也出过 1 次 P1 级事故,2 次 P2 级事故(其余小故障也有,但好友并未细说)
为了避免风险,后续采用 “能在架构覆盖范围内解决的需求,通过架构解决,不能够解决的,绕过架构,采用硬编码解决”
事件爆发:
这名资深架构师的半年绩效考核结果为 “中”,技术 VP(我的好友)的理由是 “功过皆半”
这名资深架构师在面谈过程中虽有过对峙,但最终接受了考核结果
从考核后开始,这名资深架构师开始 “说三道四”,大致意思是指责技术 VP(我的好友)胆子太小,如果不断加大核心架构的投入,迭代升级,一定如何如何
没有不透风的篱笆墙,终于在某次会议中,双方大吵了一架,本来是一场业务需求评审会,双方却 “兜起了老底”
事件结果(两败俱伤):
这名架构师主动离职,并且在离职过程闹得沸沸扬扬
技术 VP(我的好友)郁闷至极
故事就到这里,情节仍将继续
很显然,这个故事中还惨杂着技术管理的话题,不过单从纯技术视角来看,这显然就是一个“过度设计”的系统架构
在当今的互联网架构设计中,类似的情景相信不止我,连很多知名的‘大牛’都有过相似的经历,虽然这中间有着 “经验+运气” 的双重原因,但在这里我还是想说说自己对 “过度设计论” 总结出的观点:
在需求范围与方向未能明确的前体现,不应用先入为主的观点断定,可以用 “通用配置化架构” 解决效率等痛点,哪怕你已很有经验了
眼里容得下沙子,在面对新业务或新加入团队时,允许一定程度上的重复性代码,不要一脑子想着 “共享服务”、“代码精简”及“平台化通用”
让完美主义见鬼去吧,就算使用 “通用配置化架构”,也请采用 ‘微核心设计模式’,预留自定义扩展,为未来将 ‘自定义’ 转换为 ‘共享化’ 提供便利
面对说变就变、‘蛮不讲理’ 的需求,有时采用 「先污染,后治理」的方法可能更加接地气
相比之下,盲目的希望通过牛 X 的架构或平台一统天下等同于走钢丝;钢丝不断,就说你技术好,钢丝断了,恐怕你连解释或重来的机会都没有了。
本文转载自头哥侃码公众号。
原文链接:https://mp.weixin.qq.com/s/NmSIHFNTaB54sC8nx-fqGw
评论