写点什么

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

  • 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:04748

评论

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

大型企业引进低代码开发技术是大趋势

Sam678678

港股配资系统搭建

软件开发大鱼V15988750073

金融科技 港股交易系统开发 在线开户系统 CFD交易系统 港股多账户系统

跨越全场景统一架构三大挑战,MindSpore亮出“四招”

华为云开发者联盟

深度学习 联邦学习 mindspore 算子 ai框架

APICloud的发展和应用

anyRTC开发者

ios android 跨平台 sdk APICloud

盘点2020| 开启小马哥的新未来

小马哥

盘点2020

用Rust写点啥:数据结构篇——单向链表

Kurtis Moxley

数据结构 rust

【PS】给黑白照片上色

德育处主任

PhotoShop ps 28天写作

Android开发时的多点触控是如何实现的?

博文视点Broadview

看图学NumPy:掌握n维数组基础知识点,看这一篇就够了

华为云开发者联盟

Python 机器学习 数组 Numpy

Socket粘包问题终极解决方案—Netty版(2W字)!

王磊

Java socket Netty

开发复杂业务系统,有哪些设计思路

邴越

十八般武艺玩转GaussDB(DWS)性能调优:路径干预

华为云开发者联盟

数据库 sql 性能调优 GaussDB 算子

Redis 学习笔记 02:链表

架构精进之路

redis 七日更 28天写作

Java 异常处理

小方

Java java异常处理

Serverless 在 SaaS 领域的最佳实践

Serverless Devs

Serverless 云原生 SaaS

低代码开发技术

Sam678678

okhttp3 第一次使用

我就感觉到快

HDFS SHELL详解(6)

罗小龙

hadoop 28天写作 hdfs shell

与前端训练营的日子 --Week11

SamGo

学习

每个人都拥有这项神技能

熊斌

职场成长 28天写作

智汇华云 | 安超OS为企业数字化转型构建坚实的云基座

华云数据

僵尸进程的成因以及僵尸可以被“杀死”吗?

AI乔治

Java 架构 进程

智能合约上链系统开发|智能合约上链APP软件开发

系统开发

实时媒体AI,打破内容创作天花板,加速视频创新

华为云开发者联盟

人工智能 云原生 媒体 视频

微信视频号常见问题 | 视频号 28 天 (06)

赵新龙

28天写作

知乎问答:“既然生命无意义,为什么要活着?”

三只猫

28天写作

进来抄作业:分布式系统中保证高可用性的常用经验

华为云开发者联盟

高可用 运维 设计 分布式系统 系统

科技赋能传统产业:工业绿色可视化—核电站工艺流程组态仿真

一只数据鲸鱼

物联网 数据可视化 组态软件 绿色工业 核电站

夜莺二次开发指南-资产设备管理

ning

滴滴夜莺 夜莺监控

夜莺二次开发指南-任务执行中心

ning

滴滴夜莺 夜莺监控

调查bug的手段有哪些?(没有调查,就没有发言权,二)Jan 13, 2021

王泰

28天写作

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