保留变化

不知道你有没有下过棋。

以中国象棋来说，第一步你是可以直接用炮去兑掉对方的马的，但一般没人会这么做。

为什么？

虽然在开局用炮换马有点亏，但更大的原因是，因为棋盘上的子，兑掉一个少一个。棋盘上的子越少，你能走出的变化就越少，你的攻击手段就越少，你能牵制对方的手段就越少，你的先手就越没有用，整个局势就越容易往和局的方向走。

但没有人下一盘棋一开始就是为了求和的。

所以，占优势一方往往尽可能避免兑子来争胜，占劣势一方往往想方设法逼你兑子来避免自己输。

如果没有下过象棋，那么我可以再举个五子棋的例子。

每当你有了一个被防住了的三，你会在下一步马上加一个子去冲四吗？一般人应该都不会这么做。

因为冲四这一招，一旦使出，那个三的功效就被你基本用尽了，如果没有达到制胜或者扩大优势的效果，那么白白浪费了一个三。反而把这个三留着，引而不发，牵制对方，起到的作用可能更大些。

再举武侠的例子，也是如此。

一个高手，哪怕他面对对手有10种不同的出招方式，只要不到最后一刻，一般不轻易出招。那是因为，出了招之后还要收招，在收招到出第二招的间隙这段时间，便是对手苦苦寻觅的绝佳的反击时刻。所以，小李飞刀例不虚发。

我们写code，也是如此。

我们精心的设计code的框架，努力使每一行code都发挥最大的功效，就是为了当需求发生变化的时候，我们的code能毫不费力的“转身”。也就是说，这样的code保留了在将来变化的能力。

臃肿的大象转身快吗？如果我们设计的框架十分的浮肿，里面塞了很多的生产效率低的代码，这样还能“转身”吗？

这里的关键是设计，设计，设计，重要的事情说三遍。通常来说，如果一个问题可以通过改变设计来解决，改变设计往往是成本最低，副作用最小的方案。只通过改变设计来解决既有的问题可以最大化的保留code在将来变化的能力。

如果只是为了解决一些现有问题而引入重量级框架，那么code就势必要围绕着这些重量级框架提供的功能和pattern来写。当你很多东西都follow这些重量级框架的时候，那么剩下的你能自我发挥设计的地方就越来越少了。也就是说这些重量级框架会“挟持”你的设计，极大的压缩你根据需求做自由设计的空间，结果就是你再也无法维持小而美的最最最契合需求的设计来保留进一步变化的能力了，你把这种能力拱手送给了这些重量级框架来托管，而这些重量级框架今后会如何迭代演变根本不是由你说了算的。

重量级框架为刀俎，你为鱼肉。还有一句话叫自己动手，丰衣足食。

以不变应万变的核心是让自己随时可以变。

人生，是不是也应该保留变化？