大型系统的挑战

系统背景：1.c++100~150万行源代码。CS体系结构。CAE,CAM类型的桌面程序。
               2.历时4年×20人开发周期。
               3.产品开发，距发布还有1年。

重构背景：
当我负责重构整个系统的几何算法库的时候，发现我们系统里有一个用来表示几何二维点Point2d的类，用来表示Point2d几何相关的逻辑。单纯几何逻辑不应该包括下面代码的name, attributes，2D几何点不应该包括z.
class Point2d
{
public double x;
public double y;
public double z;
public String name;
public Map<String, String> attributes;
}

随着时间的推移，越多的属性被添加进去，很明显点这个类承担了过多的职责。这个类被大量使用。在不同语境下有不同的物理含义，比如"标注点", 三维点，等等。
重构过程我认为是异常复杂的。
方案一：
将Point2d换个名字，用来表示混乱逻辑的2D点。新建一个纯几何意义的2D点。新的代码尽量使用新的数据结构。这样做的好处是隔离了系统继续耦合的趋势。但是，这种做法多了，会对系统的可理解性造成致命伤害。想象一下，你想用一个几何点的时候，你有多个选择是多么恐怖的场景。实际上，我们系统已经有了不同的三套几何算法库了，相当混乱。
方案二：
其实我是没有其他方案了，也许你会说分别修改所有引用点，根据使用，建立新的点类，最终去掉原有Point2d类多余的属性和职责。但是系统是巨大的(100~150万行)，引用的地方怎样使用我单独去看，是看不明白的。另外，没有单元测试可以保证我的修改是正确的。先写所有单元测试也不是现实的，当然，我不太期望我重构时系统不会引入我误操作的Bug。

我想这个问题的解决方案应该不仅是技术上的，还应该从时间安排，重构的过程控制，团队的分工来思考。各位大虾，来点头脑风暴，发表自己的高见吧。

P.S.
1.上面代码为伪代码，实际系统是c++组成的。
2.将把您的建议实施，并反馈重构过程和结果。
重构进度
1.2011-01-11
过程：对name, attributes, z添加get,set函数。用时4个小时。
问题：由于系统重构中，原有功能有些不能用，所以部分人没有更新代码，他们新添加的代码有可能出错。
2.2011-01-12
过程：今天大家都提到了提取出纯几何意义的父类。其实这个想法和我的方案一应该是一个意思。弊端上面也描述了。
今天我打算先去掉一两个和三维点有关的函数，将其引用处改为三维点。

附上我们几何库的2D核心类图。

评论

13 楼 piao_bo_yi 2011-01-11  

truekbcl 写道

piao_bo_yi 写道

truekbcl 写道

这样的代码重构，template是不二的选择。

这个貌似和template没什么关系吧...

我的意思：采用template比oo的弹性大得多，你如果重构，可以考虑用template来做。

弹性大归大，但是修改量是相当恐怖的。其实我的向量类Vector<Real>是用模板做的，但后来发现其实没有必要。
1.我不需要提供不同的精度。double即满足我们的精度需求。
2.我不需要提供不同的坐标系。我们都是以直角坐标系建模，极坐标系等不用考虑。

12 楼 gigix 2011-01-11  

thinkx 写道

把point2d换个名字不是太复杂的事情，因为编译器会替你检测所有的错误，你只要保证换名称后能编译通过即可；麻烦的是这20个人都得负责改这个名称。

Command+Shift+R, problem solved
要学科学用科学

11 楼 thinkx 2011-01-11  

把point2d换个名字不是太复杂的事情，因为编译器会替你检测所有的错误，你只要保证换名称后能编译通过即可；麻烦的是这20个人都得负责改这个名称。

10 楼 truekbcl 2011-01-11  

piao_bo_yi 写道

truekbcl 写道

这样的代码重构，template是不二的选择。

这个貌似和template没什么关系吧...

我的意思：采用template比oo的弹性大得多，你如果重构，可以考虑用template来做。

9 楼 piao_bo_yi 2011-01-11  

truekbcl 写道

这样的代码重构，template是不二的选择。

这个貌似和template没什么关系吧...

8 楼 truekbcl 2011-01-11  

这样的代码重构，template是不二的选择。

7 楼 piao_bo_yi 2011-01-11  

抛出异常的爱 写道

如果你需要一个可以看的懂的类......
可以先构建多个父类
把非一个逻辑的东西移到父类
之后用一个空的基类来实现此bean

我这次重构主要是想将其中的几何逻辑和物理逻辑（名字等）分开。

6 楼 抛出异常的爱 2011-01-11  

如果你需要一个可以看的懂的类......
可以先构建多个父类
把非一个逻辑的东西移到父类
之后用一个空的基类来实现此bean

5 楼 苍山洱海 2011-01-11  

piao_bo_yi 写道

苍山洱海 写道

前提说的太少，没听明白整个环境，需求，以及出现了什么问题需要重构。。

职责太多，导致函数写起来很麻烦，而且也不易理解。

一轮一轮的重构是必须要做的，不然后期的代码没人愿意去看的。

4 楼 piao_bo_yi 2011-01-10  

jyslb 写道

既然是项目，请问你们项目计划里面有这样重构的时间表么？这样的一个重构可能需要QA一轮full regression testing，你们QA的测试计划里面包含了这样一个测试计划么？既然是项目，又不是产品开发，按照你的项目计划来，你的目标就只有项目目标。

我们虽然有测试部，但他们都是做黑盒测试的，别人是指望不上的。

3 楼 jyslb 2011-01-10  

既然是项目，请问你们项目计划里面有这样重构的时间表么？这样的一个重构可能需要QA一轮full regression testing，你们QA的测试计划里面包含了这样一个测试计划么？既然是项目，又不是产品开发，按照你的项目计划来，你的目标就只有项目目标。

2 楼 piao_bo_yi 2011-01-09  

苍山洱海 写道

前提说的太少，没听明白整个环境，需求，以及出现了什么问题需要重构。。

职责太多，导致函数写起来很麻烦，而且也不易理解。

1 楼 苍山洱海 2011-01-08  

前提说的太少，没听明白整个环境，需求，以及出现了什么问题需要重构。。