未来可以预测吗，除非你有特异功能，否则预测未来不就是在瞎猜吗。
彼得林奇告诉我们，不要去预测股票的走势，而要专注于研究公司的基本面。
但是这么简单的道理，我们很容易就忘光光，特别是在代码架构上，这个问题尤为突出。
很多时候说到架构，别人就会说，这么design可以更符合未来的需求，或者讨论的时候会提出这样的问题，如果未来怎么怎么样了，那你现在的架构还能支持吗。
我们设计的架构被未来的需求束缚住了手脚，可是未来的需求，我们无法预测它是否一定发生。
这样设计架构，考虑的实在是太多了，造成了很大的资源浪费。
人类总是倾向于自信的过了头，自以为能够预测未来，然而这根本不是理性。
很多人都认为架构是一竿子的事情，搞完了以后架构本身就再也不需要更新了，因为这种想法，导致他们总是在做架构的时候预测未来，甚至未来能不能work已经成了一个共识，成为了确定这个架构是好是坏的一个重要的标准。
我已经写过了很多架构不是一成不变的文章，此处就不再赘述了。
未来怎么样我们可以考虑，但不能放在主要的位置上。我们的架构可以假设一些未来的发展方向，但不能假设的过于具体，过于细节。
我们更应该考虑的，是对于现在的需求，我们的架构是不是能做到开发者能理解起来又快又准确，我们的架构是不是条缕清晰，可读性非常好。
只有这样才是真正的降低开发成本。
检测架构好不好的一个最重要的标准就是你的架构是不是一定需要资深的人才能读懂，是不是一定需要资深的人才能基于其开发。如果是这样，那么这注定是一个不好的架构。
白居易写诗，老太婆也要能听的懂。
能把当前的复杂需求，通过架构分解成初级员工也能理解完成的事情，这才是真正的降低成本。
做到了这一点，我们的架构已经具备了相当的灵活性。以后来了新需求，架构的变化修改就不会是难事了。所以完全没必要对未来的需求考虑太多。
把对未来的决策延迟到最有效的时候去做决定，也就是延迟到未来有了充分的新需求的信息之后在做决定，再去修改架构。而不是现在就去瞎猜把未来的事情先做了，然后就觉得高枕无忧了？
研究现在，研究现在的基本面，而不是研究虚无缥缈的未来。把现在研究的透彻，把现在该做的做到最好，那么等未来到来的时候应对变化也会是轻松的。
妄图一次架构就能管3年的，都是不切实际的幻想，都是静态思维，建议多找几本敏捷开发的书看看。
只有渐进式开发才是唯一正确的道路。