如何证明C++项目是不能先详细设计再CODING的

[Alan S1]

如何证明C++项目是不能先详细设计再CODING的?

[amossavez]

你知道你说的这个详细设计细到什么程度？？

[beyond071]

学习了

[sunshine502]

这是CSDN吧？不是MSDN吧？

[Alan S1]

[Quote=引用 52 楼 Meteor_Code 的回复:]
引用 9 楼 zhh157 的回复:
说说我的想法，首先，我觉得软件工程、项目管理和开发过程等式超越语言的。
可能的原因有
1. 需求不确定，或者说不确定的程度超出你的掌控。你无法在一个需求捉摸不定的需求下进行架构设计和详细设计。
2. 对需求的理解不够透彻，在需求没有彻底理解的情况下，贸然进行架构设计、详细设计只会让你得不偿失。
3. 架构设计做的不够好，很简单，大楼的地基已经夯实（有了可控的需求分析），但是，…
[/Quote]
收益匪浅......

[Alan S1]

[Quote=引用 52 楼 Meteor_Code 的回复:]
要在设计之初就考虑到设计的最大冗余,使得之后即使发生修改也会变的容易,在代码开发过程中一定注意分块设计,不同的模块只可以用接口来交互,还有就是软件设计中看见必须是软件需求,而不是原始需求,有无数的人分不清这两个之间的区别,
不要认为"最大冗余"会给设计带来麻烦,因为代码可以重用,任何一个企业做的产品都是类似的,一个项目结束之后,另一个项目还可以使用这些代码,如果一个设计小组初期的代码做的就不伦不类,即没有冗余性,也没有移植性,这个小组就解散吧,因为任何一个软件企业,他要的不是成品的软件,而是软件后面的有效代码.只能作出软件的小组和连软件都做不出的小组没有任何区别,因为企业要的是高效代码,而不是一个EXE.还有就是个人问题,一定要注意自己的事情就应该自己完成,不要把应该在自己的代码里完成的东西转交给别的模块,任何一个模块都要做到独立性. …
[/Quote]
收益匪浅......

[song_0521]

学学软件工程就知道了

[Alan S1]

up

[leogle_reloaded]

[Quote=引用 37 楼 steedhorse 的回复:]
不管什么方法，目标都应该是在有限的时间内，为客户“全部完成”尽量多的最有价值的软件特性。
[/Quote]

客户选择某家软件公司开发其项目，会参考该公司的生产能力和用户满意度，生产能力包括开发效率，千行bug率，产品质量等，用户满意度就比较广泛，前期调查，bug发生率，维护等等。而文档是体现软件公司生产能力的直接依据。如果忽略某项开发过程或跳过详细设计工程却生成详细设计文档，那么公司呈现出来的生产性必然是一个虚假的状态。他无法保证软件的质量与他所说的一致。

[theone11]

楼主没有听说过外包么……外包就是先有文档再写代码的吧,基本也就是把文档逐句转换成代码

实际上国内大多数中小企业的软件开发,哪里有什么需求分析和设计可言?都是什么文档都没有写,一上来上来就写代码,代码就是文档了.

[vcchen_bo_qiang]

支持一下！！

[Walf_ghoul]

先设计，再编码。。

[Alan S1]

[Quote=引用 48 楼 Walf_ghoul 的回复:]
先设计，再编码。。
[/Quote]
这句话没错，但是设计到什么程度是要讨论的，有的时候概要设计再编码反而会大大节约时间？不是吗？

[huizhouxueyuan]

可以置顶了！~

[ahao]

为什么有coding和design之分。如果design能详细到每个接口参数，详细到每个算法，详细到每个你要去用大脑思考的细节。那么只有design了，代码让机器自动生成就可以了，还需要什么coding？？
所以，你的问题也毫无意义，说到底就是个度的问题。

[DarkChampion]

路过

[Meteor_Code]

[Quote=引用 9 楼 zhh157 的回复:]
说说我的想法，首先，我觉得软件工程、项目管理和开发过程等式超越语言的。
可能的原因有
1. 需求不确定，或者说不确定的程度超出你的掌控。你无法在一个需求捉摸不定的需求下进行架构设计和详细设计。
2. 对需求的理解不够透彻，在需求没有彻底理解的情况下，贸然进行架构设计、详细设计只会让你得不偿失。
3. 架构设计做的不够好，很简单，大楼的地基已经夯实（有了可控的需求分析），但是，管线布控、通风照明等设计很…
[/Quote]

只要需求确定,透彻理解需求就很简单,理解了一个明确的需求做框架设计就是一个经验和时间的问题,开发精细是个个人自身的问题,
就我的一些经验,还是将原始需求转换成软件需求的过程是最重要的,其次,要在设计之初就考虑到设计的最大冗余,使得之后即使发生修改也会变的容易,在代码开发过程中一定注意分块设计,不同的模块只可以用接口来交互,还有就是软件设计中看见必须是软件需求,而不是原始需求,有无数的人分不清这两个之间的区别,
不要认为"最大冗余"会给设计带来麻烦,因为代码可以重用,任何一个企业做的产品都是类似的,一个项目结束之后,另一个项目还可以使用这些代码,如果一个设计小组初期的代码做的就不伦不类,即没有冗余性,也没有移植性,这个小组就解散吧,因为任何一个软件企业,他要的不是成品的软件,而是软件后面的有效代码.只能作出软件的小组和连软件都做不出的小组没有任何区别,因为企业要的是高效代码,而不是一个EXE.还有就是个人问题,一定要注意自己的事情就应该自己完成,不要把应该在自己的代码里完成的东西转交给别的模块,任何一个模块都要做到独立性.
最后还有一个很有意思的现象,我发现很多说自己懂得软件工程的人根本不按照软件工程说的去做,最后导致一个软件项目做的不伦不类.送给一些管理人员一句话:不要相信所谓的知名企业做1到2年就出来的人就可以多么厉害,想想他要是有很高的能力怎么会只工作1到2年就出来,那些大企业的待遇都非常高,虽然辛苦,但人家在招聘开始就跟你说,工作会很辛苦,所以在我看来,这些人大多是自己做不下去或者被淘汰下来的.我所在的公司已经深受其害了.

[Dobzhansky]

We try to solve the problem by rushing through the design process so that enough time will be left at the end of the project to uncover errors that were made because we rushed through the design process.

[once_and_again]

框架 .

[itegel84]

不管是敏捷还是什么，其实都需要进行设计。
详细设计如果只把它看成是瀑布的一个过程，那么其他开发模型就不需要先详细设计再编码了。
如果把它看成是一个普通的项目开发环节，那么肯定是需要的。不设计怎么编码？
敏捷中设计测试用例等等都是详细设计的过程。

另外这些都跟是不是C++项目没任何关系！

[晨星]

[Quote=引用 56 楼 leogle_reloaded 的回复:]
引用 37 楼 steedhorse 的回复:
不管什么方法，目标都应该是在有限的时间内，为客户“全部完成”尽量多的最有价值的软件特性。

客户选择某家软件公司开发其项目，会参考该公司的生产能力和用户满意度，生产能力包括开发效率，千行bug率，产品质量等，用户满意度就比较广泛，前期调查，bug发生率，维护等等。而文档是体现软件公司生产能力的直接依据。如果忽略某项开发过程或跳过详细设计工程却生成详细设计文档，那么公…
[/Quote]
我前面强调“全部完成”，是指一项特性的完成要经过相关的单元测试、集成测试（其中包括了回归测试等），然后等测试部门甚至客户代表验收后才算“全部完成”，并不是说口头上说一句“我做完了”就算做完了。
从现实的角度考虑，我不认为过度详细的设计文档能大幅提商软件产品的质量，设计文档对质量的保障作用远不及可反复运行的测试套件，有了测试套件，每运行一次，都能直接得出一个“通过”或“通不过”的结果；而仅靠文档的话，那让谁负责每天（甚至每小时）去核对一遍软件行为跟文档描述的一致性呢？
另外，从我待过的几家公司来看，客户需要的文档更多的是产品说明书、以及架构级的概要设计文档，而非具体的类、方法级的详细设计文档。一般客户都不会关心我们使用的语言、框架这类东西，更不要说与代码几乎对应的详细设计文档了。