Fir*_*oso 3 maintainability refactoring
我有一个项目(大约80K LOC)正在进行中,我已经有近整整一个月的豪华重构,并且在发布之前增加时间,只要我小心不要破坏任何东西.话虽如此,我该怎么做才能提高可维护性.请注意,这个项目没有进行单元测试,我并没有真正计划为此添加单元测试,但如果这是我将考虑的共同共识.
我应该寻找的关键事项是什么,并考虑修改或重构以提高软件的可维护性和质量？
编辑:我已经明确了我需要进行单元测试.这不是我真正做过的事情,对于新的单元测试开发人员来说有什么好的资源(最好是通过VS2008的单元测试框架)？
请注意,这个项目没有进行单元测试,我并没有真正计划为此添加单元测试,但如果这是我将考虑的共同共识.
坦率地说,如果您的目标是提高可维护性,则无法替代单元测试.
这将是第一步.问题是,如果没有单元测试,就无法知道在重构过程中是否"破坏"某些东西.
单元测试为您的重构提供了一层安全性.如果您无法验证您的重构是否会改变行为,那么很难让您感觉很舒服,尤其是进行大规模重构.
你可以做一些轻微的重构 - 小重命名,以提高认识,等等,但任何大规模重构,或任何设计风格的重构,以改善长期可维护性应该来设计和编写测试,可帮助您保护自己了.
要考虑的关键问题是,为什么要重构你的代码.回答这个问题,你已经有了一半的答案.
您提到希望提高可维护性,这是重构的一个非常常见的原因.鉴于这是一个目标,我将专门针对以下内容:
1)删除重复的代码.大多数程序员都试图避免这种情况,但大型项目(尤其是拥有大型团队的项目)往往会积累它.这是重构的简单目标.
2)简化你的目标.是否清楚地定义了每个函数/方法/类？你能看一下它并且非常清楚它正在做什么吗？如果没有,它是重构的一个很好的目标.很好的例子是做很多事情(或有很多副作用)的模块.考虑将它们分解为逻辑分组功能的较小模块.
3)变量/类/函数名称.他们清楚了吗？它们不一定需要很长,但它们应该使您(或任何维护代码的人)非常清楚变量的用途或功能的作用.如果有一些不清楚,请考虑重命名它们.
4)你有没有被调用的代码吗？如果您认为以后会使用它,那么值得离开.否则,对于任何维护者来说,它只是一个红色的鲱鱼.值得考虑摆脱它.
5)性能增强.您可能有也可能没有时间进行完整的算法重写(最佳性能增强).但是,现在是检查简单事物的好时机.作为C++示例,您是将类作为const引用还是按值传递？当你可以逃脱它时(前者有95%的时间),前者效率更高.
祝你的重构好运!
[编辑]另外,我在下面的每个人中都建议您在重构之前编写单元测试,以确保您的代码保持正确.