开发重构友好代码的最佳实践

时间:2009-05-13 03:33:41

标签: design-patterns refactoring resources

作为敏捷开发周期中的Java开发人员,我了解到必须确保以一种能够轻松地重构它们的方式设计我的类,而不会有太多的痛苦。我想知道,您在日常设计/开发周期中遵循的最佳实践是什么,可以帮助您轻松执行重构。
例如,我知道我应该隐藏接口背后的实现细节。因此,如果我明天更改实现,那么我不会打扰使用此API的客户端代码。同样,我应尽可能使用“工厂设计模式”,以便可以从一个工厂类控制实施类的更改,而不是找出所有地方并更改它们。 同样地,我想知道你所遵循的所有最佳实践对我有什么帮助。

6 个答案:

答案 0 :(得分:16)

使用TDD。认真。在编写课程时编写测试会强制您思考其他人如何使用它们。当你这样做时,你会倾向于写出更好的抽象。

关于这个主题的全书已经写完了:

  • 代码完成
  • 有效使用旧版代码
  • 清洁代码
  • 重构
  • 重构为模式
  • 敏捷原则,模式和实践

这些中的每一个都以自己独特的方式触及这个主题。

答案 1 :(得分:3)

你应该有一堆单元测试,可以证明每次重构时代码库都没有(无意中)受到影响。

答案 2 :(得分:2)

这可能听起来像是一个循环推理但我觉得在我的经历中是真的:

重构它很多。

这里的许多答案(特别是强大的测试套件)都是很好的建议和帮助很多,所以让我明确表示我也是那些先发制人的措施。

起初,它总是很容易改变(当它很小时)。然后,你通常需要经历一些艰难的重构才能获得突破并获得非常柔顺的东西。

答案 3 :(得分:1)

不要复制和粘贴(也称为DRY:不要重复自己)。当任何给定的功能在不超过一个地方实现时,则更容易重新实现该功能。

答案 4 :(得分:1)

我的回答是关于重构后的好结果。

方法应该......

  • 简短 - 它们永远不应该只是一个充满代码的屏幕。
  • 最多做一件事:
    • 计算值
    • 测试和分支
    • 日志
    • 守卫并抛出异常
  • 有一个退出点 - 我的推理..
    • 如果您以后需要回来并对返回值做一些事情,那么这一切都发生在一个地方。
    • 轻松设置断点并检查返回值......
    • DRY 的金额。

答案 5 :(得分:1)

如果你要做很多java,我会建议你拿两本书。

我建议Effective JavaDesign Patterns: Elements of Reusable Object-Oriented Software