什么样的设计才是有效的设计？

mis98ZB 2003-06-12 09:34:08

最近碰到一个很让人头疼的问题：
在做外包的时候，拿到手的详细设计言之无物，对编码一点指导作用都没有！！

详细设计堆积如山，却又空无一物。而且与概要设计严重脱节。
@_@

比如说一个数据库更新操作，只是写“根据XXXX的条件，更新数据”。然后给出一堆SQL语句。
按照这个详细设计进行编码，然后测试，才发现他给的SQL有问题。
然而我们无法得知每个SQL语句的确切目的，所以无法修改，与客户陷入了质问与指摘的email泥潭里。
T_T

现在才明白这种越俎代庖的详细设计其实是可怕的糖衣炮弹，抓不住重点的设计实在是不能称为有效的设计。

那么，什么样的设计才是有效的设计呢？
请大家不吝赐教！

...全文

152 71 打赏收藏转发到动态举报

写回复

用AI写文章

71 条回复

切换为时间正序

请发表友善的回复…

发表回复

shizi_mhy 2003-08-16

打赏
举报

mark

猛禽 2003-08-15

打赏
举报

设计？很难

即使是再怎么努力，也不可能设计出未来不会被改变的接口，与其如此，还不如重构。

wuhanfengchao 2003-08-15

打赏
举报

关注中···

alasss 2003-08-15

打赏
举报

拜读了楼上的帖子，总感觉大家是把设计和编码分开由不同的人员来做的？如果设计人员不接触编码，他怎么知道如何设计是适合编码的？如果编码人员不参与设计，他怎么知道自己编码的究竟是什么东西？反正我们这里是工程师自己进行各自模块的详细设计和编码的，当然详细设计是需要大家评估审核的。

一个比较规范的流程应该是这样的：

需求分析：由专门的需求人员对市场用户需求进行分析整理，变成可以理解的内容，建立需求文档。

产品规格说明书：由需求人员，我们这里是产品部，和研发工程师，测试工程师，技术支持工程师共同对成文的需求文档进行讨论分析，将每个需求变成具体的功能或性能描述。即通过产品规格说明书就可以知道将来编码做出来的是个什么东西了，长什么样，怎么用等等。通过这份文档，产品工作就由需求人员手中正式转交到研发人员手中了，交接完成。以后除非特殊情况，各方不得在对产品进行任何的更改，如果需要更改，必须通过变更流程确定，并加入规格文档中。

概要设计/详细设计：规格确定无误了，研发工程师就开始进行具体的概要设计和详细设计，在概要设计完成后，还要对其他相关部门，即参与产品规格说明书制定的部门进行概要设计讲解和说明，如果发现有架构问题或者可能影响到产品实现的问题，还需要更改概要设计。
当没问题的时候，研发工程师再进行详细设计，编码。一般这个都是同时进行的，没有所谓的专门从事详细设计而不编码的人员。

然后就是测试什么的了，就不多说了。

产品的约束应该是通过规格说明书进行的，说明书并不详细到编码层，只是确定0层数据流图，实现后的效果，至于具体怎么实现，除非涉及到重大系统问题，如架构等。一般说明书并不作规定，这样便于研发工程师发挥。

如果说将详细设计和编码分开，由不同的人做，那我觉得很难保证产品的质量。人和人的想法总有不同，这样沟通起来的成本太高了！

13060939425 2003-08-14

打赏
举报

我认为,比如写逻辑简单的网站, 设计文档越简单越好;

写硬件通信之类的C通信,感觉他们都设计得好细的

temporary 2003-08-13

打赏
举报

TO stonespace(stonespace):
我觉得你的想法很有意思，可不可以留个通信方式，相互交流一下？：）
我的邮箱between0n1@eyou.com

yzb1000 2003-08-11

打赏
举报

ｍａｒｋ

flflflfl 2003-08-07

打赏
举报

-----

13060939425 2003-08-05

打赏
举报

!!!!!!!!!!!!!!!!!!!!!!1
"首先要符合需求，再就是对编码实现有指导作用的设计才能算有效，比如对接口定义详细正确，对方法内部流程设计准确。"
!!!!!!!!!!!!!!!!!!!!!!

设计的时候还要管方法内部的流程吗?

yunhi 2003-08-05

打赏
举报

collection

gmc007 2003-08-04

打赏
举报

mark

johnson_sun 2003-07-31

打赏
举报

一般说来编码是完成某个项目的最后一道工序，很多人对这不以为然，认为测试才是。但我个人认为，测试工作应该在规划阶段，即分析完成后就已经开始，至于编码后的测试纯粹是为了测试编码的牢固度。我们在做分析的时候就已经大致上决定了项目的目标，当然也有的时候会碰到客户中途要求更改功能的事情发生。一般说来，我们在接到项目或发出外包工作的时候都要求对某一模块的功能有一个明确的设计目的，而且在设计中我们只用伪码，不会去用详细的某种编码语言。这样就给编码人员留出足够的自主发挥空间，我们只要求编码人员完成给定的要求，而不要求他们去用某种专业知识去思考该项目的实际用途。目前的情况是很多做设计的人员原来是从编码出身的，应此在设计过程中会冷不丁加进一段按照他自己的思路的详细描述代码，这样就造成了编码人员的困难。对于这种问题建议闲置该段代码，让编码人员用自己的思考方式去解决。当然能不接这种乱糟糟的设计只怕是最明智的选择。

siemun 2003-07-18