设计文档?

做软件以来,这个话题一直是自己很郁闷的一个地方,我们来看看软件开发的过程,软件开发的过程无论是采用传统的瀑布、如今的迭代等方式都是一个需求-->设计-->实现的过程,在这整个过程当中,每个环节都要有个完成的标识,并且需要成为下一环节的前置条件、参考依据,这个时候通常的做法都是通过提供文档的方式,但是在我所经历的开发当中,我最郁闷的也是这点,需求这部我没什么疑问,我觉得产生需求文档是必须的,但其实就我所经历的开发来看,我认为需求文档对于用例最好不是仅仅依赖于描述,描述是没人会仔细去看的,而最好是UI原型图,这样对于用例的表达会清晰些,当然,有些复杂的部分仍然需要通过描述的方式。
来看设计部分,在这个部分我一直就觉得有些疑问,一直以来都不是很认同在设计的输出就是要提供一份详细、规范的设计文档,在我看来,设计确实是进行实现的前提条件,这毫无疑问,但真的就一定要通过一份详细的设计文档来做到这点吗?我觉得设计中最重要的设计理念的表达,而对于设计理念我觉得最佳的表达方式仍然是图形,而这个图形一定要采用规范的象UML这些来表示吗?我并不是那么的认同,我觉得设计图最重要的就是要表现出自己的意思,至于你用什么图形来表示我不觉得有什么重要,只要设计人员认为那是他最擅长表达自己设计意图的工具就行,没必要在工具这件事上浪费设计人员太多的时间,并且造成了限制,设计的评审我觉得是有必要做的,这时我觉得大家可能会问,没有文档怎么办,怎么评审?我觉得评审的人是为了让同行的设计人员能够根据目前设计人员对图形的一个解释来准备的了解设计人员的设计意图,并且根据自己的经验相应的给设计人员一些建议;其次,从简单设计角度上来讲,我觉得设计是一个不断充实和完善的过程,设计是一个典型的求解过程,就象一道数学题,通常来说,也许会有N中解法,每个不同程度的人看到的解法也许是不一样的,但首先能解出来这就是一个成功,其次才是看这个解法有什么可以改进的地方,我现在做设计的时候就是首先采用自己目前能想到的最简单的解决方案,在做同行评审的时候也许有些同行能给出些建议,如果没有的话,通常来说我会先按照这个简单的解决方案先做,在实现后其实就会发现目前这个实现方案的一些问题,即使当时没发现,在添加新功能的时候也会发现,这个时候依赖重构开始进行调整,其实我觉得只有这样一个设计才能慢慢的被完善、被诞生,应该说,不同程度的设计师的区别就在于设计出来的东西所被完善时投入的精力和造成的影响,我相信没有哪个设计出来就是那么好的,在这种情况下,通常就会出现一个问题,就是最后实现形成的设计和最初的设计有很多的不同,这个时候是不是意味着在开发的过程中应该一直去更新、维护设计文档呢?所以我觉得最初的设计文档不需要为了规范投入那么大的精力, 但不意味着不要,需要的是一份能够表达设计意图的文档,最重要的是图形化的表达,大家认为呢?或者说大家都是怎么做的呢?还有就是这种时候正规的设计文档什么时候出呢?^_^,缺少文档时有的一个问题是怎么样将设计意图准确的表达给开发人员,这部的做法在XP中通常不存在,因为XP中设计是大家一起做的,在传统的情况下我觉得更多的是依赖设计人员和开发人员的频繁交流以及对于代码的code review。
但缺少设计文档在公司的运作中通常会出现一个问题,就是领导们的不放心,领导们会觉得怎么经过了这个阶段没啥正式的产物,领导们会认为设计图这些是不足以证明这个阶段的完善的,郁闷,造成总是和领导形成矛盾,这也怪自己在安排任务时通常缺少这个正规的设计文档的编写过程,这个过程真的有这么必要吗?疑问中......

ps:顺便说下现在自己从设计到实现的一个步骤,在设计时首先我会根据目前的需求得出问题域,这个时候开始进行设计,对问题域进行求解,这个时候会给一个自己能想到的最简单的解决方案,注意,既然是解决方案就以为着首先要能解决问题,简单的解决方案不等于简陋的解决方案,在提供这个解决方案后开发人员实现后我会对code进行review,而这个时候review经常会发现设计中值得改善的地方,这个时候开始对设计进行重构,详细设计一般要在迭代完成时才能最终形成.....觉得这样的方法挺好的,^_^,自己在做实现的时候现在的做法都是先把测试代码写完后,写设计的时候会先随意的写,写完在通过测试后开始对代码进行重构,这个时候开始把之初的长方法首先进行重构为小方法,重构完后开始做封装的考虑,形成对象模型,在对象模型形成后开始考虑继承、多态的引入,最后开始考虑设计模式的引入,一般这个时候最终的详细设计才得以形成,我觉得这个时候是体现一个设计师水平的时候,一个优秀的设计师在设计之初就能想到很多,预见的很远,使得设计在设计之初就能足够的完善,而不需要通过太多的重构形成最终的设计,而一个普通的设计师也许最初只是能给出一个解决方案,但毕竟是可行的解决方案,在设计实现的过程时才逐渐的发现设计的不足,这个时候通过重构进行的完善,对设计师来讲也是一种很好的积累,所以来说,在完成设计后最好是能多找人交流交流,^_^,喜欢这个方法.......

posted on 2006-01-06 21:19 BlueDavy 阅读(3124) 评论(4)  编辑  收藏 所属分类: 系统设计

评论

# re: 设计文档? 2006-01-07 12:26 wzr

何时创建设计文档最好?是在整个团队结束项目时,这是最后一项工作。这样的文档能够精确地反映出团队离开时的实际设计情况,而且这样的文档对新来的团队大有帮助。

——这是Robert C. Martin(即Bob大叔)在UML For Java Programmers书中所写的。

向领导们宣传XP思想,也是设计人员的一项重要工作。XP最讲究沟通,领导们也是沟通的对象。
第一步:有事没事,向领导们介绍一些软件工程方面的专家,当然要挑选支持XP方法的“大佬们”。
第二步:等领导们熟知这些专家的大名,就可以用他们的“语录”帮教领导了。比如,上面的那一句。  回复  更多评论   

# re: 设计文档? 2006-01-07 20:04 brokendoor

奇迹不是一夜之间就凭空而来的,外星人也不行。
对于设计文档,不可不写,因为“千里之行,始于足下”。
更不可写完就完了,因为这可是“千里之行”啊!
即使是开宝马,也不是一下就到的了的,中途总要加点油什么的.......:)  回复  更多评论   

# re: 设计文档? 2006-01-08 01:16 nake

写的不错,“而这个图形一定要采用规范的象UML这些来表示吗?”
如果你的团队没人会uml你就不用uml,一支笔一张纸就可以了。大的软件我觉得还是要把许多过程规范起来。简单的就没必要了,比较规范是要成本的。  回复  更多评论   

# re: 设计文档? 2006-01-09 09:23 走过看看

Bob大叔的实战水平太差,基本上写些demo程序都会出问题。他的那本“敏捷软件开发”是这类书里面代码逻辑错误最多的,真不知道是怎么混出道的。可能比较善于动嘴皮子或写书?
他说的话听听就行,不必当真。  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
博客园   IT新闻   Chat2DB   C++博客   博问  
 

公告

 









feedsky
抓虾
google reader
鲜果

导航

<2006年1月>
25262728293031
1234567
891011121314
15161718192021
22232425262728
2930311234

统计

随笔分类

随笔档案

文章档案

Blogger's

搜索

最新评论

阅读排行榜

评论排行榜