单向依赖，如果发现你必须调用另一个类，另一个类也需要调用这个类，就以一个类为主，另一个类开放事件。这也许就是控制反转，AOP的需求吧（我并没有深入研究AOP，我只记得控制反转这个词，好像是为了解决相互依赖关系问题）。“Don't call us, we'll call you”。

    但是代码稳定xìng的问题仍然没有很好解决，测试组也找出了许多BUG，但是一到客户那里运行，还是出了不少BUG。怎么自己运行的时候找不到呢？

    于是，我们在版本测试的时候、第一个版本小规模放给典型客户的时候，都加了断言。一旦软件出现问题，就立即记录日志，并进行软件中断，而不让错误继续错乱的不按我们预想的代码流程走下去。很多年前，我就惊讶于某公司的软件的质量，怎么折腾cāo作都没有问题，我常常给我的手下拿这个例子来反衬大家的代码质量。直到我有时随便乱点，居然软件中断退出了，报了一个错误号，我一下子想通了，它用了断言。断言阻止了错误的继续扩散，不让恶果之鞭长袖善舞。于是，我要求开发人员经常xìng使用断言，很多过去悄然发生的错误，测试员只运行可执行程序无法捕捉到，现在都能明确的捕捉到，在测试阶段就尽可能的消灭了那些过去无法明示的BUG。

    我过去领导过架构组。架构组的人在2002年的时候，疯狂迷上了UML和设计模式，人手一本《COM本质论》和《设计模式》。我手下有一个新手，就处处是类，处处是抽象，处处是封装，处处是分离，尽量使代码高内聚低耦合。但是这样的的代码太麻烦，他花费了大量的时间，他看自己的代码赏心悦目，别人看他的代码云里雾里，不阅读懂《设计模式》就按照常规理解业务的思路去阅读他的代码根本阅读不懂，不知道他为什么这样写代码，怪异的很。本来，这位想达到可维护xìng，可阅读xìng，却真正的失去了可维护xìng、可阅读xìng。这和我前几天看我的朋友周爱民写的《大道至简》中写到：有人希望拿UML去统一用户和软件设计者。殊不知UML有多难理解，而UML设计者却认为UML可以描述一切。就这个道理，要理解你的代码还要去读懂《设计模式》，这要求太高了吧。

    所幸这位新手自己都每次写的累，慢慢的也就懒了，觉得确实需要分离的时候就分离，觉得没什么必要的就懒得做了。用他自嘲的话说就是：被磨平了。其实，依我看，他现在这个代码状态才是刚刚好，即照顾了设计扩展，又照顾了实用。真正的纯OO，纯设计模式，可能只存在于教学和科学，而不在于我们的商业软件开发。我们作为商业开发，强调的是叫座的基础上叫好，所以折中方案是必须的，客户和我们自己两相宜就OK，是否符合正宗，就不在我们的商业开发管理范畴了。

    这位新手还写了大量的注释。在每个源代码文件头都写上几月几号，XX创建的，这个原代码文件主要是干什么的，还画蛇添足的写上版权所有，公司名称。好像这个代码要开源，或者可能会被其他公司窃取了好表明公司版权。甚至每个函数都写了注释，每个参数是什么意思，每个参数可能出现的值代表什么意思，都写的一清二楚。久而久之，也懒的维护了。代码改动了，参数扩展了，参数状态值有了变化，注释说明却没有跟着改动，让后来看代码的人老误解，还不如不写这些注释。

    我告诉他：做事不能走极端。要么全写注释，要么不写注释，都是不对的。我只在我认为要小心的地方，或者我自己都觉得很难理解懂的地方我才写注释。否则，我自己都可能会过段时间理解错了。如果某段代码我看看就能看懂，我就不写注释了。咱们做企业管理软件，深入技术又没有，只要代码能把复杂的业务处理描述的逻辑思路清晰就OK