9 月 13 日,2025 Inclusion・外滩大会「开源嘉年华」正在限量报名中! 了解详情
写点什么

测试驱动开发与遗留代码的问题

  • 2009-11-21
  • 本文字数:1633 字

    阅读完需:约 5 分钟

Allan Baljeu 试图在他庞大的、C++ 遗留代码库中使用 TDD,结果遇到了很大的麻烦,因为:

我们后来得到的类不能完全实现希望其具备的功能,当有人使用这些类时,会想要得到更加完整的实现,然而却会发现原有的设计不够完善,要进行新的设计,有些期望(测试)要做出改变,而之前对这些类的使用也得调整。

他在思考前期大规模设计(BDUF)也许有助于解决这个问题。 George Dinwiddie 敏捷教练,他认为Alan 的设计是在试图告诉他些什么。人们必须要注意“干净代码(clean code)”的基本原则,要注意基本的内聚和耦合性方面的问题(比如 SOLID 原则)。

Mike “Geepaw” Hill 也是 Agile Coach ,他提到:在他指导敏捷团队的这些年来,下列原因之一可能是类似问题的根本原因:

  • 团队在重构方面做得不够,因此你的类没有做到最小化。
  • 团队在“尽量简单”方面的技能还不够,同样如此。
  • 团队还没有采取具备侵略性和快速度的微测试(microtesting,也就是 **单元测试),所以改变常常会破坏测试 **
  • 团队不知道如何处理跨团队、或是公司对公众之间的依赖,比如公布 API 的情况
  • 团队既没有结对,也没有在开放空间中工作,这极大降低了团队层面的知识理解和传递
  • 团队似乎没有具备快速构建的能力
  • 团队可能还在使用老古董级别的工具

Keith Ray 极限编程教练,他提出:有了遗留代码(也就是欠下很高技术债的系统),实现一个故事的成本完全取决于偿还技术债的成本。接下来,他提出一种解决方式:

要让代码的结构更好(偿还技术债务),不管什么时候,当你需要集成一个新功能时,你应该同时注意新旧代码中的异味,并在发现异味时,马上重构,消除异味。 你可以手工采取小而安全的步骤进行重构(即使使用 C++)。要紧跟 Martin Fowler《重构》一书中的步骤,除非你能做到得心应手。带有 gcc 的 Eclipse 有些重构功能可以使用:“抽取方法”和“重命名”。“重命名”能够知道命名所在的范围,所以要比查找和替换更为安全。“抽取方法”和其他的重构功能可能有 bug,使用它们的时候要小心。像改变函数签名这样的东西,“依靠编译器”能够展示出哪里需要改变。

你还需要测试来保证没有破坏现有功能。Michael Feather 的《修改代码的艺术》提供了很多向遗留代码中加入测试的技巧。从更高层面来看,代码异味是破坏优秀设计原则的表现。举例而言:单一职责原则(SRP)认为:每个类、方法、模块只应该有一个意图。还有些原则是与耦合、内聚和管理依赖关系相关的。相比使用这些抽象原则,发现代码异味常常更为容易。“大类”和“大方法”可以通过“抽取类”和“抽取方法 / 移动方法”修改,不过知道 SRP 有助于判断抽取类或方法的哪一部分。

也许“告知,不要询问”是最重要的设计原则:不要分离功能和数据……恶劣的代码常常把功能实现放在一个地方,从其他地方得到需要的数据,这就造成了依赖性方面的问题,同时代码缺少局部性(locality)。其症状就是:“添加一个新功能,要修改多处代码。”代码异味“散弹枪式手术”、“依恋情结”、“参数列表过长”都是这样造成的。

尽快得到反馈能带来更多重构,这最终将会加快新功能的开发。尝试进行并行构建(分布式编译),尝试让源代码文件和头文件更小,降低头文件的复杂度——可使用前向声明、避免内联代码、尝试让每个类只有一个头文件 / 源代码文件。大量使用“指向实现的指针(pimpl idiom)”能降低 10% 的编译时间,但是也可能把“大类”和“依恋情结”这样的代码异味给隐蔽起来。

重构要比重写更好,其优势在于:你总是有可工作的代码。如果你的手工和自动化测试都很好,那你就可以交付代码了,即使目前的状态处于“优秀设计”和“恶劣设计”之间。

Keith 还写了“ Refactoring: Small Steps Guaranteed to Help You Clean Up Your Code ”,该文章发表于 Better Software Magazine,讲述如何重构 C++ 代码。

InfoQ 之前的相关内容:《如何处理遗留代码》《Bob 大叔谈测试驱动开发的适用性》《如何坚持TDD:使用者出现的问题以及解决方案》

查看英文原文: Test Driven Development and the Trouble with Legacy Code

2009-11-21 05:312153
用户头像

发布了 479 篇内容, 共 176.0 次阅读, 收获喜欢 53 次。

关注

评论

发布
暂无评论
发现更多内容

推倒重来的觉悟

FunTester

单元测试 Mockito powermock spock FunTester

技术分享| Linux高并发踩过的坑及性能优化

anyRTC开发者

Linux 音视频 高并发 服务器 高并发优化

在中国如何打造一个有生命力的开源项目?

Jianmu

DevOps 持续集成 CI/CD 开源社区 持续部署

音视频学习--X264码率控制--前瞻

Fenngton

音视频 H264 视频编解码 签约计划第二季

React进阶(四):路由介绍

No Silver Bullet

React 路由 12月日更

使用 JavaScript 给微信用户发送消息

汪子熙

微信 sdk 28天写作 Web JS SDK 12月日更

龙蜥社区一周动态 | 12.06-12.10

OpenAnolis小助手

龙蜥社区

给弟弟的信第12封|阅读对一个人有多重要

大菠萝

28天写作

设计模式【6.1】-- 初探适配器模式

秦怀杂货店

Java 设计模式

今年双12,《代码随想录》冲榜TOP1

博文视点Broadview

初识腾讯移动通讯 TPNS~

阿策小和尚

28天写作 Android 小菜鸟 12月日更

大数据开发技术NN和2NN工作机制

编程江湖

大数据

JavaMoney规范(JSR 354)与对应实现解读

vivo互联网技术

Java、 API 虚拟化 虚拟货币

C++中的pimpl惯用法

行者孙

c++ 签约计划第二季 pimpl 惯用法

react源码解析9.diff算法

buchila11

React

阿里巴巴、埃森哲、德勤三方圆桌对话——《与数字化先锋共绘创新蓝图》

大咖说

阿里巴巴 大咖说 数字经济 数智化

软件开发中的字符编码问题的思考

行者孙

c++ 软件开发 签约计划第二季 字符编码

【LeetCode】保持城市天际线Java题解

Albert

算法 LeetCode 12月日更

设计模式【6.2】-- 再聊聊适配器模式

秦怀杂货店

Java 设计模式 适配器模式

Java反射机制获取运行时类的完整结构

编程江湖

JAVA开发

dart系列之:安全看我,dart中的安全特性null safety

程序那些事

flutter dart 程序那些事 12月日更 flutter 调试工具

OPPO云VPC网络实践

安第斯智能云

云计算 SDN架构 智能网卡vpc

面试官:说说react的渲染过程

全栈潇晨

React

0 基础学习 Flutter~(mini 进阶版)

阿策小和尚

Flutter 小菜 0 基础学习 Flutter 内容合集 签约计划第二季

❤️使用 HTML、CSS 和 JS 创建在线音乐播放器(免费送完整源码)❤️

海拥(haiyong.site)

响应式 大前端 28天写作 签约计划第二季 12月日更

Android 值得学【Android专题2】

坚果

28天写作 Android; 12月日更

C++如何写出异常安全的代码

行者孙

c++ 异常 错误处理 签约计划第二季

聊聊前端工程师如果做职业规划

全栈潇晨

职业规划 前端开发

react源码解析10.commit阶段

buchila11

React

Linux学习方法《Linux一学就会》:网络管理技术

侠盗安全

Linux linux运维 运维工程师 云计算架构师

Vue之全局事件总线和消息订阅与发布

编程江湖

前端开发

测试驱动开发与遗留代码的问题_研发效能_Mark Levison_InfoQ精选文章