大型系统的挑战

系统背景：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核心类图。

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

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

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

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

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

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

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

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

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