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