当重构项目以提高可维护性时，需要瞄准哪些目标？
我正在处理一个项目（大约 80K LOC），并且在发布之前我有近一个月的豪华重构和功能添加时间，只要我小心不要破坏任何东西。话虽如此，我可以做些什么来提高可维护性。请注意，这个项目没有进行单元测试，我也没有真正计划为此添加单元测试，但是如果这是普遍共识，我会考虑它。
我应该寻找并考虑修改或重构以提高软件可维护性和质量的关键事项是什么？
编辑：我已经明确表示我需要单元测试。这不是我真正做过的事情，对于刚接触单元测试的开发人员来说，有哪些好的资源（最好通过 VS2008 的单元测试框架）？
I've got a project (about 80K LOC) that I'm working on, and I've got nearly a full month of luxury refactoring and feature adding time prior to release so long as I'm careful not to break anything. With that being said, what can I do to improve maintainability. Please not there was no unit testing in place with this project and I'm not really PLANNING to add unit tests to this, however if it is the common consensus I will take it under consideration.
What are the key things I should look for and consider revising or refactoring to improve software maintainability and quality?
Edit: It's been made clear to me I need unit testing. This is not something I've ever really done, what are some good resources for a developer new to unit testing (preferably via VS2008's unit testing framework)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
坦率地说，如果您的目标是提高可维护性，那么单元测试是无可替代的。
这是第一步。问题是，如果没有单元测试，就无法知道在重构过程中是否“破坏”了某些东西。
单元测试为重构提供了一层安全保障。如果您无法验证您的重构不会改变行为，那么很难对重构感到舒服，尤其是进行大规模重构。
您可以进行一些小的重构 - 小的重命名以提高理解等，但是任何大规模的重构或任何设计风格的重构以提高长期可维护性都应该在设计和编写帮助您保护自己的测试之后进行。
Frankly, if your goal is to improve maintainability, there is no substitution for unit testing.
This would be step one. The problem is, without unit testing, there's no way to know if you "break" something during the refactoring process.
Unit tests provides a layer of safety around your refactoring. It's difficult to feel comfortable refactoring, especially doing large-scale refactoring, if you have no way to verify that your refactoring isn't going to change behavior.
You can do some minor refactoring - small renames to improve understanding, etc, but any large-scale refactoring, or any design-style refactoring to improve long term maintainability should come after designing and writing tests that help you protect yourself.
要考虑的关键是为什么要重构代码。回答这个问题，你就已经得到了一半的答案。
您提到想要提高可维护性，这是重构的一个非常常见的原因。鉴于此作为目标，我将特别针对以下一些内容：
1）删除重复的代码。无论如何，大多数程序员都试图避免这种情况，但大型项目（尤其是大型团队的项目）无论如何都会积累它。这是重构的一个简单目标。
2）以简单为目标。每个函数/方法/类是否明确定义？你能看着它并清楚地知道它在做什么吗？如果没有，那么它就是一个很好的重构目标。很好的例子是可以做很多事情（或者有很多副作用）的模块。考虑将它们分成具有逻辑分组功能的较小模块。
3) 变量/类/函数名称。他们清楚吗？它们不一定需要很长，但它们应该让您（或维护代码的任何人）非常清楚变量的用途或函数的用途。如果有一些不清楚，请考虑重命名。
4）你是否有永远不会被调用的代码？如果您认为稍后会使用它，那么可能值得离开它。否则，这对于任何维护者来说都只是转移注意力。值得考虑摆脱它。
5) 性能增强。您可能有也可能没有时间进行完整的算法重写（最佳性能增强）。然而，这是检查简单事情的好时机。作为 C++ 示例，您是将类作为常量引用还是按值传递？当你可以逃脱惩罚时（95% 的情况下），前者的效率要高得多。
祝你重构好运！
[编辑] 另外，我向下面的每个人表示赞同，建议您在重构之前编写单元测试，以确保您的代码保持正确。
The key thing to consider is why you want to refactor your code. Answer that question, and you'll have half your answer already.
You mention wanting to improve maintainability, which is a very common reason for refactoring. Given that as a goal, here are some things that I would specifically target:
1) Remove duplicate code. Most programmers try to avoid this anyway, but large projects (especially projects with large teams) tend to accumulate it anyway. This is an easy target for refactoring.
2) Make simplicity your goal. Is each function/method/class clearly defined? Can you look at it and know very well exactly what it's doing? If not, it's a good target for a refactor. Good examples are modules that do lots of things (or have lots of side effects). Consider breaking them into smaller modules of logically grouped functionality.
3) Variable/class/function names. Are they clear? They don't necessarily need to be long, but they should make it very clear to you (or whomever is maintaining the code) exactly what the variable is for or what the function does. If there are some that are unclear, consider renaming them.
4) Do you have code that's never getting called? It could be worth leaving if you think you'll use it later. Otherwise, it's just a red herring for any maintainers. It's worth considering getting rid of it.
5) Performance enhancements. You may or may not have the time for full up algorithmic rewrites (the best performance enhancement). However, this is a good time to check for simple things. As a C++ example, are you passing classes as const references or by value? The former is much more efficient when you can get away with it (which is 95% of the time).
Good luck on your refactoring!
[Edit] Also, I second everybody below with a recommendation that you write unit tests before refactoring to ensure that your code remains correct.
我会查看关于 的维基文章此网站上的代码味道，这是一个很好的起点！
I would look at the wiki article on Code Smells on this site, its a great place to start!
拥有一个包含可靠测试的项目（单元测试，使用模拟和c运行速度极快，这样你就可以一直运行它们，并且集成测试很少运行，实际上与真实数据库交互，等等，等）是可维护性的关键：为了使项目易于维护任何目的（功能、错误消除、性能、移植等），您可以做的最重要的事情， ETC）。强大的测试套件让您对未来可能想要尝试的任何进一步特定更改的正确性充满信心，加上，代码重构为可良好测试（高度模块化、依赖注入等） ）本质上也变得更加灵活和可维护。
我强烈推荐 Feathers 的有效地处理遗留代码（这两个 PDF 我'我指着，以及同名同名作者的书），以获取关于如何在这种情况下最好地进行操作的全面且高度实用的指南。
Having a project well covered with solid tests (both unit-tests, using mocking &c to run blazingly fast so you can run them all the time, AND integration-tests to be run more rarely that actually interface with real databases, etc, etc) is the key to maintainability: the single most important thing you can do to make a project easily maintainable for whatever purpose (features, bug removal, performance, porting, etc, etc). A strong test suite gives you confidence in the correctness of any further specific change you may want to try down the road, plus, code refactored to be well-testable (highly modular, dependency injection, etc, etc) intrinsically also becomes more flexible and maintainable.
I highly recommend Feathers' Working Effectively With Legacy Code (both the PDF I'm pointing to, and the book by the same title and author) for a thorough and highly practical guide to how best to proceed in such situations.
找到未来可能发生变化的地方，并使其更加灵活。
Find places which are likely to change in future and make it more flexible maybe.