愁啊！项目开发了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，这样无论是多少个版本都应不成问题!
随时可以checkout其中的一个版本进行升级，多借鉴linux的开发进程吧，全世界的
程序员都在对他进行维护、管理、升级，也没有听说什么太多的困难！
[解决办法]
重新整理代码，坚持模块化开发（指子函数）。
使用查表法和函数指针相结合的编码技术。还可以结合一些抽象数据类型的编码技术。
以我的经验，4、5万行的代码（手写的）应该不成问题。
[解决办法]
项目可能就要这样下去了,因为可能你得上级和客户不会给你这么长时间给你做重构之类得工作,他们会对你说:小龙女,给你两天时间把这个东西改完..........什么时间不够??.....那就3天...总可以了吧!
所以我觉得一旦项目进入后期基本上没有机会有大规模得改变了,除非你有充足得资金和人力来支持你们.
既便是有了资金,人力.不懂技术得老板通常会想,我们以前已经开发了类似得东西,以前用了5个月,现在改改用2个月改完,哇赛,原先5个月挣了20W,现在2个月挣了20W,我们得效率提高了不少.所以我们得代码会一直乱下去,只到有一天,老板发现,效率怎么提高得慢了,他们才回想到去改善开发.
开发出完美得代码是程序员得梦想,积累更多得资本是老板们得梦想,这两者通常是相抵触得
个人得对项目得一点看法,请指点
[解决办法]
xiaolongnv(小龙女)
哦，我老了，所以反映迟钝。麻烦你说说你理解的Daily Build是什么意思，refactoring是怎么？特别是说说“但是,在软件产品基本稳定后,我们会周期性测试的”和Daily Build的关系。
说重构，我怎么看不到这里什么人有重构的经验，你们说说重构的保证是什么？重构和版本管理的关系是什么，重构会让你现在一团乱麻的版本管理变得更好？
我是在贬低你们这些CMM爱好者吗？Tom Demarco说CMM是软件企业的耻辱，是说CMM使软件企业丢失了创造力；在中国还要加上，丢失了职业道德。就你们那个SCM的水平联CMM2的KPA都达到不了。你们有的只是一堆发臭的规范。这样的水平不死，只能发生在这个经常发生奇怪事情的国度。你们通过CMM的用意是什么？还不是去和国家要利益。
还有你们明显是多版本的分支体系，就你们用那个VSS可以控制这么复杂的情况，而且CVS对于这样的情况也是麻烦而不易使用。
真是的你们这些人天天叫CMM，可是有几个比我对CMM熟悉。还拿长沙新宇公司都是过了CMM5说事，真是好笑。他们实施了多久CMM就过5了，脸红不红啊？
回去好好查查资料，看看refactor到底是干什么的，Daily Build到底是干什么的。别说让自己丢人的话。
[解决办法]
项目开始的时候就应该把软件架构搭建好。
不同的客户有不同的模块，但相同的部分（一般都是底层）可以建一个 Main Tree。
不同的客户从Main Tree上分支出子树，通过makefile配置模块的编译。
开发过程中，为客户定制他们的特性，也不断维护通用的Main Tree。
[解决办法]
xiaolongnv(小龙女)
你们怎么越来越搞笑了？
“用CVS，VSS来做版本控制，可是，还是一团糟。有了历史记录，可是找一个文件很麻烦，得查一堆的文档，烦死了。
想从配置库中找到当前的最新项目情况，看不出来。
分支，合并的太多了，看管理的历史文档，一堆，头大了。
想查一下，当前的产品5。0版本下面有那些模块组成，那些在4。0的基础上做了修改，那些是新增加的模块，太难了。”
就这样的情况，什么人还要重构。玩笑开的有没有限度啊，死还要死的最难堪的那一种，还觉得现在的版本不够乱。
说daily build，“通常最短２－３天提交一次版本，因为每个开发人员负责很多的开发模块，BUG是批量改正的，每个PACK对应一系列的BUG。”什么样的话你都说啊，nt千万行都daily build，他们是怎么做的？2－3提交一次，难道他两三天才编一行代码？
ericzhangali(卖女孩的小火柴——五毛钱俩一块钱不卖)你也是，看你总在我坛子上混，我就对你好一点，可是你也太不让我满意了。SCM是要建立各个版本间的统一和协调，你划分更多的模块之后，虽然有帮助，但是协调的工作就会更加繁重，就他们现在的水平还维护到模块？
他们联最基本的版本基线都找不到在什么地方，还划分模块，建立maintree？他们搞笑，你就别给他们添乱了。
所以你们这些人最好回去好好学习一下，版本管理到底是什么东西，手段都有什么。基本的都搞不定，还玩CMM3。CMM虽然让我讨厌，但是好歹CMM还能让我研究一下，CMM2的最低要求你们都达不到，还有脸来喊你们都CMM3了。为什么现在CMM名声这么臭，还不是你们这些人搞的。
[解决办法]
ozzzzzz(希望敏捷) 斑竹大人，你有你的理念，别人也有别人的实际情况。
你的理念不是一定适用的，这里的讨论和C/C++里最大的区别，那里一个问题有标准答案，看看编译器怎么处理的，看看标准里怎么说的。
这里的问题，只能说比较合适的选择，每个人想法不同，每个公司、团队想法不同，大家也都在摸索，现在提出的新理念现在看着用着觉得挺好，没准以后就被替代，被推翻了。
在这里的讨论，主要是个适用，而没太多的绝对真理。
所以，个人认为不应该见谁就说水平低，能力差，这个不懂，那个不会。
我来这里是来学习的，没有权利要求你对我怎样，也没有义务非让你满意不可。
虽然对斑竹大人的态度有些看法，但不妨碍继续向斑竹学习。 （ ：
[解决办法]
我们的开发是基于C/C++的跨平台开发，CVS Server 是 Sun Blade/Solaris ,
CVS Client是 WinCvs / win2k + sp3 ,我们已经在此模式下开发了不少项目
而且好像并没有碰到什么麻烦！我们的软件版本涉及到不同的操作系统：win
/linux/solaris, 还包括不同的项目工程，运行情况很好。真不知道你们CMM
是怎样实现的
[解决办法]
啊，那我的项目比较小，我基本上是人为的管理，我觉得人的因素决定一切，呵呵
只要适合自己，就用，不适合自己，就不用，管它什么CMM 还是CMM3~~~5 ....
[解决办法]
呵呵，你就让O6z痛快一下吧，好容易有一个典型跳出来可以当靶子。
我是不敢发言的。因为我实在不知道当最基本的版本管理都乱得一团糟的时候，还有什么奇招妙着能够救你。学习。
[解决办法]
ericzhangali(卖女孩的小火柴——五毛钱俩一块钱不卖)
等你明白到底怎么回事你就会和我一起骂，而且你骂的可能比我还凶。至少你骂我的时候就根本不知道我要干什么就开发骂了，现在让你知道到底发生了什么你还不更骂。
他们从cvs中不会回复以前的版本，而且找不到最新的版本，这可以说是我第一次听说的奇闻。天大笑话，如果这样cvs还用来干吗。本来就够好笑了，今天他又来了一个更好笑的（其实我前面以前提醒过他了，scm是cmm2的kpa），他说“补充一下，项目在参评CMM的时候，刚刚到２。０，问题还没有暴露出来。一个状态记录表就可以清清楚楚看明白。”不知道他知道不知道SCM是cmm最基本的kpa，没有达到这个就只能是cmm1。你说他们是怎么通过评审的。而cmm两年一次复审，不知道他们怎么通过的。反正现在cmm只是一个噱头，谁喜欢就可以拿来骗一把，所以我一般也就见怪不怪。可是他们这个就太过分了，我见过很多烂cmm，可是没有见过这么烂的scm。cmm再不好，但是它对于scm的重视还是很严格的。而不知道是不是真的cmm就要被废止了，所以主任们有权不用过期作废。我原来还对那些主任有一点幻象，认为他们不管怎么样都要做的秀，现在联秀都不用做了。而且你要明白cvs最初就是开发来给C/C++做版本管理的，要是说像delphi、VB这样的程序有2进制的frm文件可能合并等等操作的时候有麻烦，可是现在明明是C/C++,还搞不定啊。
xiaolongnv(小龙女)
你现在不是管理不好版本的问题，是根本就没有SCM制度的问题。
我先给你说说大概应该怎么做，你回去想想看有什么不明白，然后我再来告诉你怎么解决眼前的问题。
首先CVS的功能就是告诉你当前的最新版本是什么，以前某一个时间的版本是什么，如果这个都搞不明白，那么请看看CVS手册。
然后在开发中，我们一般情况下是首先建立一个单一的版本(我是没有看到过多版本一起的开发的新产品，即使有也是先建立一个基线产品，然后在对其做增减）。而在建立这个版本中会有多次的集成。当然你可能运气超好，或者水平超高，就安排一次集成，就一次ok。否则就必须多次集成，不这样你的集成测试所发现的bug也不可能被修改啊。而集成bug是系统内的兼容bug，最为让人头疼，寻找麻烦，修改也麻烦。所以XP才搞一个持续集成，MSF来一个每日建造，不是说他们水平高，而是他们认为自己水平不高。当然也许你们水平高，能从一堆代码中找到bug，可是即使如此你们一样要化时间。而减小每一次集成之间的时间，就可以减少每一次修改和新增的代码数量，也就更容易对bug定位。就是因为水平低，才需要更大密度的集成，而不是隔两三天把一批bug修改完毕再去集成。我的经验每修改3个bug，就会出现一下新bug，而每多100行新代码就会多付出1个小时的寻找bug的时间。所以即使是winNT这样的千万行代码的项目也坚持每日建造，不是别的，而是被层出不穷的bug搞怕了。当然世界上有linus这样的英雄，他说好程序员就不会写有bug的代码，所以他们的linux内核就一直不加入debug功能。你要是觉得你至少不比他差，你也可以随便搞。
而每一次建造会得到一般版本，这样的版本我们叫build，它只是通过了白盒测试的版本。而你所做的内部黑盒测试就是，针对这些build的。当你的这些黑盒测试达到一定水平的时候，你就要沿着版本树向上测试，当到达最后一个完全通过的版本时，你就把那个版本确定为release。而我们说的阿拉发版本和贝塔版本，你就可以认为贝塔是这个release，也可以认为阿拉发版是这个release，而通过一定的客户测试后得到的修改版是贝塔，这写你们可以自己选择。而最后当这个发展后的release，你判断它已经符合市场的要求，达到成品标准的时候，你就可以认定它为一个standard，这就是一个真正的产品版。你从我上面的表达可以看出，standard肯定是一个release，而release不一定是standard。每一个release都是一个build，而build不一定是一个release。那么standard也是一个build，而build不一定是一个standard。于是有极端的人要求，每一个build，都必须达到standard的外在标准，比如如果你会以cd发布你的软件，那么你得到的build就应该是cd，如果是dvd，你就应该拿到dvd的build。需要用户手册，那么你的build也必须有那个手册，总之每一个build除了bug和功能的差异，和真正的产品都完全一样。当然我觉得这有些过分，它也告诉你build，不是那么简单的把代码放到一块就可以了，你必须为其准备集成测试，还要把他们完全编译。
这是简单的单版本情况，而实际情况往往是多版本同时开发。比如当你有了standard1·0之后，你要维护它，修补bug，于是会不断的推出1·1－1·2之类的版本。而同时你还在开发新的更多功能的2·0版本。这些版本间有共有的代码，注意是代码而不是模块，特别是那个小火柴，一定要理解这些共有是建立在代码基础上的。比如你修改了一行代码，那么你的版本升级了，可是你并没有模块级的改变。在多个版本共同开发的时候，你会发现有不同的几个standard和release以及build，这个时候就要建立他们不同的分支。而由于有cvs等版本控制软件的支持，我们可以很容易的得到当前的最新版本和以前的任一版本，这是因为你的每一次集成都会被记录到你的资料库中。这些资料要包括你测试的版本，代码的版本，建造的时间，产生bug的记录。这些都是可以用工具自动执行的，如果达不到自动，就去查查手册。
而不同的体系版本间会有兼容问题，这也要看你的产品策略。我们以简单情况为代表，这个时候你的新开发的代码如果不使用在1·0的系统下，就只要去考虑对于其在2·0体系下的测试。而你要为修改的1·0的bug，则你要看在2·0是不是也同样有这个bug，如果有就说明这是你在原始代码中的bug，你需要回归测试到0·0，寻找到底是那一点代码产生了这个bug。而如果只是1·0体系下的bug，则当然只要回归测试到1·0。
其实说了半天，没有什么复杂，关键是要坚持做到每一次少提交一点代码。而那些记录其实都是可以由程序自动完成的。你现在遇到的情况，真的让人匪夷所思。而其实你们的PM提出的建议就更加让人惊奇，但是最惊奇的还是这里有些人让你去重构你的代码。现在事情就已经够乱的了，再加上重构这个对于版本控制要求非常大的手段，你们死的会更快。
这根本就不是什么理论和实际情况的问题，这是典型的混乱开发。而且我也奇怪你们怎么会认为C/C++是一个特殊情况，难道cvs最初不是为c准备的？
骂了你们半天，最后还是要我出来给你们上课，所以没事被我骂几句，你们也值得。
[解决办法]
身为一版之主，在面对高手的讨论，或是面对菜鸟的指导时，个人认为都应谦和、平易，这才是大家风范，而且记得在其他o6z的帖子里看到，o6z资历不浅，不是年纪轻轻之小伙，怎么看到别人不满就言语如此激动呢？
o6z斑竹向我做的解释确实清楚，一看就明白了，有理有理。现在去重构肯定是荒唐的。
继续学习。
[解决办法]
ericzhangali(卖女孩的小火柴——五毛钱俩一块钱不卖)
嘿嘿，我不是高手，也不想作什么高手，我也不是一个还算温和的人，但是在工作和学问上我绝对不会去玩什么好好先生。我数次发火，你还没有看到过，那是很久以前，那个时候我也不是这个名字。我现在言辞激烈，也只是由于看到一些根本就不应该发生的事情。其实他遇到的问题是最基本的CMM2就必须解决的问题，怎么过了CMM3还会出现，而且我昨天和朋友聊天，他说CMM4的企业一样有类似现象，而后来一个人又偷偷告诉我CMM5他也看到过找不到最新版本的事情。事情到了这样的地步，你说能不让人感到痛惜吗？我虽然反对CMM，但是我觉得至少你去实施一下CMM也比你什么都不作强。可是如果是这个情况，我就敢说，他们搞的CMM，就是为了18号文件去的，和软件工程什么关系都没有。说实在话，我不同意用什么工厂式和作坊式，来概况软件开发。但是借用一下这个概念，它们之间的标志性区别就在于有没有SCM。而他们的情况对于一直好称是工程化的CMM，是莫大的讽刺，通过CMM的企业在我的心目中的地位越来越低。而你也可以从SCM工具的销售看到，其实CMM还是非常重视这个KPA的，实际上现在往往大家都在通过CMM2的时候，重视的是文档和规范，而很少有人重视SCM。就如同你看到的MS的winNT一次编译要经过19个小时，但是他们还是坚持每日建造，并且最后项目组将开发的成功也归功于每日建造，而你去看看现在随便一个什么国外的流行的商业软件，那个版本号最后不是一个几千的后缀，那个不是说明白别的，就是在说明这个版本是第几千个build。而我们还是在一再推脱，说我们水平低，作不到每日建造，要几天甚至几个星期一次建造。我就奇怪了，你到底是水平高，还是低啊，高你也高不过MS吧？
很多东西你不了解内情，所以你就看不出问题有多严重。
[解决办法]
啊，原来是斑竹，我说呢？！
那，也不用这么激动嘛！
[解决办法]
重构是个好的想法，是到了重构程序、重构文档的时候了，就象电脑用久了就会乱总要拿出时间来专门整理。但也只能解决这一时，不能解决最根本的问题，老板和进度的要求不可能总让你拿出时间来重构，而且象中国程序员流动性又大，做到后面几版往往换了几拨人了，所以重构困难更大。我认为象这种版本分支众多文档繁复的项目，一开始就要下大工夫在版本管理、需求管理、文档规范三个方面上，虽然ＣＭＭ３不是万能，但它必竟世界公认的管理标准，绝对值得借鉴。
[解决办法]
glchengang(glchengang)
哦，你明白不明白什么是重构啊，懂不懂什么是版本管理啊。不懂就别装懂，看看我上面的帖子。水平低不怕，也没有什么可脸红的。但是像你这样的，无知而还乱发言就是天大的不该。
重构别人的代码还自己的代码从理论上没有什么不同，而且我发现重构者越是对代码结构无了解，其重构的成果越巨大。这是因为，重构是直接从代码中寻找模式，也就是寻找代码结构的内在规律。而重构所要求的最基本保证就是良好的版本管理，这个时候你怎么就看出是“重构是个好的想法，是到了重构程序、重构文档的时候了”？
我就不与你们讨论CMM是不是公认的标准了，讨论这些东西对你们也没有什么实际的好处，而且对于你们这些对软件工程一知半解，或者干脆就是一点基本原理都没有人，要求有点高。你们先把最基本的东西学好，我就很满意了。以后你们要发言，先要动动脑筋，不或者看看别人的发言，别不负责的乱讲。
[解决办法]
偶是进来学习的菜鸟，
偶接受过cmm2的培训，也在实际操作过程中用到了cmm4的度量，
偶还是觉得cmm有很多不错的地方，
记得我们在开发过程中，主要根据我们自己的实际情况，并没有完全的按照cmm规范做，结合了v模型和rup，50多天一轮开发，每一轮都有重构，而且我们确实解决了不少问题，配置库也很规范。靠，当时老大英明，跟着他简直太幸福了，我老大,西门，克劳斯，老虎，还有figo,winner,真牛，可惜现在没有跟他们了，真遗憾。
妈的，现在失业了，找不到工作，两个星期之前，跟人家打架，我用棒棒生生的那个188cm的sb送进医院住了一个星期，听说公司找到我还要陪20k人民币，你们说我离开那个城市能不能躲过这一劫。被我打的那sb,以前特嚣张，喜欢窝里斗，展示他很威风，一点都没有团队精神，日，警告过他三次，做人不要太过分。那厮不听，现在跟公司好的同事联系，他们说那厮现在不嚣张了。巨靠。现在过年了，找不道工作，真tmd麻烦。本来想在那里好好干的，下次见到还要打。
[解决办法]
ozzzzzz(希望敏捷) 真是言辞激烈，如果不是有点自信，象我这样一个做５年开发１年项目管理的老程序员，我还真是会看你的回复会转行去了（没办法呀，搞了这么多年还是没入门）。
我觉得很多人都喜欢把问题复杂化，我对重构的理解就是程序整理，这个整理也许是整个结构的调整，也许是仅仅是部分代码的优化组合，至于“重构是直接从代码中寻找模式”我觉得那是只是重构的一种方法。提到模式，由于粗浅看过一本＜＜java与模式＞＞的书，觉得模式确实不错，现在我做的项目是电信集团的一个全国性运维管理网站就是主要用到factory和proxy模式，但如果过于追求程序的模式化未免太过了，因为程序模式化也是有时间代价的。
ozzzzzz(希望敏捷)说：“我发现重构者越是对代码结构无了解，其重构的成果越巨大。”我以为然，当然要看是重构者水平高低了，但不用置疑重构者第一步要拿出相当的时间理解原程序，而原程序作者这一步就免了，而原程序作者在开发完成后也会了解到自已代码中的不足之处，因些重构的速度又会快一层。请注意重构是要付出时间代价的，特别是对顶帖那位老兄那种重个系统的重构时间代价更大，所以重构者最好是原作者。不过如果ozzzzzz(希望敏捷)老兄作老板就好了，你的产品会一级棒，但产品上线会一再的跳票。
最后再说一句大家来这里是探讨学习的，套用lnjit(4国杀手) 老兄的话来说：“没有必要用窝里斗的言辞，以展示他很威风”。这里帖一个关于ＣＭＭ的好帖（http://www.worldhello.net/doc/cmm_practice/）希望对受困于软件管理的同行有所帮助。
[解决办法]
glchengang(glchengang):
我对Refactory技术的理解和你不同。仔细读一下Martin Fowler的Refactoring你应该很容易发现，他所指的Refactoring应该是一种代码级的优化过程。重构强调的是smell，也就是从代码中能够很直接看出的重复，逻辑复杂，长函数，大类，从这些简单的smell决定程序是否需要优化。因此基本上我把它看作是自底而上对于设计的重新理解的过程。这本书里有很多简单实用的技巧，如果能够花点功夫掌握，并且应用的话，基本上可以保证你的代码干净，易懂。o6z说，“重构者越是对代码结构无了解，其重构的成果越巨大”应该是有一些道理的，因为重构一个重要目的就是让更多的人无需了解设计细节就可以读懂你的代码，而从其他人的角度，较易发现代码逻辑中混乱和不清楚的地方。
个人并不把Refactory认为是XP独特的地方，即使传统的软件工程，在Programmer完成工作之后，就应该有一个流程是对自己的实现Review和优化。有一个说法，第二次完成的结果总会比第一次好很多。我想这应该就是Refactory的原型吧。
事实上我觉得Refactory是一个很简单实用的轻量级的技术，只是现在很多人把它看得太神秘和复杂了。
[解决办法]
又再一次看了帖，我觉得小龙女面对的现状是内忧外患，外患是用户需求的多样化，内忧是产品一开始就没规划好，导致后始功能扩展的困难，其次是管理经验的缺乏导致开发混乱。我想你可以考虑以下的建议：
１、外患的解决：需求管理：不是用户的所有的需求都一窝蜂的满足，应定出重要的和其次的需求，急迫和不急迫的需求，并将一些可以合并的需求合并之，做这些事时基础是一定要搞清客户的直正需求是什么，以免需求理解不正确返工而增加后面开发和版本管理的负担。所以你须要有一个需求实现的计划表。
２、内忧的解决１：加强文档和程序代码规范。文档要精，杜绝大而无用的文档写作方式，程序设计思路、程序构架要点说明、代码流程是一定要要的。建议用ＵＭＬ来实现文档。代码规范包括命名规范（文件名、变量名），程序员都有自己的命名风格，比如修改一条记录的方法:modiClass, editClass, class_modi,classmodi....., 如果规范不到位说不定一个项目中这几种命名方式都会有。 另外项目组还要有人定期做code review和文档检查，以便防范之未然，尽早发现问题。
３、内忧的解决２：重构是必须的，其实早在这个名词还未出现之前程序员就已经开始做实际是重构的事了，每个项目都不可能一开始都考虑很周全，所以项目本身是一个不断生长而且不断自我调整的过程，可惜的是你们的产品到了５.0版本才考虑这个问题，所以面对困难会更大，但重构仍然要做，否则你们的产品到最后只能变成一个畸形儿而死掉（产品因不断的ＢＵＧ而溃烂掉，或被重写（凤凰重生？）），那时的代价会更大。重构有级别之分，我觉得在进度的压力下，没有能力做系统调整，可以做模块级的调整，由于我不熟悉你们的项目这里我也提不出更进一下的建议了。 前面的帖子提到“代码中进行重构”我深以为然，我现在的项目即是这样做的，每个月会有10%留给程序员做代码整理或者说重构，当然在之前你一定要有code review在之后你要开专门的会议来讨论和计划重构方案，完成之后再code review，以保证质量。 软件管理分隔化，分隔化是指程序员的工作以其所写的代码要尽量无关，完全无关是不可能的，所以做为项目设计师要给他们的接合处定义很好的接口，这样大家在相同的接口下各自完成自己的工作就不至于混乱一滩了。 软件设计分层化模块化，不知你们产品是否有API层，不要让你的程序员图方便将逻辑流程或功能实现直接写在前端代码中，提取它并将它加入到ＡＰＩ层中，这也是做code review和重构时要做的一件事之一，象你这种面向多用户多版本的产品共性代码的提取尤其重要。重构用一句话来说就是：磨刀不误砍材功。它避免了代码的混乱和腐烂，让你在后期维护时bug更少，扩展更容易。
4、内忧的解决３：版本管理，我只能用过VSS，好象也够用了，这里我提不出什么建议。我只说说我的问题，我们项目有些成员，把VSS将共享文件夹来重，我每次get last version时，因为其它成员没有check in其它相关文件，代码总是无法编译通过，于是一个个求他们将该check in的文件提交上去，实在是让我深恶痛决。由于我刚从深圳来北京，在这个项目不是ＰＭ，提了几次问题依旧，也无可奈何，幸好项目组人不多又都坐在一块，不然&*^%$^%$. 惨！ 希望你们是每天都会提交完本日的所有代码，然后build，不会有我那种情况。
５、最后提一点最关键的，让你老板多花点钱雇一些好的PM、设计师、程序员吧，做软件人最关键，否则什么方法也白搭，全是纸上谈兵，呵呵，当然前提是别把你换了就行了。
[解决办法]
我有一个观点：概念理解每个人都不同，不在于你理解的概念是否正确，而在于你学习概念后而得到的东西是否正确。我不喜欢玩概念，我喜欢概念后所包含更深层次的东西。
scalene(南瓜汤)说的东东正合我意，同意。：）
[解决办法]
对于软件重构，我想说几句，软件重构可以让以后的开发工作变得很顺利，
以前我们公司有一个产品的软件基本上是用C基于模块编程的思想开发的，
但是在维护时，发现很不方便，需要做大量的重复工作，现在使用OOP的编程
思想，用C++类来封装对象，利用类的继承和多态性，使软件更具有层次感，
开发出来也很轻松！因为产品必须跨平台运行，所以我们有点仿造linux内核
的模式，使用多进程和多线程技术，目前产品运行良好，但是初期的重构工作
做的很辛苦！
[解决办法]
glchengang(glchengang)
你提的那一堆建议都是纸上谈兵。没有实际意义。
重构刚才scalene(南瓜汤) 给你讲了一些，你仔细看看，别再有什么糊涂观念。而且你似乎是用java的，你看看《重构》吧，也算给我gigix卖点书。
看了你上面的发言，发言你依然没有最基本的概念，如果你真的是工作5年了，那么你的学习能力真的有问题。其次我不知道你为什么会用VSS，非常奇怪的选择。而且从你的发言来看，你的基本版本管理概念都没有，你还是仔细看看上面我的最长的发言，对你有好处。
然后我还是要再次给你解释一下，现在为什么不能重构。首先不管你是不是采取重构推荐的小步跑的策略，你都会明白，重构会增加新的版本。而现在他们的SCM这么混乱，你再去重构是不是会让局面更加混乱。而重构，你也要以最新的版本为基础重构，就像你必须以最新的版本为基础除掉BUG一个道理。只不过去除BUG，是要通过回溯，找到BUG,而重构只是以最新版本为基础。同时重构中也可以让你发现新BUG，这也是重构的一个功能。而发现新BUG之后，由于SCM的混乱，你也很难采取针对性措施。
这个时候根本就不能作重构。这个道理很简单。而你说的上面那一堆建议，在现在的情况下根本就没有价值。你说的根本就是给混乱的局面增加新的混乱。
最后你对照一下我的发言和你的发言，看看你说的是不是一个有五年职业经验的程序员应该说的话。仔细研究一下我的发言吧，对照一下自己的情况，找找差距。不是我倚老卖老，而是你们实在是水平差。
xiaolongnv(小龙女)
由于工作关系，我接触的公司都是在为生存挣扎的（国内大公司都是这样),所以我很了解他们的苦恼。但是越是这样，我就越是觉得保证最基本的软件工程方法的实施是多么重要。而这些基本方法中，最为迫切的就是SCM。而不管你对于CMM作合看法，实施SCM都是一个必要的手段。而你们的情况就是典型的SCM混乱的例子。其实如果你们研究CMM，就会发现CMM2的基础，也可以说CMM的基础就是在SCM上。在评审的时候，这个KPA是来不得半点马虎的。而别的KPA，即使是需求管理有些问题，也可以对付过去，但是SCM绝对不能有半点水分。而这个也可以划分是真CMM还是假CMM，最大的标准。而这个SCM管理建立起来以后，只要你去大概按照其要求走，就不会发生你现在的情况。
别的我就不多说了，你仔细看看我上面的一篇长篇发言，看完了再来讨论好不好。至少你应该明白，为什么持续集成比每日集成好，而每日集成比每周集成好，而且集成的次数越多效果就越好。
然后推荐给你一本书《CVS和Nightly Build技术》，清华的，一本很小的绿色的书。虽然我不同意作者的很多观点，但是我依然认为这是我目前看到的最合适初学者和一般开发队伍作版本管理的书。
其实要是我是你们的老板，我就会停下来把版本搞清再去继续，否则你们会越来越混乱，最后的结果只能是死路一条。而搞清这些东西不是很难，一个周末就可以了。关键是这之后你们必须建立每日建造的制度，这是一个到任何软件组织都有益的实践。而且大家会很快喜欢这个制度。根据我的实际经验，越是没有被传统软件方法污染的持续员，越是容易习惯这个做法。而越是没有去实施CMM的企业越是容易实施这个方法。
[解决办法]
前面我早就说过了， 和重构没关系， 其实就是最基本的版本控制都没搞明白。
不过在理论上我可说不出来。
还是ozzzzzz(希望敏捷)历害， 受教了。
这是一个极难得的理论联系实际的好贴子，请大家仔细读过再踊跃发言。
[解决办法]
1.将项目中功能和模块联系比较密切的代码重新组织，用OOP的思想进行类的
封装，严格控制对部分变量和函数的访问，从这些模块扩展来的函数封装在
派生类中，使用继承和多态进行类之间的访问
2.用wincvs来管理源代码时，可以使用Diff,Log,Status,Graph来很方便的
查出你所作的修改和修改的目的，但前提是程序员在提交源代码时必须添加
必要的注释和说明，程序员必须养成好的工作习惯：每天工作前从CVS仓库中
更新本地源代码，每天工作结束后将调试通过的代码check in/commit
