天之道，权衡之道

损有余而补不足，天之道也。—《黄帝内经》

有没有觉得这句话很熟悉？它其实出自黄帝内经。
而关于阴阳理论最重要的一点便是阴阳自和（现在通常译为“中庸”）。
正如健康的人是阴阳之间的平衡。
当某一方过于强盛，就损之，某一方过于虚弱，就补之。
怎样才算是平衡呢？关键就在于找准平衡点了。这便是玄机所在。
因为平衡点的位置因人而异、因时而异、因事而异动态调整的。并没有什么标准。
如果一定要说有什么标准的话，我想大概是“最合适的才是最好的”。

这和我们的程序有什么关系呢？
由于这个观点最抽象，最基础，所以在程序中最容易找到它的影子。

事物总有相对的两个方面，没必要非常扣上阴阳的帽子。
我的理解是，对于程序过程中遇到的各种问题，总会有些不同的解决方案。每个解决方案有其有点与据点。最终针对这个问题的策略是各个解决方案优点与缺点之间的权衡，而权衡无处不在。
没有哪一个点一定是对好的，最合适的才是最好的。

设计模式里有这样的观点，应对变化最基本的思路就是预测变化，封装变化。
那么把所有可能发生的变化都封装起来，就是最好的设计了吗？
可是多一次封装就相当于多一层抽象，抽象则会带来理解的困难。
经常有人跟我说C++难读懂。那是因为我们习惯了C代码。C++与C相比多了许多抽象的用法，所以难懂。
抽象层次太多带来阅读困难，就要减少抽象。
抽象太少难以修改，就要增加抽象。
因此设计模式提出的封装变化，并不是要封装所有的变化，而是修改与阅读之间的权衡。

coach经常向我们宣传TDD，因为这种边开发边测试的方法能够有效地保证代码质量。及时测试也能及时发现问题。
可是真正在开发过程中，没有什么人使用，因为写起来太累了。
我并没有认为TDD一定是多好或者多不好，在开发过程中用不用TDD，或者用到什么程序，只是开发与测试之间的权衡。
开发人员写代码通常是为了开发，不太喜欢考虑测试的事情，那么TDD的天平倾向了便于开发的这一段也很好理解了。

我们的文件系统中，经常有大量的数据要管理。最原始的数据管理方法就是把数据一个一个地排好，需要这个数据时就从头到尾按顺序找。用脚趾头想想都知道，随着数据的增加，这样文件系统速度肯定快不了。
于是牛人们设计了各种各样的数据结构，以树为主，像B树、红黑树这些。分别针对不同的存储介质、存储对象等因素设置的。
树的形状虽然各不相同，其原理都是一样的，就是在合适的位置增加一些指针，指向某些特定的数据，再基于这些特定的数据进一步查找，以些方法来更方便地找到所需要的数据。
当然，要存储这些指针也要牺牲一些存储空间。合理设计数据结构的话，也是指针也多，查找速度也就越快，所牺牲的存储空间也就越多。究其本质，还是时间与空间的权衡。

这样的例子，还可以举出很多很多。

。。。此处应当有个总结，但是我感悟不够，写不出来^_^