计算机界的泰斗唐纳德说过：过早的优化是万恶之源。
这句话有两层意思。
第一层意思是，比如说当你看到一个100ms的函数你可以把它优化成50ms的时候，此时你就要先抑制一下冲动。
如果100ms用户使用起来也没什么问题，那为啥一定要优化成50ms呢？如果只是一个小改动那也就无所谓，但如果这个是要改很多地方呢，改一下引入了bug怎么办。
更严重的可能是可读性问题。要优化的更快，几乎一定会牺牲可读性，因为要让机器跑的更快就势必要用上更复杂的算法，引入更多的概念，或者使用一些平时很不常用的技法。但我们的代码都是业务代码，80%的代价都在维护上，所以对于业务代码永远是可读性第一，性能第二。
100ms用起来也没问题，也没人投诉，说明没有真实的需求，没有真实的需求干嘛要优化呢，我们可以等待啊，我们要和时间做朋友，我们等到这个项目膨胀到加入了很多的功能以后，100ms降到了200ms了，那时我们再予以优化，就可以再把它优化回100ms，200ms->100ms，反而比你100ms->50ms，还提高了一倍的kpi。
和延迟满足感一样，我们要延迟优化。
不到最后一刻绝不优化。
很多人可以做到上面说的，因为上面说的其实是一个单一的具体问题。但是唐纳德的话还有第二层意思，那就是我们的架构也不能提前于需求。
我看很多人做架构，老是想提前于需求，他们把所有未来可能发生的情况都考虑到了，然后设计出了一个宏大的架构，以为这样的架构就可以容纳以后任何的变化了，他们认为这样才是一个完整的架构，这才是架构的涵义。
然而这样的做法完全违背了敏捷。
世事无常，未来实际并没有这么容易预测。一个宏大的架构本身，导致了它不能很迅速的响应变化。
未来的实际很可能是产生的变化会超出这个架构之前的预测，会往这个架构之前完全没有想到的方向发展，导致你搭建了一堆东西，没一个能用得上，之前的东西全废了。然而因为之前搭建的东西太多，为了适应新的变化就要改超多的东西，或者根本就没法改必须推倒重来了，这就是无法承受的巨大代价。
造成这种错误思维的根源在于我们还是***满脑子想的都是要毕其功于一役，把架构看成是一次性的搭完了就ok的静态的东西。我们不愿意做时间的朋友。***
做架构的根本目的不是把未来的所有可能性都得现在就考虑好了搭建好了，而是当未来变化来临的时候，确保在那时，之前的架构可以用最小的代价来实现新的需求。
做架构的根本目的就是让我们能够有能力去***延迟决策***。把决策延迟到未来事情真正发生的时候再做决策，因为只有那时做出的决策，才是针对那时的需求的最有效的决策。而我们知道无论未来做什么决策，我们现有的架构都能支持我们快速的适应未来的决策。
这才是一个专业架构师的核心思维方式。
架构本来就是code，不应和code区分对待。
架构和code一样需要进化。用进化发展的眼光去看架构，有多少需求就做多少架构，未来才会留有余地。做时间的朋友，随着时间不断改善架构，直到项目终结之日，架构工作才能算是终结。
之前写的相关主题：
关于软件架构的最大误解
保留变化