写点什么

你是如何看待“过度设计”这件事的?

  • 2020-04-17
  • 本文字数:2201 字

    阅读完需:约 7 分钟

你是如何看待“过度设计”这件事的?

知从何时开始,在 ‘烈火中烧’ 的日当午跑步,变成了我非常喜欢的一件事情,身边有人觉得这是种不可理喻的自虐行为,而且过于极端,不过在我看来这样做有 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


2020-04-17 15:04737

评论

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

第九周学习总结

orchid9

第九周作业

Geek_ce484f

极客大学架构师训练营

第九周作业总结

Geek_ce484f

极客大学架构师训练营

真零基础Python开发web

MySQL从删库到跑路

Python django Web bottle

助推城市智慧化!正舵者携手中科院演绎区块链魅力

CECBC

区块链 人工智能

架构师 01 期,第九周课后作业

子文

第五周学习总结

晴空万里

极客大学架构师训练营

架构师训练营 1 期 - 第九周作业(vaik)

行之

极客大学架构师训练营

第9周作业1

Yangjing

极客大学架构师训练营

第九周作业

极客大学架构师训练营

week5 作业二

Sean Chen

架构师训练营

Snowpack - 更快的前端构建工具

曲迪

效率工具 大前端

训练营第九周作业 2

仲夏

极客大学架构师训练营

一致性 hash 算法的实现

幸福小子

一致性Hash算法

极客时间架构 1 期:第 9 周 性能优化(三) - 命题作业

Null

第9周作业2

Yangjing

极客大学架构师训练营

第五周作业

晴空万里

极客大学架构师训练营

大数据和Hadoop平台介绍

MySQL从删库到跑路

大数据 hadoop

常见的负载均衡实现方案

幸福小子

负载均衡架构

Week 9 作业01

Croesus

训练营第五周作业

大脸猫

极客大学架构师训练营

架构师训练营 1 期 - 第九周总结(vaik)

行之

极客大学架构师训练营

请简述 JVM 垃圾回收原理

orchid9

数据库工程师整理最常见mysql面试题,每一道都是工作面试经典

小Q

MySQL 数据库 学习 架构 面试

架构师训练营第九周课后练习

薛凯

文件上传踩坑记及文件清理原理探究

比伯

Java 大数据 编程 架构 计算机

极客时间架构 1 期:第 9 周 性能优化(三) - 学习总结

Null

Netty源码解析 -- 对象池Recycler实现原理

binecy

Netty 对象存储 高性能

第九周学习总结

Meow

第九周作业

Meow

你是如何看待“过度设计”这件事的?_行业深度_头哥侃码_InfoQ精选文章