可牺牲的架构

本文是翻译，版权归原作者所有

你坐在会议室里，凝视着你的团队在过去数年一直维护的代码。你已经做出了决定，你现在能够做的、最好的选择就是扔掉所有的代码，重建一个全新的架构。对于这些命中注定的代码、你投入其中的时间、此刻之前所做的那些决定，你该作何感想呢？

对于很多人而言，扔掉代码库是失败的象征，鉴于软件开发固有的探索性质而言是可理解的，但是，这仍然是失败。

不过，你现在能够编写的最好代码常常是你在数年之后要抛弃的代码。

我们经常把伟大的代码视作永久的软件。作为一名编辑，我写这篇文章时的身份可追溯到1980年。对于软件架构是 如何减轻某种永久 做了很多思考。然而你的成功可以建立在代码之上，因为被送到了 /dev/null。

想一下网络上最成功的大型商务网站之一的、eBay的故事。它在1995年用了一周时间，从一堆perl脚本开始。在1997年，它推翻一切，在当时的windows工具之上，用C++编写的系统取而代之。然后到了2002年，应用程序用Java重写了。早期的版本因为它们被取代了就成为了错误吗？很难这样说。eBay目前仍然是web上最伟大的一个成功，但是成功的大部分因素是建立在90年代被抛弃的那些软件上。就像很多成功的网站一样，eBay已经看到了指数级的增长，指数级的增长对于架构不是友好的。支持1996年eBay的合适架构，对于2006年eBay来说，就不是合适的了。1996年的架构无法处理2006年的负载，但是2006年的版本太过复杂而难以建立、维护，它是根据1996年的需求演化而来的。

的确，这个原则可以引出工作的一种组织方式。在Google，大家熟知的要求就是设计一个满足当前10倍需求的系统，这暗示着如果需求超过了一个数量级，那么扔掉并从头做起是更好的。每隔几年就被重新设计与抛弃的子系统而言，这是非常普遍的。

的确，我们通常可以看到，刚接手一个成熟代码库的人们诟病架构的性能和可伸缩性。但是在软件系统的早期阶段，你不一定要确保它真正需要做什么，关注灵活性以应付功能改变是十分重要的，而不是性能或可获得性。随着你的用户越来越多，你需要切换优先级了，不过让太多用户处在一个低性能的代码库，通常是优先级较高的问题，而不是优先级低。Jeff Atwood发明了一句话“性能是功能”，一些人把它理解成性能总是第一优先级。但是任何功能只是你不得不从其它功能选出的。这不是说，你应该忽视性能之类的工作——软件可以变慢、不可靠到断送一个业务——但是团队不得不与其它需求做出痛苦的抉择。通常有更多的业务决定，而不是技术上的决定。

那么这意味着要故意选择一个可牺牲的架构吗？本质上它意味着接受，因为若干年后你将（如果顺利的话）扔掉当前创建的东东。这说明了要接受你堆放在一起的、跨功能需求的限制。这也说明了现在需要考虑，当这一刻到来的时候，如何能够让其变得容易——软件设计师很少考虑如何设计他们的创造，以支持将来的优雅替换。这也意味着在相对短的时间内被扔掉的软件，仍然带来了很大的价值。

明白了你的架构是可牺牲的，不代表要放弃软件的内部质量。通常，被牺牲掉的内部质量，将比替代时间更早地伤害到你，除非你已经工作在行将退役的代码库上。良好的模块化是健康代码库的关键部分，模块化通常在替换系统时起到巨大的帮助。对于系统的早期版本，要做的最好的一项工作就是搞清楚什么是最好的模块化结构，为将来的替换做准备。虽说在早期牺牲一整个系统是合理的，但是如果具备良好的边界，随着系统的增长，牺牲单个模块是更有效率的。

处理这个问题时，容易忽略的一个方面就是结算。是的，真的如此——我们已经陷入 人们不情愿替代一个明显的、不可行的系统 的状况，因为他们正在分期偿还代码库的方式。对于大企业，这更像是一个问题，但是不要忘了，只要你生活在这个世界上，就要去检查一下。

你还可以把这个原则应用到现有系统的功能上。如果你正在开发新功能，那么只让一部分用户可见是明智的，因为你能够得到 它是不是一个好想法 的反馈。为了达到这个目的，开始的时候，你可能在以一种可牺牲的方式在开发，你不必在一个功能上投入全力，因为你可能发现它不值得全面部署。

模块可替换性对于微服务是一个主要论据，但是我谨慎推荐可牺牲的架构。微服务暗示着分布和同步，它俩都是复杂的助推器。我已经碰到过一些项目，它们在走不是真正需要的微服务道路——结果严重减缓了它们的功能管道。因此，借助后来引入的微服务，逐渐将庞然大物分解，而庞然大物经常是好的可牺牲架构。

编写可牺牲架构的团队要决定牺牲它的时机。对于接手的新团队而言，他们讨厌现有代码、想重写，这是不同的情况。如果你没有理解已编写代码的上下文，你很容易就厌恶你没有编写的代码，明白你将要编写的代码属于可牺牲的代码，将是一个有用的变数。

致谢

1. 与Randy Shoup的谈话启发了我，并帮助我构思了本文，尤其是eBay（和一些Google的类似故事）的历史描述。 Jonny Leroy指出了结算问题。Keif Morris, Jason Yip, Mahendra Kariya, Jessica Kerr, Rahul Jain, Andrew Kiellor, Fabio Pereira, Pramod Sadalage, Jen Smith, Charles Haynes, Scott Robinson and Paul Hammant 提供了有帮助的评论。

原文地址：http://martinfowler.com/bliki/SacrificialArchitecture.html

译文： 《可牺牲的架构 》| 腊八粥