关于详细设计/代码的同步问题--请教

按照"设计文档/代码"分开的原则做，越做越怕:
rose model中的那些注释等，还要一个一个的copy到代码中，工作量已经很大了。等rose model发生修改了，该怎么办呀...

Together Control Center6.0好象可以实现这个功能。

尝试过一些做法，都不尽如意，最后的做法还是在代码中加些注释，详细设计文档中只记录一些不易改变的内容。按照xp的做法，只有代码是可以运行的，不要写没人看的文档。

没必要在rose里为每个类写注释，可以把这些时间用到代码的注释上去
生成javadoc一样可以很方便的查看，需要的时候再对整个source code做
一次完整的逆向工程
rose里记录的更重要的信息是整个系统的actors and cases，关键的
state chart等

用together吧，有几个版本

together cc不知怎样，
together for jbuilder不好用的，要在两个窗口切换，而且特耗内存

强烈推荐together for eclipse，不用双向操作，做到即时同步，当然用eclipse做web还不太方便，但是做java project，我觉的比jbuilder强，特别是refactor功能

我现在把一个web项目分两部分，一个是核心java prj，另一个web prj，引用java prj生成的jar

传统方法的缺点--难以维持设计/文档/程序的一致性。这么久以来都没能解决这个问题（相信很多人有这个感受）。所以不得不怀疑传统开发方法的适用性。看看国标的文档模板，真TMD恶心，在实际应用过程中效果如何？我是没有遇到用的很好的。
所以现在想换一种开发方法，使用XP方法尝试一下。
但我对xp方法了解甚少，现有一问题请教:(问题较弱，莫笑话我)
xp过程，会有哪些文档，其中哪些是过程性文档，哪些是最终留下来的文档？在做的过程中不断涌现出来的一些想法，算法，结构，需要记录成文档吗？如果是，记录到最终留下来的文档中吗？

楼主我不得不告诉你，你对Rose误用了，Rose不是用来生成代码的，只是一个设计工具，不要在Rose设计的类图里面添加太详细的注释，并且期望把这些注释导入到代码中去。

Rose你做到系统分析级别，也就是说到设计的系统不依赖于具体语言实现就该结束了。不要再细化到具体每个类的每个具体属性了，这就误入歧途了。

开发阶段对类的修改是非常频繁的，需要不断的根据系统实现的考虑修正设计，折衷，如果你在Rose里面都详细到每个Java类的每个属性和方法，改起来你会累死的。

> Rose你做到系统分析级别，也就是说到设计的系统不依赖于具体语言实现就该结束了。不要再细化到具体每个类的每个具体属性了，这就误入歧途了。

同意。从发完那个帖子之后，我也没有再那么做了。原因很简单，如果一种方法屡屡失败，就有问题了。

但即使如此，还是无法解决设计/文档/程序同步的大量工作。所以要尝试另一种设计/开发方法，从减少“中间环节”开始。说白了，就是减少文档的数量。

我这里说的“减少文档数量”，是指那些最终要提交的正式文档。还有很多非正式的中间过程文档，作为我们自己的交流文档和备忘录，还是要的。

也许你们需要引入 Process. 方法都是好方法，但是操作的过程不同结果往往大相径庭。

我以前在 R&D 的时候，一般就写 HLD,DD 等文档。每个软件版本都有 Feature List(这一般是由 PM 确定的),然后就有人根据 Feature 写 HLD 和 DD. 每份文档出来后都要有 Review, 要留底(通过 一个文档管理系统来管理),而且每个对文档的改动也都会产生一个新版本的 Document.

后来公司 Process 改进，要求程序员做好 Unit Test, 减轻 SIT 组的压力，于是我们开始承担一部分测试。测试时也要写 Test Plan，测试组的同事写了一个系统，可以在 WEB 上编制 Test Plan,然后产生 CheckList,测试时就对这些 CheckList 打钩，最后可以要求系统提交一份报告。如果有BUG，还要提 MR. MR 修改后，要写修改了什么，为什么修改,不写不能入库。

产品出来以后，会有Document Group 的人负责写操作指南
......

在我离开 R&D 时，公司的 Process 还在变化中。

我的感受是，软件只是一个辅助工具，只有 Process 走通了，才应该考虑如何引入软件来减少操作上的复杂度。

设计与编码的同步，照我现在的经验看来，基本上没有什么工具可用，主要还是靠管理和手动的同步。
我现在的项目用的也是Rose做类设计，然后生成初始的Java代码，但在以后的开发中，往往很多类都被删除或改名或修改了内部结构，所以我现在的做法是：一段时间后，从Rose里面Reserve一下源代码，但Reserve代码只能让类设计部分保持一些同步，对其它更复杂的设计部分根本不能同步，只能手工修改其他的设计部分。

要保持设计文档与源码的同步，我觉得要做好以下2点：
1、设计文档尽量简洁，不要涉及太多实现中的细节，不然以后实现有大的变化后，设计文档就有的改了；
2、定期对设计文档和实现做同步；

呵呵，其实以上2点我自己现在根本也没有做到…… :(

可用Together来确保详细设计、代码的同步

其实如果详细设计做到这个地步，一旦需求变化频繁，反而增加不少额外的工作量。设计关键在于从更高层的角度来规划全个系统，很多人看到together能和代码结合起来就好像捉到了什么法宝，实际上工具永远是工具，关健是你怎么去用它，这就是上面iceant 提到的process。
我最喜欢用word文档＋代码注释，这里还有一个原因，直接在together或rose修改没法清晰反映出相应的版本改动，而在word是可以一目了然的。

> Rose你做到系统分析级别，也就是说到设计的系统不依赖于具体语言实现就该结束了。不要再细化到具体每个类的每个具体属性了，这就误入歧途了。

不太同意!如果最后代码与设计类图不一致，那设计类图还有什么用呢？又不是像画家一样画出来欣赏的
类图就应该跟代码保持一致，这样，后来者就可以通过设计类图来把握系统全局。
当然，手工同步是比较不爽，建议用Together for Jbuilder 或者Together for Eclipse

实际上说到“详细设计与代码”同步，有一点要清楚，究竟设计出来的什么样的设计模型和代码同步，一般详细设计模型是分很多种的，除了提到的一些类模型，可能还有一些用例，DFD，甚至最详细的关于算法的伪代码，所以就算你用rose或together，也就是方便了你类模型和代码的同步，其他怎么办呢？所以说关键还是要从开发过程去控制和管理这个同步问题。