代码重构之TDD的思考

需求的不断变更是重构的最根本原因,代码架构最初的设计也是经过精心的设计,具有良好架构的。但是随着时间的推移、需求的剧增,必须不断的修改原有的功能、追加新的功能,还免不了有一些缺陷需要修改。为了实现变更,不可避免的要违反最初的设计构架。经过一段时间以后,bug越来越多,越来越难维护,新的需求越来越难实现,最初的代码构架对新的需求渐渐的失去支持能力,而是成为一种制约(新需求的开发成本会超过开发一个新的软件的成本)。说白了,不管是devops还是敏捷开发,永远强调的是快速响应(产出)!只有好的设计及代码才能做到快速响应!

1. 既然重构那么重要,那究竟什么是重构呢?

重构就是通过调整程序代码,但并不改变程序的功能特征,达到改善软件的质量、性能,使程序的设计模式和架构更趋合理,更容易被理解,提高软件的扩展性和维护性。 

2. 重构的目标值?

  • 持续偏纠和改进软件设计 
  • 使代码更被其他人所理解 
  • 帮助发现隐藏的代码缺陷 
  • 从长远来看,有助于提高编程效率,增加项目进度(进度是质量的敌人,质量是进度的朋友) 

3. 怎样去重构?

代码重构的方法论,这里不做论述,有一本《重构改变既有代码的设计》非常值得一读。

4. 重构的困境,集成化测试谁来做?

重构依赖测试,依赖自动化,集成化测试。Test-Driven Development(TDD),是Extreme Programming (XP)--极限编程的一个重要组成部分。那问题来了,谁来做,怎么做?

我的结论是开发人员来做,由开发人员编写测试带来的收益,最重要的一点不在于测试本身,而在于它能促进开发、测试以及需求分析人员的交流与沟通。而测试先行的方式也能让开发者跳出实现的窠臼,而从业务角度去看待问题,从消费者角度去思考接口的设计

5. 集成化单元测试怎么做?

说实话,要做到极致(在jenkins中点发布时代码规范、单元测试、集成化测试等各项指标达标发布成功,发布失败把这些项邮件给负责人)。就但集成化测试还真有点复杂,这里分享一个我之前的一个思路

这里分享一个我之前写的mock-plugin-maven ,这里再拓展一下,要实现集成化测试,其实BDD(行为驱动开发)是个不错的方案。

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值