当面临选择时，总是选择最简单的东西来解决你眼前的问题。然后确保你以后可以改变主意。我所说的最简单的事情是指最容易推理的解决方案。
当我们总是选择最简单的解决方案时，我们就可以避免分析瘫痪，即找出在我们可以想象的所有未来情况下哪个解决方案可能是最好的。我们只需选择最简单的东西，然后继续前进，因为我们知道以后很容易改变主意。在我们实施了简单的解决方案之后，我们对我们的问题有了更多的了解，我们可以问："我眼前的问题解决了吗？" 如果没有；重复。
复杂性是思维杀手！
当我们试图改变一个复杂的系统时，我们的思维会超负荷，这导致我们犯错。系统必须是可改变的，这是使它们不成为遗留问题的原因，它使我们保持敏捷和适应能力。
在可改变性的名义下，大量的复杂性被增加了。我们创建了微服务系统，所以我们可以改变我们的编程语言和服务实现，但我们增加了网络、服务发现、消息队列、容器协调等方面的复杂性。它还增加了资源开销，迫使我们提前进行横向扩展，这很复杂。我们是否可以简单地将实现隐藏在一个接口或一个函数后面？我们真的会很快改变我们的编程语言吗？它是否真的能解决我们眼前的问题？
始终着眼于你眼前问题的规模，找到你最简单的东西。这里有一些常见的复杂性陷阱。
- 当你必须存储一些数据时，不要急于马上建立一个数据库。一个数据库会增加网络、sql、模式、死锁等方面的复杂性。你能不能把它作为文件保存在磁盘上，甚至保存在内存中？
- 你需要使用那个框架或库吗？或者你能不能自己实现你实际使用的那个功能？
- 你需要CQRS、N-Tier、Redux或MVC架构吗？它们是否真正解决了你眼前的问题，还是说它们现在只是增加了复杂性？
- 你需要重构你的代码吗？还是你想让它 "更漂亮"，为可能永远不会发生的未来做更多改变？
最简单的解决方案往往是最快速的实现。这让我们可以更快地进行迭代，从而得到更快的反馈，从而得到一个更好的解决方案。对删除你的代码感到满意。你投入的时间越少，删除的伤害就越小。避免为一个有缺陷的抽象概念添加一个 "快速修复 "的诱惑。只需删除它，然后写一些简单地封装你的新抽象的东西。如果它是简单的，重写起来就会很快。
与其他工程领域不同，软件总是可以改变的! 利用这种力量，选择最简单的东西来解决你眼前的问题，然后在需要的时候再改变它。