10种软件开发中 over-engineering 的错误套路

别把「不要过度使用 Generic」误解成「不用 Generic」，也别把「不要写一些不必要的 Wrapper」误解成「不写任何 Wrapper」。我只是在讲 over-engineering 这个事，只是在提倡不搞野路子编程。

攻城狮觉得自己最聪明，因为东西是他们写出来的嘛！然而这经常就是 over-engineering 的根源。即使我们考虑好100件事情，还是会有第101件我们没想到的事情冒出来。就算我们搞定了1000个问题，还是会带出10000个新问题。我们觉得一切尽在掌握，但是事实是要打脸的。

在我15年的 coding 生涯里，我还从来没见着哪块业务光用需求就能概括清楚了。业务总是会变得五花八门，这不是业务人员的错，这是业务的天性使然。

长话短说：别和业务争，他们是赢定了的

温馨提示：如果你时间不多，这篇文章 Get 到上面这点就够了

业务需求越来越多时（早就料到有这么一天），我们的反应是：

在合理的系统中，共享逻辑会随着时间沉淀下来，即使外部功能变多，也依然保持「身材」。如果你看到的情况与此相反，恭喜你，你手上的系统早晚难逃被全部重写的命运，因为实在难以做局部的改进了。 
在水平划分业务之前，最好先考虑垂直划分。比如不相干的服务，流程相关的逻辑，语言相关的模块，等等。这样一来改个局部的地方就比较容易，不用想太多。

长话短说：不要搞组合共享，要隔离

温馨提示：去代码库里挑一个和外部系统（Endpoint/Page/Job/etc）打交到的 Action 来看看，算一算这段代码的执行过程中需要切换多少个 Context/p>

（本套路有时候是与套路2一起发作的，有时也单独发作）

• 连接数据库一个 Generic Adapter
• 查询数据库eneric Query
• 传参数eneric Params
• 构建参数eneric Builders
• Map the Responseeneric Data Mapper
• 处理用户请求eneric Request
• 干所有的杂活eneric Executor
• 等等等等

有时候攻城狮就是管不住自己的欲望：不先去解决具体的业务问题，而是要浪费时间搞一个完美的抽象。 
设计只能是追着真实生活的需求跑，所以哪天即时我们吃了狗屎运搞出个完美的设计，完成的时间也就是过期的时间——业务变了。最吼的设计就是易于重构的设计。这篇文章提倡的是大家应该写删了不心疼的代码，而不是老是想着被扩展的代码

长话短说：错误的抽象比重复还要糟糕

如果要做合理的抽象，适度的重复是必须的，因为只有我们从足够多的重复中总结的抽象才是好抽象（别一开始没多少重复就着急搞抽象）。抽象的质量，往往是系统里最薄弱的一环。 
正经提示：在微服务之间搞抽象简直是灾难，会导致分布式巨无霸怪胎产生

以前用到外部库时，总要包装包装，但往往只是影子封装法。我们也就只在实现功能和打包第三方库之间玩玩小把戏。所以呢，我们所谓的封装其实是和底层实现绑得死死的（有时候只是1:1的搬功能，有时候甚至花10倍功夫来包装，而只实现了底层库1/10的功能）。如果以后我们把底层库换了，包装器就得跟着改。有时候还在包装器里带点业务逻辑，搞成个四不像，最后成了个懵逼胶水层。 
现在是2016年了，醒一醒吧！第三方库都已经做得又快又好了。写这些库的人都很聪明：质量好、测试好、有钱有闲写得好。用这些库的时候，就只管按照 Initialize-Instrument-Implement 的模式来用就行了。

长话短说：写 Wrapper 属于意外事件，不要当作常态。不要为了包装而包装

温馨提示：不是开玩笑，有人就是想搞能「海纳百川」的 Wrapper，理由就是，可以随时更换实现库啊！这是一种病，参照后文中的「可X性」套路

盲目地套用代码质量概念，并不能实际提高代码质量，比如：把所有变量都写成 private final，给所有的服务类都加一个 interface，等等。 
看下 Hello World 企业版 或者 FizzBuzz企业版 ，代码写得巨多，且搞笑。细看每个类都严格遵守实现准则了，设计模式也用得蛮多（工厂，构建器，策略，等等），编码技巧上也下了苦功夫（泛型，枚举等等）。拿工具一检测，代码质量给满分。 
但是，从大处一看，这货也就打印一句废话。

长话短说：别迷恋细节，要从大局出发

自动化代码质量检测工具能帮我们盯覆盖率这些东西，但是分辨不出测试是不是测了需要测的东西。性能检测工具能测性能，也不知道程序是并行还是串行跑出来的。只有人才把握得了大局。 
否则，就会催生出千层饼现象：把代码逻辑分割到10到20层面饼里面，但每一层对全局的了解都是懵逼状态。为什么会酱纸是因为我们单纯追求代码可测试性，或者单一职责原则这些东西，忽视了大局观。 
在以前，大家喜欢搞继承。A继承B继承C继承D等等。

有一些很好的原则，就是用来对付继承和其他OOP滥用的现象的。很多攻城狮不知道这些原则的来源，只管照本宣科，是有问题的。

长话短说：相同的概念在不同的领域有不同的含义。不要见得风就是雨，拿着锤子眼里只有钉子

在别的领域，要学会说人话。好的开发者要靠这个混。新瓶装老酒是行不通的。永远不要以套用概念的名义把设计搞乱。

无处不在的泛型。这个世道上，HelloWorldPrinter 都要写成 HelloWorldPrinter< String, Writer >

如果问题明显能用普通的方法、专门的数据类型来解决，就不要乱搞泛型。

无处不在的策略模式。连 if 都想用策略模式来做。

脑子有毛病/p>

无处不在的 DSL。想用 DSL重写所有东西。

不知所云……

喜欢用 Mock。测试时任何东西都想 mock 一下。

如果玩砸了……

元编程好屌，什么地方都搞一搞。

能讲讲理由么！

枚举好屌，扩展方法好屌，Traits好屌，好屌好屌，用起来！

骚年，这是不对的！

长话短说：不要什么地方都长话短说

瞎搞。不可理喻。顽冥不化。

栗子1：来做个可扩展性屌屌的 CMS 吧！业务人员可以随心所欲地给实体加字段。 
结果：业务人员从来不用。如果非用不可，他们会抓一个码农来帮他们用。本来就想要几个常用字段，快点出结果。结果你给我搞一个狂拽酷炫然并卵的界面出来。

栗子2：设计一个可配置性极好的数据库。改个文件就能自由切换底层数据库哦！ 
结果：10年以后，我只见过1家公司动真格去换底层数据库。到了真换的时候，那种所谓的配置隔离文件起不了什么作用。有太多运维工作要做了，不兼容性、功能不匹配，等等。等到我们的客户要求我们光换个配置文件就把半数表格换到 NoSQL 去，我们就疯了：配置文件只是千千万万要改动的地方之一，客户你玩儿我呢nbsp;
今天根本没有办法光凭一个配置层就能把传统数据库和新的 文档/KV 数据库（Redis CouchDB DynamoDB）统一起来。甚至不同的传统关系数据库之间也不行（MySQL Postgres SQLite）（这一段我不想翻译了，我觉得这个是个常识）

长话短说：重构是每天日常工作的一部分。没有什么代码是不能改的。

真心的，经常会见到素质还不错的攻城狮/团队却写出了一坨屎。看到他们写的代码，我们会想，卧槽，这真是那个号称很牛逼的人做出来的么

质量不光靠技巧，还要靠时间来凑。越聪明人的人，越容易自信满满导致估计失控。（WTF最后呢，只好靠一堆 hack 技巧和自杀性工作时长来把事情了结。

长话短说：还没写代码之前，错误的估计就能毁了工程质量

如果你能耐心看到这里，我谨在此表示由衷的感谢！还是别忘了，我只是在讲 over-engineering 这个事，只是在提倡不搞野路子编程。

来源：火山石