分支下如何重构

长期的项目，持续的需求，后到的需求可能需要先发布，为控制变更，项目经理选择项目分支，分支最后都合并到主干上并发布。

在一个分支上基本上没办法做重构（以前的代码质量实在不咋地），重构最后会在合并时造成很大混乱，而且你的重构，可能要求其它分支上的开发在合并的时候进行修改，项目经理和其它项目成员很难接受。

于是只有看着项目die away.

我不是很清楚所进行的分支是否具有必要的独立性，不过有几点我的想法，希望能提供些参考：
１、提高测试地位，即使做不到测试驱动，也要逐渐保证每次程序扩展／重构后都要进行回归测试，以便保证当前代码的正确性，为重构加上保险锁；
２、小步／长期重构，尽量一小步一小步的重构，步伐不要太大，且把重构作为持续的长期的过程，并加以坚持；
３、对密切分支进行合并，如果象你上面所说“重构最后会在合并时造成很大混乱，而且你的重构，可能要求其它分支上的开发在合并的时候进行修改”，那么这种分支得不偿失；
4、缩短集成周期，持续集成，以能够尽早发现集成问题，减低集成带来的风险

首先我觉得一个问题是，究竟什么情况下选择分支，什么情况下选择将项目切分开。其实这个问题也可以表示为，究竟什么时候应该将项目的一些部分抽象到——其实也就是重构到一个可以脱离项目的为其他项目也可以柔和的被接纳的公共组件。我想这个可能才是我们需要思考的解决的。

我怎么感觉你这并行开发就是一种变相的多模块开发？

并行开发的各个分支是否都是独立度很高的功能模块？如果它们之间有很高的横向关联，那么哪怕你不重构，以后合并也会痛苦异常。若否，那么只要控制好接口和耦合，各自重构应该不会对以后的合并产生根本性的灾难。

最怕的是模块之间依赖图异常复杂，那么必须先对整个依赖关系进行梳理然后再开分支，并且要严格控制分支之间的依赖关系。

用maven的multi-module来开发，对于这样的开发模式会有直观的感觉了。

当然咯，无论怎么样，自动化的单元测试是第一的必要条件，如果有一个算法比较好的合并工具，可以在以后合并的时候事半功倍。

我的观点，简言之，就是先对项目结构和模块间关系进行重构，然后才能动手在各自模块上重构。

Sorry,图省事，没说清楚

项目的分支可能是代码再也不需要合并的，可能是分支后还要合并的。为什么要合并的原因有很多，我之前经历过两个项目原因各异，比较有说服力点的是，基于商业原因，系统在两个时间点卖个两个客户（往往同时可能有更多的客户），两者都有新的需求更改（而且可能是同一个模块同一个class），基于对发布和变更的控制，采用了分支。

在开发过程中，在分支上，我曾经习惯性的做一些简单的重构，其后果首先是加大了合并的复杂度，更严重的是当其它分支再合并的时候，别人就晕菜了（如果另外一个分支也是我开发，可能稍微好一点点）。
再后来只有在不进行重构的前提下和项目经理和市场人员沟通，强烈的要求屏弃分支的开发方式。

其实合并和分支都可以看作一种形式的重构。关键问题还是在于我们如果做好这个重构。而重构是有方法的，也是有策略的。
不管如何既然是分支，则说明它们都是有共同的部分。而将这些包装起来，保证统一的接口，是一个良好的策略。而如果你发现那些非共同部分有很多部分在重复这些公共的组件，则本身就是在说明这些部分需要重构到公共组件中去。这样的工作我想只能会让你更加容易的合并，而不是相反。

分支Copy上的重构，如何能够快速、高效、自动的传播到其他的分支上？

目前看来，分支合并时遇到冲突，主要还是要看SCM工具的Diff能力大小。如果有一个智能的Diff工具，能够理解重构的语义而不是简单的字串相似匹配，那么也许还是可能的吧？貌似Martin Folwer也在找类似的工具-http://www.martinfowler.com/bliki/SemanticDiff.html

Perforce的Merge/Diff是我用过最好的工具,很多让CVS/SVN冲突的差异,它都能很好的合并.当然,merge的人一定是要对代码有所了解的,毕竟终归有conflict的时候,还是需要人脑介入的.

另外一个也许很理想化的workaround是:
分解这些业务逻辑，使用一些模式，把这些variant隐藏起来，对于使用者/调用者来说是透明的，只要通过某些开关或者配置，就能自由选择那个策略。
但是我担心：1这样做，本身是一个重构；2时间不够用；3代价太高，项目本来不堪一击禁不起这样折腾。。。