大家做项目都要写详细设计吗？(100分)

T

tt_mok

Unregistered / Unconfirmed
GUEST, unregistred user!
详细设计真的详细到看着文档就能写出代码的程度吗？这是我们公司的要求，
我对此抱怀疑态度，我不是反对写设计，但对文档的详细程度有不同看法，
我觉得只要把大概的实现流程写写就可以了，若是详细到那个程度，干脆
直接编码算了，何必多此一举呢？而且有些东西是到真正做的时候才知道
难点，有些是临场发挥的，根本很难预料，文档详细到能编码好像不太现实，
各位大侠你们说呢？
 
文档可以详细到能编码的程度，但是我认为软件开发并不是像我们所学的软件
工程里说的那样详细设计完就不用再继续设计了。我在实际工作中发现往往在
交付之前还在设计和编码，原因就是对用户的真正需求并不是很了解（包括用
户在内，他也不了解自己的需求）这样一来，你需要不断的修改你的设计，当
然，系统框架是不会改变的了，否则就是一个失败的设计。修改设计实际上是
一个逐步细化的过程，当系统满足要求了你的设计也就完成了，而且是一个详
细到可以编码的设计。
 
to tesug:
你好，谢谢你的意见，但比如我设计一个窗体，那每个按钮里的事件都要写成文档吗？
如过要，应该以怎样的格式写呢？谢谢
 
你试试UML吧，虽然我对UML还不是很熟悉，但我觉得很适合面向对象系统的设计。
我用UML描述后，基本可以直接生成代码。
 
用伪代码写。
如窗体from1中的一个button1的click事件可以写成如下：
单击button1
开始
结束
 
大侠们，给点意见吧
 
如果要写详细,不如写帮助
 
事实上你觉得你不用写就可以完成代码；原因是东西是你设计的，你想怎么做就怎么做；但是你有没有
想过以后你设计的东西要别人去完成，那么别人看了你的东西能否达到你的设计要求的那样吗？？
详细设计所要达到的就是这个，也就是说在这个人完全不再的时候，随便让一个人都可以来编码
国内很多公司软件成本高就是因为这个原因，一个人从设计到编码到实施，别人无法插手他的工作就是因为
不理解它的意图。。。。。
 
写每个按钮的流程、对数据库哪些表及字段的操作，全写完，你可能会发现原来概要设计、
数据库设计有不合理的地方，这就是对后面写程序最大的好处，同时以后自己看程序时也会
很轻松找到问题所在。
现在我们也在尝试用UML，好不好以后给你答案。
 
这一类的文档是应该要写的，当然一个项目只有你一个人在做，而且你有很好的开发习惯
对自己写的代码的可读性很有信心的话也许文档对你来说不会有太大帮助，可是如果是多
个人开发呢？代码开发随心所欲会出现的问题我想我不用说你自己也会知道。其实详细说
明并不是要求你写得象你说的那么详细，对于事件，例如点击button你只要说明点击button
实现什么功能，或是调用什么操作；对于函数和过程，说明函数过程名，定义好参数，返
回什么样的结果；一些特殊的算法需要给出的是算法说明（当然你的程序员够强这也省了）
反正你的说明书要告诉你的程序员，你会输入什么，你要求输出什么，这是最起码的。
 
多说程序员都没有写文档的习惯，包括我在内，有时真觉得这是件很烦的事。
虽然如此我觉得写文档还是一个很好的习惯，程序作多了或者很多项目之后，
要维护时，就连自己也忘了到底怎么回事。这时候文档的作用才突显出来，
我觉得首先整个系统的框架、流程时一定要写的，其次是各模块、各Unit至少
要把思路写清楚，如果涉及到算法问题更不能少。如果还有精力就可以在每个
函数、过程写上一两句注释即可。我觉得一个程序员能做到以上，已经可以少
很多麻烦了，不管是自己还是别人。
 
做设计的薪水至少是做代码的三倍，你说该不该写详细设计，
不排斥临场发挥，但回过头来还要在规范，否则随意性太大，
 
to 轩辕散光
谢谢你的意见，其实你的意思我懂，这是软件工程中的道理，关键是现在很多公司流程都
很不规范，做设计的是我，写代码的也是我，我的头根本不懂DELPHI，他也不理你的文档
质量如何，只要有个样子就行了，而且详细设计写好了，也不会有个高级一点的人看看，
提点改进的意见，你说，这样的文档有用吗？只是形式主义而已 ：），再说，我又不是
系统分析员，拿我的设计（全是我个人发挥，没经过讨论验证），去拿给别人写程序，这
样现实吗？若你接到了一个详细设计，觉得他有诸多问题，你会按照它来写程序吗？
 
要求是要写，但时间都来不及，项目完成后程序改了乱七八糟，详细设计通常却是从没改动
 
我也曾经经历过这样的事情,设计得不到验证,而且代码还得自己来写,
不过程序一定要走的,这样才能提高,这也是通向系分的路,
一般的老板都不相信刚出校门手里就拿着系分证的应聘者
 
我觉得不管用什么方法、工具都好，关键是有一个详细的逻辑说明文档，有了逻辑好像
写起来就快些。我也想过写一些更详细的文档，不过似乎从来没有这个机会，通常我们
有足够的时间把设计逻辑记下来就很不错了。
一点体验而已。
 
我觉得没有必要。写上每一个procedure要处理什么问题和需要注意的事项就成了呗
如果要那么详细的话，先编程序，再把源程序整个copy给他算了……
 
不同意楼上的，设计是一种通用的、抽象的描述。一个详尽的设计交给编码人员，如果
它懂C语言就可以用C来实现，懂DELPHI就可以用Delphi来实现。而代码不是这样，你把
C的代码交给只懂DELPHI的人，它能够完成同样功能的Delphi代码么？
 
不必太详细的
但总要在关键地方作标记
因为怕到时你自已都看不懂了
 
谢谢各位的意见，还想请问一下各位，那你们公司对详细设计的要求是怎么样的？
愿闻其详
 
您必须登录或注册才可回复。

Similar threads

S
[教程]Delphi Android应用启动画面详解
回复
0
查看
399
swish
S
不
Python 的 Magic Methods 指南(转) - 不得闲
回复
0
查看
684
不得闲
不
S
[教程]使用 TQJsonOutputChannel 写入 JSON 数据到流中
回复
0
查看
672
swish
S
不
Delphi中设置条件断点 - 不得闲
回复
0
查看
658
不得闲
不
不
ISO8583报文协议（转） - 不得闲
回复
0
查看
671
不得闲
不
顶部