十个现代软件过度工程的错误

世界很少有东西是随着时间一直增加的，这些稀有之物包括：恒星之间的距离，在可见宇宙中的熵，和业务需求。许多文章说不要过度工程，但没有说为什么以及怎样做到。这里有10个清晰案例告诉你这些细节。

1.软件工程比业务更加聪明
工程师们往往认为自己是最聪明的人。这第一个错误往往容易导致过度工程。假如我们计划了100件事，业务将永远会是第一百零一件事，也就是你从来没有想到过的。如果我们解决了1000个问题，他们会再有10000个问题。我们认为，我们已经控制了一切，其实 - 但我们不知道我们在干什么。

业务需求是发散，他们永远不会凝聚

发散是业务的自然本质，不是业务人员自己的错。

2.业务功能的可重用
我们尽可能的尝试对业务逻辑进行抽象分组和概括。这就是为什么大多数MVC系统最终会变成胖肪控制器或胖模型原因。但正如我们已经看到的，业务需求是发散，他们永远不会凝聚。

在自然系统中，共享的逻辑和抽象随着时间的推移倾向于稳定。随着功能越来越广他们要么保持持平或相对下降。如果不顺这个自然之势，而是主观往相反的情况去“作”时，就会创建太大而不能失败的系统（导致可怕的重写）。

案例：我们为前一个客户创建了一个用户配置文件系统。开始CRUD控制器是共享其功能的，因为我们以为一切都是相似的。但最终有13个不同的注册流程 - 开始是社交账户连接，而第一次进入时需要一个漫长的注册表单，这些都是看上去完全不同的页面等等，最终控制器共享已经变得没有任何意义，从而导致共享终结。

在水平拆分业务之前先尝试垂直拆分业务功能。这适合所有的情况下 - 隔离服务，基于主干的服务，特定的语言模块等，也有助于轻松从一种形式到另一种。否则，系统会变得越来越复杂以至于难以改变。

先隔离才能组合

3.每件事都是通用
要连接到数据库吗？让我们写一个通用适配器；
查询数据库？通用查询；
传递参数？通用参数；
构建参数？通用的构建器；
映射响应？通用的数据映射器；
处理用户请求？通用的请求；
要求执行整个事情？通用的执行者；
等等

有时工程师们会被业务问题带着走。而不是试图解决业务问题，这种试图找到完美的抽象实际是在浪费时间。

重复胜于错误的抽象

恰恰相反，重复有时是正确抽象的关键。因为只有当我们看到系统的许多部分共享“相似”的代码时，一个更好的共享抽象才会出现。抽象的质量是最薄弱的环节。重复暴露许多用例，使边界更清晰。

4.浅显的封装
这是这篇文章中最难的一个问题。

将一个外部库包在使用之前进行封装是常做的事情，实际大部分我们这种封装是很浅显的，我们总是挣扎于保证功能能够实现以及封装又要足够好之间。所以我们的封装大多是紧密与基础底层库耦合。如果我们以后改变底层库，封装器wrapper通常也会被改变。有时我们也把业务逻辑混合到封装器中，使它既不是一个好的封装也不是一个好的业务解决者，不伦不类。

开源软件库是神奇的。他们有很高的质量和可怕的人写的专门的测试代码库，他们是集中时间专门编写。大多数都是明确的、可测试的、真正有作用的API，允许我们遵循标准模式：初始化 - 准备- 实施。

封装是异常，而不是规范常必的。不要为了封装而封装好的库包，因为这些库包已经哟足够好的API

5.将无形的质量作为有形的工具
盲目应用质量概念（如改变所有的变量到“private final”，为所有类写一个接口等）反而不会让代码变得更好。

看看企业编程FizzBuzz，它有大量微观层面的代码。每个类遵循SOLID原则，采用各种设计模式（工厂、建筑、策略等）和编码技术（泛型、枚举等）。它从CQM工具获取高代码质量评级。

但如果我们退后一步，才能看到宏观。

自动化CQM工具跟踪测试覆盖率是好的，但不能告诉我们是否正确测试了。一个基准工具可以跟踪性能，但不能判断它是并行或顺序运行。人必须看大局。

学习一种不同的语言，尝试以另一种思维方式做事情。这从根本上促进开发人员更好。但是不能新瓶子装旧酒。我们永远不需要用一个概念的名称来撕裂一个清晰的设计。

6.过度热心综合症
如果明显的一个问题可以由特定的数据类型处理，或当正常类型的签名已经足够，就不要使用泛型。

发现策略模式，将每个if条件变成策略？
先问问自己为什么这么过度热心？

发现如何编写DSL，将DSL到处应用？

等等。

7.<X>–ity

可配置性
安全性
可扩展性
可维护性
可扩展性

这些目标很好，很难反驳。

但是，问自己一个简单问题，业务案例的上下文场景是什么？然后深入挖掘，这暴露了在大多数预先主观设计的缺陷。

8.关在房间里的发明
关在房间自己搞自己的专门发明，开始感觉很酷。

1.In-house库包 (HTTP, mini ORM/ODM, Caching, Config)
2.In-house 框架 (CMS, Event Streaming, Concurrency并发, Background Jobs后台任务)
3.In-house 工具 (Buildchains, 部署工具)

最终这些闷在房间搞的软件框架虽然开源了，但是自己公司却不再使用，别人因为其公司名声大反而盲目采用这些专有发明，掉入大坑。

还有两个错误见原文：
10 Modern Software Over-Engineering Mistakes – Med