代码灵活竟然是万恶之源！

在软件开发中有一句名言：过早优化是万恶之源!（Premature optimization is the root of all evil）。过早优化是很多程序员的坏习惯，但是程序员还有另外一个坏习惯，我们暂且就称呼它为：过早灵活化。

过早优化是万恶之源

过早灵活化的含义指是：向代码添加复杂度让它变的灵活，以期能应付未来的变化。程序员犯的最大错误是编写灵活而抽象的代码。我们中的一些人认为，编写灵活而抽象的代码有助于系统快速演进发展。我们编写接口、抽象类、框架和平台，假设它们能帮助我们更快地满足未来的需求。

在软件开发的实践中，“灵活性”和“可复用”作为流行语被大量的强调。为什么这样做是糟糕的？你肯定会有很强烈的疑问。我们都知道软件需求是会变化的，所以让你的代码具有灵活性，能够处理那些不可避免的变化，这样不是很好吗？大多数关于面向对象编程的经典都会阐述这一点，比如说通过使用抽象类，所以子类可以变化，因此我们的代码将是灵活的和可复用的，这样做不是很棒吗?

而现实生活中的严重失败的情况通常是这样的：不仅仅只是需求发生了变化，而且变化通常总是以刚开始程序员没有预料的方式发生。值得铭记的铁律是：灵活性必然伴随着复杂性，复杂性让改变更加困难。

换句话说：如果你把东西做得尽可能简单，那么沿着任何方向对它进行扩展至少都是可行的。（简单性原则可参考《奥卡姆剃刀原理、简单性原则与软件开发》）

简单性原则

开放-封闭原则（Open-Closed Principle）建议：我们应该能够通过不修改系统的方式扩展系统的行为。我们应该能够扩展系统的行为而不必修改该系统。 而这是一个广被误解的变成原则。

SOLID原则

从理论上讲，这是个好原则。 但我们使用的时候心里应该有一个警钟。那就是所有这些扩展点都带来了额外的复杂性。 复杂性使系统更难理解，也更难被改变。 更糟糕的是，我们的抽象经常是错误的，因为我们经常在需要实际灵活性之前就预先设计了它们。

Sandi Metz说过一句很经典的话：代码重复比错误的抽象要好。（Duplication is better than the wrong abstraction.）一旦抽象被证明是错误的，最好的策略是重新引入重复的代码，让它告诉你什么是正确的。

在软件设计也有一句著名的“使用-复用悖论”（Use-Reuse Paradox）：容易使用的东西很难复用。容易复用的东西很难使用。（What's easy to use is hard to reuse. What's easy to reuse is hard to use.）

我们再仔细看看设计模式，它们是面向对象的经典。它们中的很多模式都是让你如何使你的软件变的灵活。但是现实世界的例子是：一代又一代被淘汰的灵活框架。它们总是被其它的“灵活的”框架所取代，下一代总是证明上一代的错误灵活性。而C标准库。它的设计不是为了灵活，而是为了尽可能简单。30多年过去了，它还在被使用。

设计模式

另外，请注意“简单”是一个非常微妙的概念。它并不一定意味着“粗糙的”。简单的解决方案是解决你现在的问题，而不是解决你认为你后面可能会面临的问题。如果你能训练自己养成只解决今天的问题的强习惯，你明天就会比通过试图预测未来会有更好的准备。

灵活、抽象的代码很难使用，也很难理解。它们让我们编码的速度慢下来。请记住，速度是通过编写简单直接的代码和尽可能少的抽象来实现的。

抵制编写灵活代码的诱惑。通常情况下只编写简单直接的笨代码。只在必要时增加灵活性。

参考资料：

https://product.hubspot.com/blog/bid/7271/premature-flexibilization-is-the-root-of-whatever-evil-is-left

https://dev.to/codingunicorn/flexible-code-is-considered-harmful-13nm