BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

重建还是重构?

| 作者 Ben Linders 关注 28 他的粉丝 ,译者 覃璐 关注 0 他的粉丝 发布于 2015年12月3日. 估计阅读时间: 7 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

Agile Testing Days 2015大会上, Wouter Lagerweij谈到了如何重建一个遗留系统而不是重构它,来帮助团队采取敏捷实践,比如测试驱动开发,自动化测试,持续交付。他的谈话基于他的博客文章 Don’t Refactor. Rebuild. Kinda

InfoQ采访了 Lagerweij关于是什么让重构如此困难,重建软件的风险是否比重构小,以及持续交付如何配合软件的重建。InfoQ同时请教了他关于重建和重构的建议。

InfoQ:您能解释一下是什么使得重构这么困难吗?

Lagerweij:只要你去做,重构是一项相当简单的实践。同样的例子是单元测试。只要你坚持为代码编写测试用例,或者清理代码中的设计问题,一小步一小步的,这并不困难。

可是你越是把这些丢在一边,捡起来的时候就越困难。这就是为什么每个人都一直说“技术债务”。可是实际上它通常不是指 Ward Cunningham所创造的技术债务(参见 Ward Explains Debt Metaphor)。

软件行业并不是唯一发生这些事情的地方。只是询问一些活跃在医疗保健行业的专业医师。了解到外科医生坚持在手术前洗手能降低一半的手术并发症,但是即使有积极的宣传和结构化的清单,它依然很难被遵守。

所以,由于一些团队推迟重构,我们有一些混乱,或者说“遗留代码库”。由于这些团队几乎总是没有足够的重构经验(否则他们已经这样做了),他们无疑不能完成修复这些混乱代码的工作。

此时这些团队认识到他们应该为他们的“债务”做些事情,他们不得不接受一个系统,在其中努力学习用以提升自己系统的技能!当小的改动在系统的不同部位导致不可预知的结果时,是对重构中积极的学习经历不利的。而且任何开发人员都知道为封闭的,紧耦合的系统添加单元测试是一个困难和不愉快的经历。

我想我要说的是,如果你等到遇到这些麻烦才开始学习这些技能,很可能你将不会成功的应用它们。也就是说,在掌握它们之前,你更可能会先放弃它们。

InfoQ:在您看来重建软件比重构的风险更小?您能解释一下吗?

Lagerweij:说实话,如果你的团队成员知道如何去改进一个遗留系统,重构始终是更好的选择。它的风险更小,并且比任何类型的重写的开销要少。

但是不幸的是这些技能仍然非常稀少。如果团队中的成员之前没有做过这类工作,之后你的所有工作都会慢于预期。你会在开发团队和公司中增加挫败感。

有一些组织发现自己陷入了困境。他们简直没有专业人员来解决他们的技术问题。他们不能构造有竞争力的新功能。甚至找到几个有经验的人也很难,常常是“太小,太迟”的情况。

这种情况下重写是更有吸引力的。

InfoQ:您能给出一些例子来展示团队如何来重建软件以及做持续交付吗?是什么让它们成为一个好的组合?

Lagerweij:重写的一个好处是你能重新开始。这意味着这次你能确保你这样做是正确的。当然,大多数时候,你不能。就像我之前说的,处理这些事情最好的方式,例如测试和重构,就是持续不断的做。但是如果你之前从来没有做好过,它怎么会突然就能工作?

我在谈话中说过的,我们已经在我当前工作的团队试过。我们使用测试驱动开发(也叫做行为驱动开发),我们会保持代码的整洁,确保始终有100%的单元测试覆盖率。他们不再害怕他们的遗留系统,他们知道他们能够做到这一点。

我们也同意,确保我们不会受到放松控制的诱惑,我们从第一天起就做到完全的持续部署。这意味着开发者每次推送代码到 GitHub中时,它会自动构建,测试并部署一直到生产。这使得我们任何时候都能极好的关注在保持高质量上。你不能推迟那些测试,因为推送未测试的代码会破坏构建,使得整个团队等着你。但是你也不想跳过测试(或者写一个未检查的单元测试只是为了糊弄覆盖率),因为你实际上可能破坏生产。你自己,很明显。

还有一些简单的心理作用,没有人真正关心什么让测试覆盖率从2.1%到2.0%,但是当它从100%掉到99.9%时,整个团队会要求一个解释。

你仍然需要经历一个学习过程。重新开始并不会让你突然做的更好。它只是创造一个更大成功率的机会。

InfoQ:对于正在考虑用重建软件代替重构的团队,您有什么建议?

Lagerweij:首先,在发布之前不要尝试和重建任何东西。找到一种方式将新系统和老系统融合,并尽快为你的新系统的用户提供价值。有些东西比如 strangler pattern branch by abstractio能帮助你。如果你不这样做,你的项目要么在某个时候被取消,要么永远继续下去,但无疑不会有好的结果。

其次,停止糊弄自己。使用一个严格要求规定的工具,比如持续部署,会感觉在项目的表明需求上增加了额外的负担,但是这个规定会帮助你避免陷入和之前同样的陷阱,写出一个完全的新的遗留系统。它会促使你学习新技能,例如持续重构,如何测试驱动你的代码,有多少种不同类型的测试需要被掌握,如何自动化部署,如何处理监控和错误处理。所有的这些都是和到生产的途径变得短和直接紧密相关的。

最后,可能是最重要的,涉及到客户!尽管比通常的要多,重写的诱惑是得到“和老系统做同样的事”的响应,而不是因为客户交流有任何进一步的需要。但是我们需要知道客户现在需要什么。我们也需要知道他不再需要什么。我们都熟悉80/20法则关于被使用的功能。你看,重构不仅仅只是发生在代码层面,审查你的需求,业务流程甚至是商业模式都是同样的重要。

当然,它仍然会有大量的工作要做,但是如果你坚持这些原则,一旦你做到了,你会得到干净的代码,一个学习型团队,和高兴的客户。

查看英文原文:Rebuild or Refactor?


感谢张龙对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入InfoQ读者交流群InfoQ好读者(已满),InfoQ读者交流群(#2)InfoQ好读者)。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

说明关键还是人 by X Ray

关键还是人,否则还是重复“写出一个完全的新的遗留系统”

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT