愁啊项目开发了2年，从1。0版本升到了五。0版本，越来越乱了

愁啊！项目开发了2年，从1。0版本升到了5。0版本，越来越乱了。
愁啊！项目开发了2年，从1。0版本升到了5。0版本，越来越乱了。
两年前着手的项目，用了8个月，完成1。0版本，在客户那儿使用，初验结束了，后来根据客户的要求，加了许多新的功能，版本升到了5。0，但是，用我们产品的客户有4家，功能在增加，版本在升级，分支越来越多。
用CVS，VSS来做版本控制，可是，还是一团糟。有了历史记录，可是找一个文件很麻烦，得查一堆的文档，烦死了。
想从配置库中找到当前的最新项目情况，看不出来。
分支，合并的太多了，看管理的历史文档，一堆，头大了。
想查一下，当前的产品5。0版本下面有那些模块组成，那些在4。0的基础上做了修改，那些是新增加的模块，太难了。
产品开发容易，维护难啊，管理明白了更难！
我该怎么办啊？
大侠们给点儿点子。
－－－
先给100 出来，看看大家有什么好主意。。。

－－
－－




------解决方案--------------------
我没有开发经验，不过我说说我的看法，如果在起文件名的时候加标识，标明是第几版本所添加的功能，将相关的内容都放在一起，功能尽量内聚。我认为一切的整理工作应该在开发过程中进行，而不是事后整理，因为事后要消耗更多的时间。望高手赐教。
------解决方案--------------------
让变化的代码,和变化的文档一起来管理呢?

还有要注明变更内容,时间,客户的要求,模块化的呢.
不过让客户牵着走的确是很麻烦的.
------解决方案--------------------
提一下，个人意见。

最主要的还是能在开发过程中，进行重构。
如果本来程序就一团糟。
文档再怎么管，还是隔靴搔痒吧
------解决方案--------------------

   还是花力气来整理清楚吧，反正总是要整理清楚的（除非你不干了）。另外要求大家做事情规范一点，情况会好一些的。

------解决方案--------------------
关于“重构”的问题。坦白说，我也没什么实际经验。
因为看过点XP的书，尝试过些Junit的自动测试，
还比较喜欢重构这个观点。

首先我觉得，大家一般的工作环境可能是这样。时间紧任务重，
能完成功能、按时交货，就上上大吉了。
写文档？1没时间写，2懒得写，3不知道写什么。
大多数时候，我觉得代码本身比文档更有可读性。

版本扩展的时候,很多人都是copy一段paste再加
一点,实现新功能的扩展。这样的系统一般都是"低聚能,高偶合".
这样下来积累了2年，就轮到楼主接手了。

我觉得要完成重构，首先要有类似peer review的机制。
在开发的过程中，比较频繁的进行代码评审，频率不低于2天一次。
相关人员互相白箱审核设计和代码，及时抽取公共部分，进行持续设计。

可能有人会说，为什么不一开始把公共部分都设计好。能设计出来当然好，
很多时候我们并不知道哪些可能是公共部分。如果一开始贪大求全，反到容易
把事情复杂化。到不如，如果一个情况出现一次的时候，只要实现功能就可以了。
如果出现2次以上就再针对这个问题进行设计。
但大多数时候出现2次以上的时候，大家还是按出现1次的方法去处理。
这种情况，看上去是初期设计不够充分，但我觉得更多的是开发过程中的沟通不灵所造成。

如果大家有每天花一点时间,做peer review的制度，可能会有所收获。不过大家可能都
不喜欢别人对自己的设计品头论足或者teamleader抱着实现功能就可以的态度。这样很
难将peer review进行下去了。

还有个问题就是，在重构或者整理代码中，要冒着引入错误的危险。
整理了半天，然后发现程序不能运行了，一定很受打击。
XP的实践方法，要求有自动测试机制。每个模块都有比较完整的测试用例，而且能自动执行。
这样，修改整理一部分后，就运行一下自动测试，查看一下有没有引入新的错误。
我自己尝试着在一些java项目中，使用junit进行自动测试。 觉得效果还不错，
即使过了好几个月进行修改，原来的测试用例，还是比较有价值。但要完成全部的自动测试
就有些困难。

说了半天，对于楼主目前的处境来说，只怕是一点现实的帮助都没有。
前人造下的冤孽，也不是一下能赎清的。

现在只能指望"编程之神"给予楼主智慧之眼和勇敢之心。能够看出分散在系统各处
的功能类似或重复之处。并在没有自动测试的保护的情况下，以大无谓的气概把
它们集中到一起时，而原系统还能运转自如,又不引入新的错误。 Amen...

关于“重构” 有本书中英文版皆有。
关于自动测试 junit的使用 ,下面有篇本人写的小教程，希望能有所帮助。
http://www.delphibbs.com/keylife/iblog_show.asp?xid=2441


------解决方案--------------------
能重构的就重构、
不然抛弃 重做

看看《重构》
------解决方案--------------------
或者经过一个版本以后，重建VSS，这样应该更好一点，因为VSS也会坏的哟
------解决方案--------------------
《重构》
http://www.cnforyou.com/query/bookdetail.asp?viBookCode=9185

配置管理固然重要的，但最重要的还是整理代码本身。
------解决方案--------------------
我认为和重构没多少关系。

主要问题是你们根本不是在做产品，而是在做项目。
或者你们使用的开发工具是面向项目的RAD，不适合开发产品。

作为产品，每次升级，所增加的功能是严格定义与管理的，
而且所有用户使用的是完全一样的东西。
不能用户有要求就加。

若是用户确有合理要求，但比较独特，不适合加入产品中，
就要在产品中预留适当的接口，然后在外挂模块中实现。





------解决方案--------------------
每次修改作最详细的log
无论程序还是备注目录
定期做大的Pack,这样便于管理
重构就有点... ...
------解决方案--------------------
若暂不能重构，早点按用户分为4个项目。搅在在一起更乱。
------解决方案--------------------
rtdb(东临碣石) 说得很对,你们不是在做产品.

我说说我的经验吧,我们有一个报表系统一直在不断升级,
在每一个源文件更新时规定一定要写更新或修正说明,在
不定时检查时发现没有做这步骤的就强制该源码负责人修
正,在一个版本积累的一定的修改后或者客户的需要会发布
一个版本,这之前会做一个Label,在Label说明中写上至上
一个版本发布以来的新增功能,修正等信息.当有定制需要
时,作为特例处理,发布定制版本时只备份该源码.
在应用中碰到问题无法确定就查看历史版本的更新信息
基本上就能确定问题位置.该系统和流程一直维护到现在,
依然非常流畅.

不知道哪位还有比较好的经验,欢迎共享之.
------解决方案--------------------
同意wolfsquare(狼平方 Swing报表工人) 。
我们公司也是这样做的。 后来为了控制BUG数量，做的更严格：
取消大部分人的CHECK IN权限，CODE REVIEW后再CHECK IN。
再就是新版本发布前，提前一个月CLOSE， 进行TEST。

------解决方案--------------------
这种情况我也遇到过，我不知道你的程序基础和你的人力支援情况怎么样？
如果你的程序基础很好或者是你的人力资源很丰富的话，重新计划你的开发计划加长程序审查时间，这个时间包含如下内容（培训你的人员——统一你的程序风格，加强可读性），整理你的程序文档——最简单的办法画出程序流程图），加入严格的变更管理控制。你的程序整理完成之后可以使用上述各位老兄描述的方法是程序更加清晰。
------解决方案--------------------
1.每个项目都有一个新的配置库。
2.完整的技术和式样说明并一直维护到项目结束。
3.在做任何一次发布的时候维护发布履历，更新所有的文档。
4.重要的发布在放到发布库的同时将放到基准库中。
5.项目结束后将项目的配置库封闭，备档。
6.新项目开始的时候就应该确定所有的需求，知道现有的基础是什么，需要新添加什么需求。从上一个项目的配置库中取得最终版本作为开发的第一个基准开始新一轮开发。
7.模块也应该有严格的配置。
------解决方案--------------------
重构是一种保留程序行为的程序转变，能够自动改进面向对象的程序设计。这种设计改进主要有三种，分别是：方案转换、设计模式微结构、特点驱动式趋进。

重构是一种参数化的保持行为的程序改进，它自动更新程序的设计及相应的代码。重构典型地表现为一个非常小的、对程序代码有直接影响的程序转换，对其所处理代码的一个直接影响（但不是那种随意的改变）。

在需求不断增加，使代码越来越乱时，开始重构；
定位程序中的bug时，需要重构（因为代码不够清晰，一致有些隐含的bug很难发现）；
做代码评审时伴随着重构，在代码评审中，需要其他人理解你的代码，这个观点来自于xp中的成对开发。
------解决方案--------------------
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察之行为的前提下提高其可理解性、降低其修改的成本。
重构（动词）：使用一系列的重构动作，在不改变软件可观察之行为的前提下调整其结构。

------解决方案--------------------
不管你如何的标识，如何的保证所有的变更都有记录，如何保证所有的版本都有详尽的说明，你还是不可能在大量的版本中寻找到合适的模块和功能的。
  如果你真的觉得现在版本太乱，同时维护太多的版本（你不会需要从以前的各种版本中寻找某个功能然后组装一个新版本吧？），你应当考虑减少同时维护的版本数量。不管外面发了多少版本，维护几条主线，逐渐的升级起来，不要每次某客户有了需求，就去寻找当时它使用的版本来改。
  记录清楚上一个版本与下一个版本间的差异，修改了什么bug，添加了什么新功能。
  其实再好的配置管理，都及不上减少同时维护的版本数量。
------解决方案--------------------
我們公司也是Visual Source Safe來管控程式源代碼.目前感覺還行.

我們的程式命名規則為模組代碼+0001,如系統管理模組為SYS001,SYS002...

當然我們有一份文進描述每支程式的功能...
------解决方案--------------------
用CVS进行管理，每个项目或版本用一个tag，这样无论是多少个版本都应不成问题!