当前位置: 代码迷 >> 开发过程 >> 愁啊项目开发了二年,从1。0版本升到了5。0版本,越来越乱了
  详细解决方案

愁啊项目开发了二年,从1。0版本升到了5。0版本,越来越乱了

热度:9752   发布时间:2013-02-26 00:00:00.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个项目。搅在在一起更乱。
------解决方案--------------------------------------------------------
  相关解决方案