我对软件架构设计的认识(一)

最近一直致力于引擎的架构设计,到目前为止一个多月没有写一行代码。半个多月前我的计划是这样的:留出足够的设计时间,例如3个月,然后开始集中开发。在这种思想指导下,整个引擎的开发计划也是如此定制的。现在几乎每天都在更改前一天的设计,每天的工作都在构思-〉推翻-〉重构-〉思考-〉验证的过程中,不停的否定-〉肯定,自己跟自己打架,很希望能有人跟我一起讨论。虽然很寂寞,不过也自得其乐。一个多月的设计让我感觉有必要重新审视自己的思路,所以今天把自己对软件架构设计的认识写下来,也许以后回顾的话能得到一些参考罢。
什么是好的设计?怎么样才能做好一个设计?这是我这几年一直疑惑的问题。首先要明确一点,设计的目的是什么?我的回答是:设计是为了编码提供开发依据,为了在将来的的软件的维护过程中提供依据,为了让整个开发团队能充分理解软件的体系结构提供依据。其实设计还可以有很多目的,例如为了骗取项目投资人的信任,为了满足 Boss 的对你的满意程度,为了能在年终考核里加入更有分量的砝码等等。总之,设计的目的分为两大部分,1.真正满足整个软件生命周期的需要,2.满足除了软件需要以外的需求。很可惜,自从搞软件开发以来,我写的设计大部分属于后一种,反而是我自己的项目里的设计倒是第一种,但是很少。不过我想这是普遍的现象,造成这种情况的原因有几个:1.开发周期短,这势必会导致开发人员在设计上花的时间不够,时间不够意味着不可能出现好的设计,这是绝大多数的情况。2.Boss 认识不足:这是要命的,如果你的 Boss 认识不到设计的重要性,甚至不懂软件开发,劝你赶快跳槽吧。3.自身认识不够:很多程序员知道要做设计,但不知道如何下手,不过这种情况现在好了许多,毕竟这类的书籍到处都是,UML\敏捷\XP\AOP\OOP….等等众多的开发方法让人感到头晕目眩。但仍然有很多人不知道该怎样设计,做好设计,这个话题下面会展开论述。讲了这么一大堆,到底应该怎样才能做好设计呢?
讨论任何问题,都要有一个假定的前提,所以在这里我也要假定一下:假设你的 Boss 认识设计的重要性,假设你有一定的设计时间,假设你有设计的经验。当接收到一个项目,首先重要的一点是要分析,当然系统分析不在这个讨论的范畴,不过我认为在现实开发过程中设计其实是包含一部分系统分析的工作的。如果按照传统的瀑布型软件开发模式,软件的生命周期是这样的:分析-〉设计〉编码-〉测试-〉维护,随着软件系统的日益复杂,这种模式暴露了很多问题:1.这种顺序化的开发过程是在一个对整个软件系统有充分认识和了解的前提下的,而要对一个复杂的软件系统有充分的了解(包括实现细节),这个本身就是一个完整的实现过程,从这点来说,是矛盾的。2.在复杂软件结构下,如果有能做到这种程度项目开发团队,那一定是有着丰富的开发经验,并经历过无数次的失败的项目,而现实的情况往往是经验较少的项目团队来开发复杂软件系统,而经验丰富的开发团队也是经过失败才从新手达到老鸟的程度的。从这一点来说,也是矛盾的。
话说回分析,分析由谁来做?这是一个大问题,书本上讲分析由系统分析员来做。系统分析员具有什么能力?系统分析员应该是有着丰富经验的开发老手。但现实的情况是分析人员是通过国家系统分析员考试的刚毕业的大学生,是市场人员,是你的 Boss,甚至是项目的需求方人员,他们不具有丰富的开发经验,甚至都不懂软件开发,在这种情况下出来的所谓需求分析报告可想而知了,除了对要做的软件的外观有一个描述之外,对开发没有任何帮助。如果你的项目很不幸出于这种情况下(基本上国内都这样,所以我们都很不幸),而且恰好你是一个很负责任的开发者,那么你的设计中就要包含本应该在需求分析阶段完成的系统分析的工作了。但是,这样你就会非常被动,原因2点:1.项目规定的设计时间对你来说很可能会不够用,因为你要完成额外的分析工作。2.Boss 或者 项目需求方对你的压力,因为他不知道分析的工作没有完成,他们理所应当的认为你现在的工作只是设计。好吧,也许你说“太糟了!能不能完美一些?”,那么好,假设系统分析人员给你一份足够专业的需求分析文档,那么还依然存在问题:1.分析是否能覆盖到所有的需求?2.对于隐含的需求是否分析清楚(这恰恰是最重要的,现实的情况是往往漏掉的一个隐含的需求会导致整个结构的变化)?3.是否做好用户需求到开发需求之间的映射(这是体现功力的地方了)?所以,未来的路还很长。
 话再说回设计,正是因为以上的种种原因,我已经有很长时间习惯了没有需求分析的设计了,我的设计中往往包含了分析的工作,虽然累了些,反而觉得这未尝不是一件好事,至少保持了分析-〉设计的连续性,而且也可以做到分析和设计之间的互动:通过设计来反映分析的缺陷-〉重新分析-〉修改设计,其实这就是一个迭代的过程,同样,在开发中任何两个阶段中都可以这样来互动。实际上迭代式开发模式就是在瀑布是开发基础上加了个循环,可以评估每个阶段的输出结果,并修改上一个阶段的输出结果。其实最早迭代模式的出现,是为了解决在开发过程中需求不断变化的问题,传统的瀑布式开发是假定需求是不会变化的。软件的复杂性会导致不可能有某一个人掌握或者在短时间内的就能分析透彻的,更何况还不断的修改需求。而在这里,我倒是觉得经验少的团队很适合迭代开发,或者说很适合一个你不太熟悉的复杂系统。
Advertisements
此条目发表在DreamEngine开发手札分类目录。将固定链接加入收藏夹。

发表评论

Fill in your details below or click an icon to log in:

WordPress.com 徽标

You are commenting using your WordPress.com account. Log Out /  更改 )

Google+ photo

You are commenting using your Google+ account. Log Out /  更改 )

Twitter picture

You are commenting using your Twitter account. Log Out /  更改 )

Facebook photo

You are commenting using your Facebook account. Log Out /  更改 )

Connecting to %s