你是如何看待“过度设计”这件事的？
不知从何时开始，在 '烈火中烧' 的日当午跑步，变成了我非常喜欢的一件事情，身边有人觉得这是种不可理喻的自虐行为，而且过于极端，不过在我看来这样做有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的架构或平台一统天下等同于走钢丝；钢丝不断，就说你技术好，钢丝断了，恐怕你连解释或重来的机会都没有了
最近技术类文章：
扫描二维码或手动搜索微信公众号【吃草的罗汉】
欢迎转载，带上以下二维码即可
点击“阅读原文”，所有【吃草的罗汉】近期的文章汇总
↓↓↓