谈谈软件开发的那些事儿 之 软件开发的轮回

——对软件分析设计的一次深刻反思与探讨

 

前言：你干软件开发多少年了？你是否开始感到困惑了、累了、算了？你是否该找一个加州旅馆好好歇一歇脚了？这篇文章也许就是你的加州旅馆，它给你解惑，反思软件开发中出现的问题，探讨解决这些问题的办法，那就是建立模型——用例模型、领域模型、分析模型和设计模型。

 

谈起软件开发，我在10年前就开始了。那时天是蓝的，生活是美好的，程序设计也是轻松愉快的。如果当时有人告诉我，设计一个程序需要数十人、花数年的时间完成，我会张着大大的嘴盯上你足足十分钟。那时，设计一个应用系统实在太简单了，我和我老师，还有另一个同学，仨人花两、三个月就可以搞定一个系统。我们不必考虑什么中间件，什么技术架构，什么通用性。跟着老师去客户那里谈一下午的需求，画一堆ER图，然后用Power Designer工具生成数据库，就开始用Power Builder设计程序。设计程序也是相当简单，一个下午就可以设计出一堆数据窗口，一个人几天就可以设计出一个模块。那时的项目相当清楚，就是针对某个单位的某个部门，或是某个具体的业务。不用考虑通用性，设计好了很少需要变更，大不了又重做一套完事。

 

但后来事情就开始变化了，软件应用的范围越来越广了，起初是一个企业，然后是多个企业，后来是整个集团、整个系统，甚至整个行业。技术也在越来越复杂了，从C/S到B/S，各种框架和技术路线，各种产品的整合。随着软件发展的一步步深入，软件规模在日渐扩大，软件设计变得越来越困难。

 

我个人经历了无数项目，也看着别人做了无数个项目。虽然每个项目都各有不同，但整个过程却千篇一律，都是俩字：崩溃！几乎每个项目的开始都是美好的，项目负责人总要召集大家坐在一起召开一个讨论会，总结过去的经验教训，展望未来的美好前景。几乎每个讨论会大家都唾沫横飞，列举过去的种种不是，提出各种各样完美方案，所有人都群情激昂，感觉自己从此进入了某个崭新时代。随后各人就回到各自的座位开始废寝忘食地工作，小心谨慎地按照事先规定好的规约执行。数月过去了，一切进行得井然有序，曾经出现的问题没有再次出现，所有人都暗自庆幸。也许，终于可以经历一次完美的开发过程了。

 

随后的事情就发生了，用户急匆匆地跑过来说，程序的设计不如他所愿。OK，程序员不得不在自己完美的代码上进行修改，然而软件交付的日子又要如期将至了。怎么办？程序员顾不得过去的约定开始随意地修改代码了，功能实现了，但是一些糟糕的设计开始了。很多的变更已经改变了原来的设计了，哎，不管了，原有的设计文档也被撂到一边。软件如期完成后，开始测试了。不久，测试员邪恶地将一堆问题报告摆到了程序员面前。为了完成任务，另一堆糟糕的代码出现了。也许某个程序员会自言自语地对自己说，如果当初这样设计就好了，但重构代码得花上一晚的时间，算了，将就对出着吧。

 

再后来，软件交付客户了。正如那句经典的话描述的：I changed when I saw it（当我看到软件时，需求就开始变更了）。当我们的软件经历了客户数轮的变更，一切都变得面目全非。这种变更才是真正对软件设计的终极考验，但非常遗憾的是，至今还没有一个我参与的软件系统经历住了这样的考验。

 

有一次，客户需要修改一个业务逻辑，非常清晰的业务需求，非常明了的一次业务变更。但是我们真正开始着手修改的时候才发现非常困难，因为无数人在各自的模块实现了这个业务逻辑，也就是说这个业务逻辑被分散在了无数的代码中，这样一个业务逻辑的修改就意味着所有这些代码都必须进行相应地修改。崩溃啊，我们又猛地扎进了无尽的加班中。也许你会问，当初为什么不实现一个通用方法供所有人调用？是啊，我也想问这样的问题，但这样的情况还在继续，类似事件依然在延续。

 

就这样将就着，我们在痛苦中维护了一个又一个的系统，两三年、五六年，没有任何乐趣。随着时间的推移，维护系统的人员也在发生着变化，当新来的人员重新翻看过去那些设计资料时，不是残缺不全就是因为历次的变更而今非昔比，他不能从中获得有用信息。即使询问当事人也是记忆残缺不全，也许读取代码才是真正的人间正道，令人崩溃啊。人们只有通过大声地吵架来宣泄心中的郁闷。终于有一天，我们的客户慷慨地说，好吧，我们重新设计一套系统吧。OK，一切都解脱了，我们又开始了另一个轮回。 （续）

 

 

 

相关文章：

 

 

 

《 谈谈软件开发的那些事儿 之 解决之道 》

《 谈谈用例模型的那些事儿 之 用例图 》

《 谈谈用例模型的那些事儿 之 用例说明 》

《 谈谈用例模型的那些事儿 之 注意什么 》

《 谈谈领域模型的那些事儿 之 从领域获取知识 》

《 谈谈领域模型的那些事儿 之 注意什么 》