重构:提升软件质量,单元测试:为重构提供安全保障

缘起

前面两篇博文,带大家认识了TDD和单元测试。现在来了解重构--改善既有代码的设计。
任何一个软件系统,在最初设计的时候,都很难预测到未来的变化。业务的发展随着公司的发展进行改变。为了能够使日渐复杂的系统更加灵活,简洁,易于修改。大师们引入了重构这一软件技术。重构的目的是为了保证现有模块功能不改变的前提下,使代码更加清晰,简洁,更好扩展。而为了保证重构没有破坏现有功能,需要每次重构后,跑一下单元测试,确保重构后,功能没有受到影响。

原则

既然重构是为了改善代码设计,也就意味着,要重构的代码破坏了设计原则。我们在开发过程中很难一直保证遵守设计原则,有很多原因:赶进度,我们不可避免的减少了对设计的思考,而为了更快(短期看起来快,破坏了长期利益)的完成开发任务,我们抛弃了设计原则。又或者我们很难在设计的初期预见到未来的变化,这时我们就需要重构这一法宝。
软件设计的七大原则:

  • 单一职责原则
  • 开放封闭原则
  • 里氏替换原则
  • 依赖倒置原则
  • 接口隔离原则
  • 合成/聚合复用原则
  • 迪米特法则

重构的方式

重构目的是为了使现有软件符合设计原则,在面向对象技术中,我们重构就是在类与类之间,函数之间,域之间。
主要有一下几大块(也是重构这本书的主要目录)

  • 重新组织函数
  • 在对象之间搬移特性
  • 重新组织数据
  • 简化条件表达式
  • 简化函数调用
  • 处理概括关系

单元测试在重构中的表现

为了能够确保,重构没有破坏现有的代码功能,我们需要单元测试这个护盾来确保重构没有造成破坏。
更好的做法,不是在重构之前补单元测试,而是在最初开发的使用就使用TDD,这样重构的工作量能大幅减少,毕竟单元测试的工作量也不小。

为了减少单元测试代码, 我们在开发过程中会使自己写更简洁,逻辑更加清晰的代码,例如在重构--简化条件表达式,减少开发过程中对条件表达式的单元测试用例,我们会在开发过程中就思考简化条件表达式这一重构手法。

学习了重构,那么重构最好使用在哪里呢?

就像上面说的 简化条件表达式,重构的手法,会融入我们的日常开发中,而不是积累很多的技术债务,再专门进行重构,重构应该是伴随开发过程,而不是需要团队特别为重构计划时间。

如果由于业务变化,那么现在的设计不能满足新的业务,那么此时需要进行重构,而这时的重构更多的关注的是类与类之间的关系,而不是像简化条件表达式这样的。

总之,了解学习重构,不仅仅是在系统不堪重负的时候进行重构,而是把重构加入到日常开发中。因为重构很难一蹴而就,并且今天的重构,不一定就符合日后新业务。

总之,重构,单元测试,编码技巧,设计模式,所有的所有都是为了使我们的软件更好,很多时候不要为了重构而重构,为了单元测试而单元测试,这就本末倒置了。

关注我的公众号第一时间阅读有趣的技术故事
扫码关注:
重构:提升软件质量,单元测试:为重构提供安全保障

也可以在微信搜索公众号即可关注我:codexiulian
渴望与你一起成长进步!

相关推荐