重构:提升软件质量,单元测试:为重构提供安全保障
缘起
前面两篇博文,带大家认识了TDD和单元测试。现在来了解重构--改善既有代码的设计。
任何一个软件系统,在最初设计的时候,都很难预测到未来的变化。业务的发展随着公司的发展进行改变。为了能够使日渐复杂的系统更加灵活,简洁,易于修改。大师们引入了重构这一软件技术。重构的目的是为了保证现有模块功能不改变的前提下,使代码更加清晰,简洁,更好扩展。而为了保证重构没有破坏现有功能,需要每次重构后,跑一下单元测试,确保重构后,功能没有受到影响。
原则
既然重构是为了改善代码设计,也就意味着,要重构的代码破坏了设计原则。我们在开发过程中很难一直保证遵守设计原则,有很多原因:赶进度,我们不可避免的减少了对设计的思考,而为了更快(短期看起来快,破坏了长期利益)的完成开发任务,我们抛弃了设计原则。又或者我们很难在设计的初期预见到未来的变化,这时我们就需要重构这一法宝。
软件设计的七大原则:
- 单一职责原则
- 开放封闭原则
- 里氏替换原则
- 依赖倒置原则
- 接口隔离原则
- 合成/聚合复用原则
- 迪米特法则
重构的方式
重构目的是为了使现有软件符合设计原则,在面向对象技术中,我们重构就是在类与类之间,函数之间,域之间。
主要有一下几大块(也是重构这本书的主要目录)
- 重新组织函数
- 在对象之间搬移特性
- 重新组织数据
- 简化条件表达式
- 简化函数调用
- 处理概括关系
单元测试在重构中的表现
为了能够确保,重构没有破坏现有的代码功能,我们需要单元测试这个护盾来确保重构没有造成破坏。
更好的做法,不是在重构之前补单元测试,而是在最初开发的使用就使用TDD,这样重构的工作量能大幅减少,毕竟单元测试的工作量也不小。
为了减少单元测试代码, 我们在开发过程中会使自己写更简洁,逻辑更加清晰的代码,例如在重构--简化条件表达式,减少开发过程中对条件表达式的单元测试用例,我们会在开发过程中就思考简化条件表达式这一重构手法。
学习了重构,那么重构最好使用在哪里呢?
就像上面说的 简化条件表达式,重构的手法,会融入我们的日常开发中,而不是积累很多的技术债务,再专门进行重构,重构应该是伴随开发过程,而不是需要团队特别为重构计划时间。
如果由于业务变化,那么现在的设计不能满足新的业务,那么此时需要进行重构,而这时的重构更多的关注的是类与类之间的关系,而不是像简化条件表达式这样的。
总之,了解学习重构,不仅仅是在系统不堪重负的时候进行重构,而是把重构加入到日常开发中。因为重构很难一蹴而就,并且今天的重构,不一定就符合日后新业务。
总之,重构,单元测试,编码技巧,设计模式,所有的所有都是为了使我们的软件更好,很多时候不要为了重构而重构,为了单元测试而单元测试,这就本末倒置了。
关注我的公众号第一时间阅读有趣的技术故事
扫码关注:
也可以在微信搜索公众号即可关注我:codexiulian
渴望与你一起成长进步!