一个失败的系统是怎样产生的：设计不足

    不久前朋友提供了一个系统案例S，粗略地分析了其体系结构，并浏览了大部分代码。从商业的角度来说，S也许是成功的，但是从技术的角度分析，该系统明显存在大量的问题。也就是说，一个成功的产品，却是一个失败的系统。个人认为其具有典型性，可作为设计不足的案例。

 

总体有规划，具体无设计
    不得不说，该系统还是有一定的规划的，至少看起来有个像模像样的架子。但遗憾地是，没有发现总体设计文档。一个陌生人接触该系统的话，可能要琢磨相当一段时间才能有所领悟。当然，该系统也没有详细设计文档。硕果仅存的几篇文档是《数据库设计说明》，并且长时间没有维护，已经和现状相去甚远了。作为有一定规模的系统，这样的状况是不应该的，有必要追究Leader的责任。

 

工具：工欲善其事，未先利其器
    仅有的《数据库设计说明》文档，对表的描述也是用word中的表格，（即使数年前）是不是已经out了呢。保存便于计算机实现的数据库模型应该更值得推荐，花费大量的时间和精力在word中画表格，显然是不明智的选择。对于这个让人失望的系统而言，即使有设计并生成文档，我想也仅仅是冗长的文字最多配两个手绘的图表而已。

 

界面：远看过得去，近看不忍睹
    系统的界面，粗略地瞟一眼还是可以的。一旦具体到页面，尤其区别到不同作者的模块，让人不敢恭维。千差万别谈不上，参差不齐总是有的。可见，开发人员过多地参与了界面开发（可能也算不上），至少过多地和界面打交道，花费了大量的时间和精力，这些都是不必要的成本。如果有良好的界面设计，或者设计者（如果有的话）能够给出方案，实现可配置的界面呈现，系统是不是就显得清爽多了呢？

 

代码：无规矩不成方圆
    编码规则的确定，技术选型的敲定，往往也是在设计阶段完成的。源代码作为某种文档，统一不同开发人员的风格是必须的。该系统存在的问题就是，代码混乱，甚至冗余，注释少得可怜或者不规范。这样的代码谁愿意看呢？我想compiler有自由的话，也不会去编译它。追求新技术是程序员的爱好，而新技术的使用应当有严格的流程。该系统使用了一些不必要的技术和组件，七七八八，使得系统看起来杂乱无章，臃肿不堪。

 

设计不足导致的问题至少包括以下几条：

 

系统实现事倍功半
    由于缺少周密细致地设计，开发人员在编码过程中常常自由发挥，随意挥洒，经常出现这样那样的问题。然后就是询问，确认，返工，再询问，再确认，再返工。当然，有些问题可能得不到确认，这会导致更大的问题。此时开发人员的思维中只有模块，没有系统，遇到模块交互功能的实现，常常无章可循，临时讨论协议，分歧不难发生。这样的开发过程，也许很能锻炼个人的编码能力，实际上是一种糟糕的开发体验。日积月累，终于有一天好容易“搞惦”了，甚至交付了，验收了。令人痛苦的事情也来了。

 

系统脆弱
    系统在部署并投入运营之后，潜在的问题会逐渐暴露，然后就会出现这样那样的错误，甚至走向崩溃。引起该问题的原因往往包括模块的不兼容性，甚至相互冲突。除了当初的开发人员，其它人不能快速定位问题并着手解决。这时，甲乙双方就会意识到这是一个并不健壮的系统，那么接下来该怎么办呢？

 

难以扩展
    如果我们足够幸运，系统上线一段时间后表现良好。无论出于什么原因，客户有意愿提出进一步的需求。然而，除了大动干戈，我们无法在原有的基础上扩展新的功能。实施进一步的需求，可能会有牵一发而动全身的不良反应。即使加入一个普通的模块，也不得不修改其它的代码，而我们就需要花费更多的时间重新确认系统仍然能正常工作。当客户的扩展需求零碎而又个性化十足时，系统维护会成为一场噩梦，并将为此付出昂贵的代价。

 

没有可复用性
    对于设计不足的系统，可复用性将无从谈起。