浅谈软件开发中设计的重要性以及错误设计的避免和修正



"If you are failing to plan, you are planning to fail."

—Unknown



前不久的《程序员》还专门为黄柳青先生开辟来谈“面向构件的开发”。颇有感触，觉得一个好的软件设计会让开发组省力、让公司省钱、用户省心。事实上，作为公司其市场受益度还远远比这个大，而开发组成员则能在这个开发过程中学习好多的开发经验。当然，好的软件设计肯定不是一个项目的成功全部保证，但是绝对是最关键的保证之一。

人们对“软件设计”的重要性已经有太多的强调，但是我认为无论再怎么强调也不过分，因为一个好的软件设计至少会提高软件的质量、节约开发成本。创建一个软件系统与其它需要耗费人力与财力的工程是一样的。如果你要造一幢房子，在开始砌第一块砖之前，你必须事先画好建筑图与蓝图。在你开始浇铸水泥之前，你必须让人评审你的蓝图并获得通过，在软件开发中事先做计划也与此类似。当然，你也可以反驳我说Linux 系统的实现在事先就没有详细的设计说明，是的，但是没有文字说明并不意味着就没有设计，相反每一个Linux模块的细节在Linus.Torvalds动手编写代码之前在他的大脑中已经非常清楚了，当然，你也可以不用文字说明你的设计——除非你有Linus.Torvalds那样的大脑。那么，“好”的软件设计有没有标准呢？John Erik Hansen and Carsten Thomsen 在他们的《Enterprise Development with Visual Studio .NET, UML, and MSF》中简单的给出以下几点参考：1.使解决方案符合用途 (Makes the solution usable)， 2. 达到目标用户的期望(Fullfills the expectations of the target audience) 。3.不易出错(Isn’t error-prone)。作为商业观点，他们又给出了两条，4.提供利益 (Provides benefits). 5.有用(Is useful)。使解决方案符合用途，这是一个最基本的前提，如果解决方案旨在节省用户管理日程的时间(如电子日历系统)，则必须保证易用性。若解决方案使日程管理任务更难，或更慢(还不如普通纸张日历来得快)，则说明满足不了使用标准，不是一个“好”的设计。达到目标用户的期望，这一点非常关键，也就你在设计软件的时候要考虑到目标用户教育背景，计算机技能以及年龄等问题，你总不能以英文界面给那些没有受过教育或教育程比较低而母语不是英语的用户群吧！软件不易出错也非常重要，如果用户在使用你的软件时老是出现一些让他们摸不着头脑的错误，那么用户在情感上就会拒绝使用的你的软件，而你的信誉度必将及实际利益必然受损，再说，就如写书的人最怕自己的书前脚摆上书店，后脚就被当废纸拉回印刷厂，做软件其实也一样，如果用拒绝使用的软件或者对你的软件有较多的抱怨，对你来说也是一种自信心的打击。

让我们来分析一下，“坏”的软件设计会给你带来什么不好之处。首先，影响士气，事实上一个开发团队就是一个战斗的队伍，而一个系统架构师就是这场战争中将军，一个将军要是在战斗中使用某个错误的决策，势必败北。软件开发与此类似，一个“坏”的设计将会延缓开发速度，导致开发最后超期，打击士气并产生恶性循环，让你的软件遭遇失败。“夫战，勇气也，一鼓作气，再而衰，三而竭(《左传.曹刿轮战》)”的道理在这里同样适用。其二、资金损失，如果不改正错误设计，而是按时交付产品，则不可避免地损失资金。如果开发的方案供内部使用，则公司无法使用该方案，得不到投资回报，从而蒙受损失。如果解决方案供外部使用，则销售情况一定难尽如人意，用户也会要求更正错误，当然也会带来成本的攀升。第三、时间，错误设计还会引发时间成本。在需要改正错误或撤消设计和开发时，时间成本将凸现出来。另外，项目团队士气受到打击也会减缓开发速度，造成时间延迟。第四、名声，技术软件开发人员可逐渐习惯于不完美和失败，而业务客户却不是总能忍耐。如果不更正错误设计，则公司的名誉必定受到影响，项目团队也可能被牵连。如果明知设计有误，却坚持交付解决方案，则一定将背上质量低劣的名声。坏名声很难去除，会影响未来销售和内部士气。

是的，所有的这一切表明一个“坏”的软件设计是多么的可怕的事，然而事实上，在真正的设计开发中不可能没有设计上的错误，除非正如Steve McConnell在的《Code Complete》中所指出的那样——有着“稳定的需求”，软件开发工作可能从结构设计，到详细设计，到编码，都平稳、顺利的进行。这简直是造就了软件开发的天堂，你可以预测开支，不必担心最终会冒出一个让你多花 100 倍钱的错误来，然而那不过是一个神话。现在，问题的关键是我们怎么样去尽量避免和修正这些设计错误。首先，充分的理解和把握你的需求，原因很简单，因为实践证明，良好的需求是正确软件设计的前提，换句话说，如果你连需求都不理解，那你设计软件的依据是什么？是你头脑中从教科书上看来的几个概念？还是想当然、凭感觉？据IBM、GTE、TRW 的一个调查显示修正在总体结构阶段发现的需求错误，将比当时就发现并 修正的成本要高出 5 倍，如果是在编码阶段，要高出 10 倍，在单元或系统测试阶段，高 20 倍， 在验收测试阶段，高 50 倍，而在维护阶段，竟要比原来高出多达 100 倍！在较小规模的计划中，在维护阶段修正错误的放大因子可能是 20 而不是 100，因为这时管理费用较低。但无论如何，没有人愿意从自己的收益中拿出这笔钱来。其次，建立一套更改控制过程来应对用户的典型的变动(还是和需求有关，根据 IBM 的调查，对于一个典型的有一百万字的需求分析，大约 25%的内容在开发过程中要进行变动)，也就是说建立一个用户变更审查委员会，用户变更需求，意识到自己的需要功能更加强大、更加全面的软件是一种正常的行为，但是过于频繁的变更而导致开发跟不上他们的进度，则有点不正常了，这时，你可以让用户将变更提交给委员会，然后让委员会去决定是否接受变更并和用户去沟通和交流，这样将使大家都会感到宽慰。顾客感到宽慰是因为有专门机构处理他们的意见，会使他们感到自己倍受重视，你感到宽慰是因为现在你只在特定的时候处理变动问题并修正你的设计。第三，合理划分自己的系统，合理划分就是指将自己的系统分为多个模块，比如在当前C/S应用开发中比较流行的3 层结构在大模块划分就比较清晰(见图1)，这样你在数据层就专注于数据操作，也便于对外部提供统一的接口，功能层就专注于业务逻辑，而表示层就专层相当于应用的本体,它是将具体 <!--[if !vml]--><!--[endif]-->

(图1)

注于与用户的接口。当然，模块下面又分子模块，也就是说模块得到合理的划分以后，尽量产用组件开发，这样你的系统设计就有了一个可容错能力，在应对变更的时候就不至于那么“茫然”，那么“不知所措”或者“牵一发而动全局”了。第四，设计者自身的素质以及设计经验，这一点非常关键，优秀的设计者不仅能精确的把握需求，而丰富的设计经验能让设计者在初期就考虑到诸多不利的因素，为后期设计变更提供良好的应变对策。第五，理想与现实的平衡，我认为一个具有高度理想主义者是不太适合做软件设计(当然天才除外)，因为大部分应用软件的设计是基于“平台”之上，而任何一个平台本身均存在一定先天不足，只有了解和承认了这些不足，我们才能在此之上设计出性能较为良好的产品。我一个做软件的朋友给我说了一个他的切身体会——有一次他为一家大型电力公司设计系统，由于他自己过分专注于系统的完美架构，而他未能在系统和性能之间取得一个良好的权衡和折衷，结果，交付用户以后大数据量的查询时系统直接把服务当掉，最后，客户忍受不了，他也忍受不了，不得不重新修改自己的设计，不必说付出那令人吐血的成本，而且还身背恶名，让公司蒙受潜在的市场损失。

今天，软件市场瞬息万变，市场在扩大的以及生存环境的更加缩小让每一个软件设计者不得不认真的思考怎样才能应对用户有时近乎无理的要求，这时，一个“足够好”的软件设计会让我们能比竞争对手更快速、更低成本地提供给用户功能更全、性能更好、更加稳定和易用的产品，帮助公司开拓巩固和拓展现有业务范围，挖掘更具潜力的市场。



参考资料：《Enterprise Development with Visual Studio .NET, UML, and MSF》，

John Erik Hansen and Carsten Thomsen

《Code Complete》，Steve McConnell

《程序员》杂志