如何处理一些频繁使用的库的分步重构

How to handle step-by-step refactory of some heavily used libraries?

本文关键字：重构何处理处理更新时间：2023-10-16

我有几个针对多个平台的库，其中一些实时库没有或没有像样的STL支持，更不用说tr1或c++ 11了。这意味着所有东西都使用库自己的string/array/list/younameit类。现在，这些平台正在被抛弃，转而支持"纯"c++ 11和STL(我非常非常高兴:我做的最新库是第一个使用新标准的库，开发时间缩短了很多，而代码质量却提高了)。

现在我想要新的项目不依赖于自定义字符串/数组/…类，我计划一步一步地进行重构:每当我需要一些类时，创建一个副本(好吧，不是完整的副本;这仍然很痛苦，但是还有其他选择吗?)使用STL代替。在开始时，这可能意味着整个类树可能需要立即更改。与此同时，原始代码应该在未来4年左右继续工作。

实际上，我现在面临的主要问题是:我把这些新类放在哪里?例如

AA.h depends on BB.h and string.h

变成

a new A.h depending on a new B.h and <string>

我是否创建一个新类NewA并将其放入A.h中?或者在新的名称空间中创建类a并将其存储在AnewA.h中?还是新建一个像newAA.h和newBb.h这样的子目录结构?

我知道已经有几个类似的问题，有很好的答案，但我想要更多实用的建议，而不是"阅读有效地使用遗留代码"。虽然这是一个很好的答案，但我更感兴趣的是你在类似的情况下是怎么做的?

edit一些说明:

我确实使用VCS, git，并且几乎所有重要的东西都由单元测试覆盖。否则这就是疯狂了。
没有真正的团队，我只能靠自己(不幸的是，在这种事情上，我不能把我的同事算作团队成员，尽管他的年龄几乎是我的两倍，他的编程水平还不到我的一半，我甚至没有那么熟练。

不要重复类。让您的旧项目运行，并将其分叉到某个地方。当然，要使用单元测试和源代码控制。

然后，我会选择深度优先的方法，一次一点。每次更改一个类以使其适应新的编码标准，并解决由此产生的所有编译器错误。这特别意味着，对于您感兴趣的类，您首先摆脱旧的string.h，更改接口和实现(字符串/向量类彼此之间并没有那么不同)，然后构建项目。让编译器错误告诉你下一步该去哪里。

根据项目的大小，您可以从使用最少或最多的类开始。只有在所有其他类转换完成后，才能删除未使用的字符串/向量类。

这可能是一个相当简单(尽管耗时)的操作(因此不同于重构)，如果您使用一个良好的版本控制系统，具有良好的合并支持和单元测试，这可能可以由多个开发人员同时处理得很好。一定要使用单元测试和版本控制。真的。

当然，你不会让你的整个代码适应STL和c++ 0x，你应该首先争取自定义字符串/容器类，并在它们所属的地方添加智能指针。您的中期目标应该是在整个代码库中删除所有出现的delete。