Martin Fowler 阐述“牺牲的架构”

软件开发团队希望拥有长期稳定的软件架构，但是硬件、软件和网络速度的技术却在高速发展，就这需要架构做出重的大调整，甚至抛弃之前的整个代码库。在这种背景下， Thoughtworks 的作者和顾问 Martin Fowler 在他近期的博客中介绍了牺牲的架构。

牺牲的架构意味着要接受一种现实，那就是在几年内团队将需要（希望）抛弃他们之前构建的一些东西。Martin 提到，这意味着当这一时刻到来时，要立刻思考如何让这些东西更容易被替换掉，但是软件设计人员却很少思考如何设计他们的产出物，让它们如何支持将来的替换。

对于许多人来说，抛弃代码库是一种失败的标志，或许考虑到软件开发所固有的探索特性也能够表示理解，但仍然会感到强烈的挫败感。但是，现在你抛弃几年前写的代码，通常能够写出更好的代码。

Martin 举了一个 eBay 的例子，他们的做法与牺牲的架构是一致的，他们在一段时间之后把 perl 脚本移植成了 c++ 代码，又在一段时间之后移植成了 java 代码。能够支撑 1996 年 ebay 的架构不会成为能够支撑 2006 年 ebay 的架构。1996 年的这一版不能处理 2006 年的负载压力，但是 2006 年的版本对于构建和维护来讲太复杂了，而且是针对 1996 版之后的需求逐步演变而来的。

EPAM 系统的开发人员 Dmitry Cheryasov 也支持牺牲的架构，因为这是业务转变的需要。他在 Y Combinator 的讨论中共享了他的观点，他说：

为了在合适的时机重新构建而构建。它就像抛弃原型，只是代码已经投入使用罢了。当你的业务增长的时候，你可能不得不抛弃之前的一些或者全部的代码库（就像 eBay 的做法，第二次提到了）。这并不意味着之前的解决方案不好：一点也不，在当时的情况下它们非常恰当。

谷歌的高级研究员 Jeff Dean 在他的陈述中提到，在代码库太旧之前就重新设计或者抛弃掉。

当前正确的设计对于十倍或者百倍的增长可能就是非常错误的了，可以针对十倍的增长进行设计，但在增长到百倍之前就要计划去重写了。

Martin 说，在早期的软件系统中，很少保证软件事实上需要做到什么，所以重点是更加关注特性变更的灵活性而非性能或有效性。 Stack Overflow 和 Stack Exchange Network 的联合创始人 Jeff Atwood 创造了一种新的说法“性能就是一种特性”。所以团队可以把性能特性和其他的特性一起来排序。最初它的优先级不高，但是开发阶段后期就要提高它的优先级了。

Martin 说牺牲的架构不会引起质量的缺乏。对于一个健康的代码库来说，关键是模块化。

好的模块化是一个健康代码库的关键部分，当要更换一个系统时，模块化通常能够带来巨大的帮助。最好的一种做法就是，在系统早期系统就探索最好的模块化结构应该是什么样的，以便你能够基于替换的认知去进行构建。由于在早期时它就被设计成了全部系统都是可以牺牲的，随着系统的增长要牺牲独立模块时就会更加的高效，因为如果你有良好的模块边界，就只做简单地替换就可以了。

Justin Meyer 是 jQuery 顾问和 JavaScriptMVC 、 CanJS 和 jQueryPP 的联合创始人，他在近期的博客中分享了模块化的重要性，他说：

模块化是一个可维护性应用最重要的特性。一个模块化的应用不会浪费，部件可以被修改、替换或者抛弃掉，而不会影响到应用的其他部件。

Martin 说，写牺牲的架构的团队决定了牺牲的时机，也了解代码在未来牺牲掉是一件好事。

查看英文原文： Martin Fowler Describes “Sacrificial Architecture”