文章原文由 Martin Fowler 编写，以绞杀榕这种特殊植物的生长模式作为比喻，介绍了软件开发重构中的一种常见的工作模式，并以具体的例子说明了这种模式如何实施，及它的优点。
Martin Fowler，软件工程師，也是一個软件开发方面的著作者和国际知名演说家，专注于面向对象分析与设计，统一建模语言，领域建模，以及敏捷软件开发方法，包括极限编程。
当我和 Cindy 到澳大利亚时，我们在昆士兰海岸旁的雨林中度过了一段美好的时光。这里最奇妙的自然景象之一，就是巨大的绞杀榕。他们的种子从一棵树的枝叶上发芽，渐渐的向下生长，直到他们的根系到达底部的泥土中。经过多年的生长，他们形成了壮丽外形的同时，将他们寄生的树木绞杀。
绞杀榕就像一个隐喻，让我们联想到重写重要系统的一种方式。在我的职业生涯中，我参与到了许多关键系统的重写，你可能会认为这样的事情并不困难：开发一个新的系统，完成旧系统的工作即可。但他们总是比想起来要困难，且增加了很多无法预料的风险。当项目的截至日期迫近，项目人员的压力增大。尽管新的特性（总是会有新特性）被人们喜爱，但旧的功能却必须被保留，甚至旧的 Bug 都需要被加入重写的系统中。
另外一个替代的路线是逐渐的在老系统的边缘上创建一个新系统，让它在老系统上慢慢成长数年，直到完全的替代老系统。这听起来很难，但我逐渐认为这是一个我们还尝试得不够多的良好方案。尤其是我意识到由一些基本的方法可以让这样的工作更好开展：最基础的方法是事件拦截，它可以逐渐的将功能移动到新的 “绞杀榕”（新系统上），还可以用于启用资源捕获。
译者注： 这一段具体指通过将事件拦截将对应事件的处理交给新的系统，并通过事件拦截将旧系统的资源捕获，并逐步迁移到新系统上。具体可参考链接中的英文原文。
我的同事 Chris Stevenson 最近参与了一个项目，它使用这种方法并取得了巨大的成功。他们发表了一篇论文在 XP 2004 上，但我还希望该项目的更多方面可以被介绍出来。在他们当前的进度上，旧的应用还未被完全“绞杀”（替代），但他们已经加入了许多商业上有价值的新功能，由此带给了团队走得更远的信心。即使他们就此停止继续重构，他们在重构的投资上也有了巨大的回报：相较完全的重写所能实现的而言。
用 “绞杀榕” 模式而非完全的重写的最重要原因，是减小项目的风险。“绞杀榕”可以稳定而频繁的输出有价值的新发布，以方便开发者更仔细的监控重写的过程。许多人之所以不想考虑使用绞杀榕模式，是因为认为这样会花费更多的成本来完成重构，但我不这样认为：因为利用绞杀榕模式，你可以在更短的发布周期中，避免产生大量不需要的特性，而这却是一个完全的重写常常带来的。
在这里，还有另一个重要的思想：当设计一个新的应用时，你应当将它设计的在未来易于被 “绞杀”。我们必须面对的事实是，所有今天编写的软件，终将在未来过时。通过让我们的软件变得易于在未来添加一棵 “绞杀榕”，我们可以允许当前的工作，在未来需要被废弃之时，有一种优雅的消失方式。
