我们不是遗留代码，我们是传奇......

在软件行业呆久了，难免会遇到一个棘手的问题：修复遗留的代码库。Michael Stahnke在他的博客中提到了一个寓言小故事，生动的描述了遗留代码的产生原因和解决办法。

在一个不起眼的小角落里，有一段默默无闻的小代码。

它厌倦了别人叫它遗留代码，它厌倦了被人们遗忘在角落。毕竟，它还在负责一段业务逻辑。然而，尽管它处理了所有的交易，提供了许多价值，还帮助了许多用户，但还是免不了被人取笑。

小代码很难过。“我是这项业务的支柱！”它大喊道，然而没有人听到它的呐喊声。人们不愿理睬它，甚至不想与它互动。小代码经常听到有人用很刺耳的绰号称呼它。就在上周，有人接到了修改小代码的命令，但是那个人的话深深地刺痛了小代码。

“我不想碰小代码。它太丑了，不符合我们目前的做法。每次我碰小代码，就会走霉运。”一位团队负责人说。

小代码伤心地坐在角落里哭泣，然而它没有眼泪。后来，小代码决心振作，它觉得自己需要品牌推广。于是，它开始与其他代码交谈。虽然，小代码和其他代码并不是好朋友，但它们似乎总是在调用它。

“你好，微服务先生，为什么大家那么喜欢你呀？”

“哦，你好，”微服务回答，一边快速地瞟了一眼小代码，显然它想尽快结束这场对话，“可能是因为我们的目标很容易定义，我有测试覆盖率，而且我很容易部署。”

“哦，”小代码说，“都有哪些人负责你的工作呀？”

“整个团队。他们负责编写、重构，并将我部署到Kubernetes上，然后更新并自动扩展规模。”

“哇，听起来很有趣。什么是kubernetes？”小代码说，“你合适生产吗？”

“生产？”微服务回答道，“那是什么？”

“哦，不。”小代码回答道。

它意识到它正在与“最好的”代码交谈——这些代码在技术上是完美的，但对用户没有帮助性。我们的小代码获得了很多诸如此类的反馈。很多新系统都有新想法，但是小代码的职责是运行业务，过去是，现在是，而且将来也是。

在遭到一系列的碰壁后，小代码想了各种办法，并试图与另一个代码库交互。

“你好。你知道为什么人们不喜欢我吗？”

这个代码库体型庞大，而且好多天都没有刮胡子了。它看起来有点狼狈，但总得来说，它看上去很有智慧。

狼狈的代码淡淡地说：“当然没人喜欢你了，因为你是遗留代码。”

“没有必要当面给我难堪吧。”小代码说。

“不，不。遗留代码的意思是说，你负责运行业务。你有巨大的影响力。你承担着各种职责……但也意味着，与你愉快地合作的时光也已经随着那些伟大的人一起远去了。人们采用了新的模式、实践和工具。现在我的处境也是同样。”

“是吗？”小代码有点伤心地问。

“当然，遗留代码从不是贬义词。遗留代码意味着这些代码长期有效，它们辛勤地工作了很长时间，而且在经历了大风大浪以后依然幸存了下来。像你和我这样的代码的职责是运行业务，我们不断坚持完成任务。领导都想要成为历史传奇，代码库也一样。”

“但是，那些微服务总是在谈论每个人都喜欢它们。它们说我是一枚数字弃子。”

“它们这么说只是因为嫉妒你。这些服务中有多少能见光的？没有你或我，有多少人能够真正完成自己的工作？当然，这本来是他们的本职工作，但通常人们都无法正确地抽象代码。这些服务最终都会成为调用我们的接口。虽然我们是遗留代码，但是没关系，因为我们提供了价值。其他代码库希望发生交易、延迟，但我们拥有健康。”

“那么，为什么没有专门的团队管理我们？”

“人们喜欢重新组织他们的工程团队。他们会分领域、微服务或子系统。很多时候，在人们的组织结构分裂之前，我们就已经存在了。我们永远在默默无闻的小角落，被人遗忘。但也有一些细心的人会看到我们，无论他们在哪个队伍。”这个很聪明的代码说。

“嗯。因为我们工作得很好，所以人们忙于处理其他事情，才把我们忘了，是吗？”

“也不能这么说。人们知道我们的存在。他们知道我们做出的贡献。他们只是想以更新的方式工作。有时他们会投资新技术和工具。我常常在想，究竟哪些产品会投入生产。记住，生产才是我们展示自我价值的地方。”

“我一直都在生产中……”小代码欣喜地说，“谢谢你。”

“不客气。”

小代码突然停下来转身微笑着说：

“我们不是遗留代码……我们是传奇。”“这就是我们的精神。我们提供价值，也不枉我们来这世上走一遭。我们为此感到自豪。”

以上是一个虚构小故事，但这个故事说明的问题非常真实。请注意，下面来让我们看看为何软件失去了管理员。

由于缺乏软件所有权而导致的问题

每当代码库的一部分没有明确的所有者时，您就会遇到问题。它现在可能不是问题，但事情开始崩溃只是时间问题。

有一些指标可能会导致您的所有权问题：

l  系统中是否有组件无人接触？

l  代码库中是否存在大多数新员工甚至没有被引入的地方？

l  代码或系统中是否存在需要英雄的部分以及来自伟大旧部落的部落知识？

如果这些听起来很熟悉，那么你很可能遇到了一些遗留问题...呃......传奇的代码。

如果代码被发送，那么一旦它被交付，它就是“别人的问题”，它不是所有权; 它更像租约到期的租赁。一旦发布了功能，子系统或应用程序，谁维护它？一个运营团队，或其他不太幸运的团队，在事情向他们推进的结构中，可能不是最好的维护代码库，他们几乎没有领域知识，并优先考虑维护与基础设施的稳定性，升级和改进。

为什么不清楚所有权？

一个软件的所有权是模糊的或不存在的主要原因有四个：

l  编写代码的人不在了；

l  曾经有所有者，但因为团队重新组建，所有权转移或消失了；

l  旧软件已被弃用，但新软件尚未能完全取代；

l  从一开始就没有明确的所有权模式。

软件缺乏所有权不是一个简单的问题，你需要做好计划，通过团队重组、制定维护计划，在未来的道路上做好这项工作。

对于开发人员来说，“成也代码，败也代码”，你需要在急于抛弃旧代码或替换系统的功能时权衡利弊。

接手代码库的人不了解实际情况。可能两年后，这个人就会接手你的工作。你需要记录各项决策背后的原因，以及决策的内容，提交代码的时候填写良好的注释。