别人的棺材 荣耀 2002冬 一个大的软件系统通常包括若干子模块。通常来说，良好的设计具有这样一些特点：
现在有A、B、C...等几个模块，B模块（但不限于B模块）负责生成指令，A模块负责执行指令，两个模块对指令的格式定义了规约。 B模块生成的指令，可能在格式上就是不正确的，也可能格式正确但内容非法，比方说，指令里的某个参数不得超过某个值，否则A若照搬执行，即会造成严重后果。很显然，A模块必须具有严谨的逻辑分析例程，要考虑所有边界条件和异常情况。 现在有人提出一种“更保险的”设计方案：B模块也要实现同样的指令逻辑分析例程。乍一看，似乎颇有些道理，实际上……，唔，你说呢？ 道理其实很简单。假如现在C、D、E...等模块（以及其他第三方模块）都要向A模块发送指令呢？更有甚者，假如指令分析的业务规则发生了变动呢？你希望只修改一处逻辑分析例程，还是修改好多处？还有，你认为同样的一个例程运行10遍比运行一遍结果会“更正确”吗？ 类似地，还有一些不属于技术认识缺陷的例子。 在一个开发团队中，本来是甲的任务，却被乙做掉了，或者甲已经开发过的好端端的模块，乙也要写一个功能类似的“更好的”模块。 不管是乙的自作多情，还是某人打着“团队协作”幌子的无端指派，造成的后果都可能会比B模块执行了一个非法指令所导致的后果，严重得多。 那些来源于生活、听起来滑稽的故事常常使我们感到好笑，以至于忘了自己可能就是笑话中的丑角，或许有些话非得说到极端才能振聋发聩。 “把别人家的棺材抬回自己家哭”，说的就是这个道理。 －完－ |
 |