与旧版代码配合使用

最终，构建软件是一个创建，维护和分解想法的周期。 我们经常关注此等式的创建部分。 那是因为它令人兴奋，有趣，并且充满了新的曲折。 从无到有，创造事物本质上是美好的。 然而，所有新事物最终都会变得越来越老，直到它消失。

在新应用程序和分解应用程序的想法之间的某个地方存在着我们通常称为传统的代码库。 当我们称某种东西为遗产时，它要么具有骄傲的含义，要么具有更多的负担。 遗留代码库通常是我们在“致力于开发新颖而令人兴奋的产品”的承诺之后发现的。 我们常常必须提取和改善过去的美好时光，才能迈向我们所期待的令人兴奋的未来。

我敢说，没有一家成熟公司的工程路线图不会以某种方式考虑到旧代码。 原有的代码库可能是即将淘汰的产品。 也许是用您最喜欢的框架的一个版本编写的，但是您已经有四年多没有更新了。 传统代码库总是会以某种形式出现。

考虑到这一点，我想提供一些有用的见解和策略来处理遗留代码库。 这些想法不仅涉及容忍遗留代码，而且在使用遗留代码时蓬勃发展。 能够有效地使用遗留代码库是一项至关重要的工程技能，它将使任何工程师在整个职业生涯中都受益。 前面没有灵丹妙药，但我希望它们可以帮助使用旧版代码提高生产力。

投诉，移情，文档和测试

我们在处理遗留代码方面取得的成功很大程度上取决于我们的态度。 提到态度是处理代码的主要因素似乎有点奇怪，但这是我策略的基石。

使用旧版代码时，我们要么做两件事：

• 抱怨
• 移情

当我们选择抱怨时，我们常常认为作者是不明智和不熟练的。 这是我们在处理我们还不太了解的事情时感到沮丧的结果。

同理心则走了另一条路。 虽然我们当然想找到代码库中的弱点和问题，但我们也想了解什么使它变得更好以及如何利用这些决策。

如果我们从“一切都不对劲”的角度来解决这个问题，那么我们肯定会比原作者犯更多的错误。

我们如何理解代码？

每个人都有他们理解代码库背后的设计故事的方式。 但是，我发现文档和测试是我们必须更好地理解代码的两个最强大的工具。 我还发现许多遗留代码库都缺少这些因素之一或全部。

在代码库内部或外部进行文档记录，可确保以前的经验对以后的工作有所帮助。 如果没有太多指导可言，请确保下一个必须处理此代码库的人员对其目的的理解要比您当前的要好。

有效地使用遗留代码意味着打破错误信息和对您所继承的理解不足的周期。 我发现，如果客户流失量很大并且易于使用，我不太可能将其称为“旧版”。

测试可能会更加困难。 如果有现有测试，我喜欢用它们来验证代码周围的文档。 如果没有测试，我们可以编写新的测试来验证我们编写的文档是否正确。 我们还可以使用现有文档来帮助我们更好地了解应该测试的案例。

通过文档和测试，我们应该对一些代码的功能有一定的了解，并确信我们要测试的用例正在通过。 即使您的代码库已经有文档和测试，也可以考虑对其进行扩展或通过编写更新的测试来对其进行验证。

我们将始终需要一种有意义的方式来交流代码的工作方式，因此，我们可以在这些元素上进行改进的任何方式都绝不是一项坏投资。

保持设计模式一致

一旦对文档和测试充满信心，我们就需要继续进行对旧代码库的有意义的更改。 我这样做的最大鼓励之一就是在可能的情况下保持设计模式的一致性。

并非所有设计模式都像其他设计模式一样有效。 可能有这样的情况：你能确定这是更好的方式比任何应用程序已经优化。 如果选择继续并用此新设计模式替换一段代码，请确保也更改其他实例。

尽管我们的优化可能使代码库更高效，但也使代码更加不一致和混乱。 我可以从经验中告诉您，没有什么比处理具有众多随机设计模式的遗留代码库更糟糕的了。

所有这些的重点是我们需要了解代码库试图讲述的消息和故事。 我们都是写人类解决方案的人。 我们的方法肯定会有错误，特权和怪癖。

最好的算法几乎没有改变

我记得几年前听过Micheal Feathers关于遗留代码的演讲。 在演讲视频中，他显示了一段代码，并问：“您会改变什么？ 它出什么问题了？” 整个诡辩是，Micheal向我们展示了一段已经生产十二年的代码，几乎没有错误。 该代码可疑是正常的，因此我们认为需要对其进行一些更改。

我们经常使用遗留代码做的最大的事情之一就是始终认为我们需要完全更改它。 这就是为什么我提到的同理心和理解如此重要的原因。

我们必须接受，我们可能不是遇到此代码的最佳人选或团队。 仅当我们了解它的来源时，我们才会做得更好。 但是，有时我们可以用一段代码来做的最好的事情就是不去理会代码或只做很少的更改。

此外，从许多方面来看，旧版代码库都类似于硬化粘土。 借助水，热量和足够的成型，我们可以帮助将其成型为其他形状。 但是，进行更改要困难得多，并且更改将极大地影响人们的查看或体验方式。 由于我们经常不构建任何或全部代码库，因此我们永远无法完全了解更改或修正的后果。 这使得重构遗留代码比正常情况更加危险。

重构是绝对必要的。 但是，我们应该格外小心，因为我们的新版本和采用的算法可能缺少其祖先的强大支持。

向前进

用同情接近通过记录，测试，并学习遗留代码库的历史将有助于我们了解到底我们应该做的是什么遗留代码库。 某些算法最好保持不变。 其他需要更改，但需要属于应用程序的相同一致设计模式。

通过对遗留代码库进行更清晰，一致的改进，我们可以比发现的更好。 也许有一天，我们会发现其他人在其中工作感到非常高兴！

翻译自: https://www.javacodegeeks.com/2018/06/working-well-legacy-code.html