如何处理一些频繁使用的库的逐步重构？
我有几个针对多个平台的库，其中一些实时库没有/没有像样的 STL 支持，更不用说 tr1 或 C++11 了。这意味着一切都使用库自己的 string/array/list/younameit 类。现在这些平台正在被放弃，取而代之的是“纯”C++11 和 STL（对此我非常非常高兴：我所做的最新库是第一个采用新标准的库，开发时间缩短了很多，而代码质量提高了）。
现在我希望新项目不依赖于自定义字符串/数组/...类，并且我计划进行逐步重构：每当我需要某个类时，创建一个副本（当然不是完整的）重复；仍然很痛苦，但是还有其他选择吗？）使用 STL 代替。一开始，这可能意味着整个类树可能需要立即更改。同时，原始代码应该在接下来的 4 年左右的时间内继续工作。
实际上我现在面临的主要问题是：我应该把这些新类放在哪里？例如
A\A.h depends on B\B.h and string.h
应该变成
a new A.h depending on a new B.h and <string>
Do I make a new class NewA and put in Ah?或者在新的命名空间中创建一个类 A 并将其存储在 A\newA.h 中？或者我是否创建一个全新的子目录结构，例如 new\A\Ah 和 new\B\bh？
我知道已经有几个类似的问题，并且有很好的答案，但我想要一些更实用的建议，而不是“阅读有效使用遗留代码”。尽管这是一个很好的答案，但我更感兴趣的是您在类似情况下实际上做了什么？
编辑一些澄清：
- 大多数当前应用程序也将及时移植为使用STL，因为它们都将在新平台上运行（仍然对RTX或InTime有疑问，但其中之一）。
- 我确实使用 VCS、git，几乎所有重要的东西都由单元测试涵盖。否则这将是疯狂的。
- 没有真正的团队，我只能靠自己（不幸的是，当涉及到这样的事情时，我不能将我的同事算作团队成员，尽管他的年龄几乎是我的两倍，他的编程水平还不到我的一半，而我甚至没有那么熟练。
I have a couple of libraries that were targetting multiple platforms, of which some realtime ones that did/do not have decent STL support, let alone tr1 or C++11. This means everything uses the library's own string/array/list/younameit classes. Now these platforms are getting abandoned in favour of 'pure' C++11 and STL (which I am very very glad for: the latest lib I did is the first one with the new standard and development time has shortened a lot, while code quality went up).
Now I want new projects to not depend on the custom string/array/... classes, and I'm planning to go for a step-by-step refactory: whenever I need some class, create a duplicate (well not a complete duplicate; still that hurts, but is there another option?) that uses STL instead. In the beginning that might mean a whole tree of classes might need changing at once. At the same time the original code should keep working for the next 4 years or so.
Practically the main question I'm facing now is: where do I put these new classes? For example
A\A.h depends on B\B.h and string.h
should become
a new A.h depending on a new B.h and <string>
Do I make a new class NewA and put in in A.h? Or make a class A in a new namespace and store it in A\newA.h? Or do I make a whole new subdirectory structure like new\A\A.h and new\B\b.h?
I know there are already a couple of similar questions, with great answers, but I'd like some more practical advice, not "read Working Effectively with Legacy Code". Though that is, with reason, a good answer, I'm more interested in what you practically did in a similar situation?
edit some clarification:
- The majority of the current applications will also be ported to use STL in time as they will all run on the new platform (still in doubt about RTX or InTime, but one of those).
- I do use a VCS, git, and pretty much everything that matters is covered by unit tests. Else this would be madness.
- There's no real team and I'm on my own (unfortunately I cannot count my collegue as a team member when it comes to things like this, though being almost twice my age his programming level is less then half of mine, and I'm not even that skilled.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不要重复上课。让你的旧项目运行，并在某个地方分叉它。当然，使用单元测试和源代码控制。
然后，我会采用深度优先的方法，一次一点。一次更改一个类，使其适应新的编码标准，并解决由此产生的所有编译器错误。这特别意味着对于您感兴趣的类，您首先要摆脱旧的
string.h，更改接口和实现（字符串/向量类彼此之间没有太大区别） ），然后您构建项目。让编译器错误告诉您下一步该去哪里。根据项目的规模，您可以从最少或最常用的类开始。仅在所有其他类都已转换后才删除未使用的字符串/向量类。
这可能是一个非常简单（尽管很耗时）的操作（因此与重构不同），并且如果您使用具有良好合并支持和单元测试的良好版本控制系统，那么多个开发人员一次可以很好地处理这个问题。一定要使用单元测试和版本控制。确实如此。
当然，您不会将整个代码改编为 STL 和 C++0x，您应该首先努力实现自定义字符串/容器类，并在它们所属的位置添加智能指针。您的中期目标应该是删除整个代码库中出现的所有
delete内容。Don't duplicate classes. Let your old project run, and fork it somewhere. Of course, use unit testing and source control.
Then, I'd go for a depth-first approach, a bit at a time. Change one class at a time to adapt it to the new coding standards, and solve all compiler errors that result. This means in particular that for the class you are interested in, you first get rid of the old
string.h, you change the interface and implementation (string/vector classes aren't that different from one another), and you build the project. Let compiler errors tell you where to go next.Depending on the size of the project, you can begin with the least or most used class. Remove unused string/vector classes only after all the other classes have been converted.
This is likely to be a quite easy (albeit time consuming) operation (hence different from refactoring) and this can probably be handled quite well by multiple developers at a time, if you use a good version control system with good merge support and unit testing. Do use unit testing and version control. Really do.
Of course, you won't adapt your entire code to STL and C++0x, and you should strive first for the custom string/container classes, and add smart pointers where they belong. Your mid-term goal should be to remove every occurrence of
deletein your whole code base.