几年过去了，在实践中，我一次又一次地把系统中的症结往深处考虑，竟然发现它们不约而同地指向同一个根源：没有银弹！
一个非常朴素又普遍存在的理论，使我多次从困惑中跳出。

略列以下几条：
1.不要企图实现一个全息系统。
实例：权限模块在任何系统中需要，如果能建立一个完备的权限系统，将可以在很多系统中使用。
无论时间多么充足，这样的模块都无法完成。并不是这个系统过于复杂，而是因为我们计划实现的是一个全息的系统，它是连续的，而软件系统是离散的，无法用一个离散的系统实现一个连续的系统，可以使用多种方法来模拟，但是绝不可能真正实现一个连续的系统。

2.分析模式的使用
分析模式是前人对某一具体领域的归纳总结。但如果真的在分析过程中想把分析模式用到极致，就会发现自己已经走上了绝路。想适应所有的变化，想用一个系统解决这个领域中所有的问题，这是不可能的。

好久没抽烟，一支烟竟然是我有点晕了，睡了先。

当系统的复杂度达到一定的规模，任何小聪明都无济于事，还不如老老实实，做点实事。

一个前辈曾说：如何把事情做对是工程，如何把事情做好是艺术。

刚开始做软件时总觉得自己是在从事一份艺术的工作，一个一个程序在自己的手中编写出来，能运行，能给很多人运行。这个过程就像一种固化的思想，能动态地和软件使用者交流。对待程序也像对待艺术品一样神圣，变成时总怀着一颗虔诚的心。
后来又走向另一个极端，觉得自己的工作无非和砖瓦匠一样，按照图纸，把一砖一瓦安置在正确的地方
在后来才知道，编写软件既不是艺术，又不是完全是工程，而永远都走在由工程到艺术的途中。借孔夫子的话，软件开发应该走中庸之道。

所谓中庸，就是作对的事情，不走极端。
假设工程是0，艺术是1，那中庸是多少？
0.5?不对！绝对的中点显然不是中庸。中庸可能是平均分布在[0,1]区间上，或者是[0，1]上的某个概率分布，不过这些对实际工程都已经没有任何意义。
换个假设，如果工程是0，艺术是无穷大，中庸是多少？
呵呵，有点无聊了。