Lazarus 代码

没人料到西班牙宗教裁判所。

George Neville-Neil

亲爱的 KV,

我被要求调查一下是否有可能采用一个有15年历史的开源软件，并更新它以在我公司目前使用的系统上工作。代码本身看起来还不错，至少不比我通常阅读的代码更糟糕，但我怀疑从头开始编写一个新版本可能比尝试理解我没有编写且多年来无人积极维护的代码更容易。我应该在什么时候决定忽略这段旧代码并编写一些新的东西呢？

Lazarus

亲爱的 Lazarus,

啊，是的，GitHub，或者还是 SourceForge，旧代码在那里走向消亡，但从未完全消失。现在在线上废弃的软件项目可能比实际使用的项目还要多。廉价存储带来的问题之一是，软件工程师（其中许多人私下里也是数据囤积者）永远不需要删除任何东西。历史现在将永远不会被遗忘，更可惜的是。

是否要复活一个软件取决于许多变量，包括你需要代码的时间有多快，代码本身过去的工作情况如何，以及你打算使用的代码有多容易理解。我不会讨论时间问题，因为我们知道每个人都急需它，而且与管理层争论编写新代码会比重用现有代码更快是一场必败的战斗，一场会导致你参加会议，在会上你陈述你的名字以及自从你开始任何项目以来一直滥用的药物。

从技术角度来看，你有一些很好的工具可以告诉你复活一段代码有多难，第一个就是你的编译器。尝试使用所有警告和错误都设置为最严格级别来构建代码。如果代码在这些严格条件下构建没有问题，那么有两种情况是真的。首先，代码可能是由真正了解自己在做什么的人编写的，并且非常小心地确保他们的代码不仅遵守当前的语言标准，而且还使用了足够窄的语言子集，以至于语言的变化不会引起任何问题。第二种可能性是你的编译器坏了。一个有 15 年历史的代码在较新的编译器下完全编译而没有警告实际上是相当罕见的。生成的警告和错误的数量将初步指示你面临多少工作。

系统是否有一组为其编写并检入存储库的测试？如果有，你就很幸运，你应该立即出去买本地彩票。在过去几十年的软件开发中，已经有很多关于测试的文章，其中一些是 KV 写的，而且，有时，有人实际上为其软件构建和维护了一套好的单元测试。如果这些测试存在，你应该首先阅读它们，因为测试代码通常比实际代码中的注释更深入地了解系统应该做什么。

你说代码存储在一个在线存储库中。如果你已经通过了以上两个建议，那么你应该阅读包含主要数据结构的文件的提交日志。如果你找不到一组包含数据结构的简单文件，那么可能就该重新开始了。好的提交日志可以告诉你很多关于程序员在开发代码时的想法。由于数据结构是所有其余代码应该流向并始终参考的核心位置，因此这些文件的日志至关重要。下面显示了一个可接受的消息示例

添加了将数据存储在离线文件中的能力。在头数据结构中包含了文件名和文件描述符。如果未作为参数或在用户配置文件中提供文件名，则文件名由 tmpfile() API 自动生成。

包含诸如“修复错误”之类的简短行的提交日志是一个警告，要远离。很少看到这种情况是可以的，但我期望看到更具描述性的内容，例如错误编号或指向错误跟踪数据库的链接，以及对问题是什么以及修复程序如何解决它的完整描述。

许多较旧的软件依赖于旧版本的操作系统和库 API。这不是重写代码的理由，因为许多这些更改本质上是机械的。如何解决库 API 中的更改是程序员的判断，但除非库或 API 本身根本不再存在，否则这些更改绝不应成为放弃软件的理由。

我希望这是不言而喻的，但我已经习惯于不得不说这些事情，所以我在这里说一下。在你对系统进行任何更改之前，请务必制作存储库的副本，并在开始工作之前将存储库导入到新的存储库中。在你的源代码控制系统中使用标签或类似的构造来指示旧代码停止的位置以及你的任何更改可能开始的位置。否则，你将处于无法向下一个必须维护它的人解释代码来源的令人羡慕的境地。

亲爱的 KV,

我已经在一家中型软件公司工作了几年，最近“晋升”为软件架构师。这似乎意味着我做了所有我过去做过的编码工作，但还必须向我团队中的其他人解释要编码什么。上个月，管理层要求我查看一家潜在收购公司的软件，并就我们是否应该根据他们已经编写的软件收购该公司向他们提供建议。这似乎是一个简单的代码审查案例，但它是吗？

求购者

亲爱的求购者,

首先要做的是与该公司的工程师成为好朋友，因为你的公司即将让他们致富，然后他们都会辞职，而你将不得不维护他们的代码，而没有奖金或股票支付的好处。而且，以我的经验，无论你说什么，管理层都会做他们想做的事情，但作为一名工程师，你必须尽力而为。所以，看看我是否能想出一个更有用的答案。

你是对的，你被要求做的事情实际上是一个代码审查，但它附加了很多条件，而且它也是在与你公司内部可能进行的代码审查非常不同的情况下完成的。将此代码审查更多地视为法律取证。我被告知，法律取证不像那些有趣的法庭剧，在法庭剧中，两位律师会问礼貌的问题，试图欺骗被审查的人泄露信息，以表明他们有罪。它更像是一场宗教裁判，多位律师可以随意提出任何问题，并使用他们喜欢的任何语气。在这种情况下，你应该像那些律师中的一位一样行事。你的工作是从收购目标公司的工程师那里获取尽可能多的信息，因为在三个月后，你将维护他们的代码。不要让他们用一个大的代码 zip 文件来搪塞你。确保你不仅获得代码，而且获得对其工具、存储库和工程师时间的访问权限。让他们中的一人或多人与你一起坐在房间里，尽可能长的时间，详细了解系统是什么，它应该如何工作，以及这在代码中发生在什么地方。

还要安排几次与工程团队的下班后聚餐，并获得批准购买你认为你需要让他们告诉你代码中真正埋藏的秘密的酒水。最后这个建议不是开玩笑，它是非常认真的。如果你想从工程师那里获取信息，就喂饱他们并让他们喝醉。带上至少一位你公司信任并且可以做笔记并扮演“好警察”角色的其他工程师。当你提出一个难题时，你的好警察应该缓和你所说的话，以便你正在采访的团队实际上变得愿意遵守你的要求。我曾考虑雇用一个人只是跟着我扮演“好警察”的角色，让我免于麻烦，但我认为在我职业生涯的这个阶段，随从有点为时过早。

最后，不要相信演示。演示可能会被伪造，并且将会被伪造。在向管理层提出任何严肃的建议之前，请确保你可以检查系统和代码。一旦你提出了建议，就要准备好使用该代码，因为即使你说该系统包含一个在执行时将拼写出全人类末日的函数，也可能无法阻止管理层决定这笔交易确实是一笔好交易，然后让你承担使其工作的难题。

喜欢它，讨厌它？请告诉我们

[email protected]

Kode Vicious，凡人称为 George V. Neville-Neil，为乐趣和利润而从事网络和操作系统代码的工作。他还教授各种与编程相关的课程。他的兴趣领域是代码探险、操作系统和重写你的糟糕代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位，并且是、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行者，目前居住在纽约市。

最初发表于 Queue 第13卷，第5期—
在数字图书馆中评论本文