ACM通信
Kode恶性
拉撒路的代码
信贷:Julenochek
亲爱的KV,
有人要求我研究一下使用一个已有15年历史的开源软件的可能性，并将其更新到我公司使用的当前系统上。代码本身似乎并不是很糟糕，至少不会比我习惯阅读的代码更糟糕，但我怀疑从头开始编写一个新版本可能比尝试理解我没有写过的代码更容易，这些代码已经好几年没有人积极维护了。在什么情况下，我应该决定忽略旧的代码而编写新的代码?
拉撒路
亲爱的拉撒路,
啊，是的，GitHubor是一个源代码遗忘的地方，旧的代码会消失，但从来没有完全消失。现在网上被抛弃的软件项目可能比实际使用的项目还要多。使用廉价存储的一个问题是，软件工程师从来不需要删除任何东西，他们中的许多人也不是秘密的数据储存者。历史永远不会被遗忘;更遗憾的是。
是否恢复一段软件取决于许多变量，包括您需要代码的时间有多快，代码本身在过去的工作情况如何，以及在头脑中消化您打算使用的内容有多容易。我不讨论时间问题，因为我们知道每个人都需要昨天的东西，而与管理层争论写新代码将比重用现有代码更快是一场必败之战，这将导致你在会议上陈述自己的名字和自开始任何项目以来一直滥用的内容。
从技术角度来看，有一些很好的工具可以告诉您恢复一段代码有多困难，首先是编译器。尝试将所有警告和错误设置为最严格的级别来构建代码。如果在这些限制下代码构建没有问题，那么以下两种情况之一是正确的。首先，代码可能是由真正知道自己在做什么的人编写的，他们非常小心地确保自己的代码不仅遵守当前的语言标准，而且使用了语言的一个足够小的子集，从而使语言中的更改不会引起任何问题。第二种可能是编译器坏了。实际上，在更新的编译器下，一段15年的代码完全没有警告地编译是非常罕见的。生成的警告和错误的数量将使您初步了解需要进行多少工作。
系统是否有一组为其编写并检入存储库的测试?如果是的话，你很幸运，你应该马上出去玩你当地的彩票。在过去几十年的软件开发中，已经有很多关于测试的文章，其中一些是由KV编写的，而且，不时地，有人实际上为他们的软件构建并维护了一组良好的单元测试。如果存在这些注释，您应该首先阅读它们，因为测试代码通常比实际代码中的注释更深入地了解系统应该做什么。
您说代码存储在一个在线存储库中。如果您已经通过了这里的前两个建议，那么您应该读取包含主要数据结构的文件的提交日志。如果您找不到包含数据结构的简单文件集，那么可能是时候重新开始了。好的提交日志可以很好地说明程序员在开发代码时的想法。由于数据结构是所有其他代码应该流动的中心位置，并且它应该始终指向它，因此这些文件的日志是最重要的。可接受消息的一个例子是:
增加了离线文件中存储数据的能力。在头数据结构中包含了文件名和文件描述符。如果文件名没有作为参数或用户在配置文件中提供，则由tmpfile() API自动生成。
提交日志中包含诸如“fixed bug”这样的短行是对远离的警告。很少看到这种情况是可以的，但我希望看到描述性更强的东西，比如错误编号或错误跟踪数据库的链接，以及对问题是什么以及如何解决问题的完整描述。
许多较老的软件依赖于较老版本的操作系统和库api。这不是重写代码的理由，因为其中许多更改本质上是机械的。决定如何处理库API中的更改是程序员的判断，但这些更改不应该成为放弃某个软件的理由，除非库或API本身已经不存在了。
我希望这不必多说，但我已经习惯了不得不说这样的话，所以我在这里说。在对系统进行任何更改之前，请确保生成一份回购的副本，并在开始处理之前将回购导入到一个新的存储库中。在源代码控制系统中使用标记或类似的构造来指示旧代码停止的位置以及可能开始的任何更改的位置。否则，您将处于无法向下一个维护代码的人解释代码从何而来的尴尬境地。
KV
亲爱的KV,
我在一家中型软件公司工作了几年，最近被“提升”为软件架构师。这似乎意味着我要完成以前的所有编码工作，但同时还要向团队中的其他成员解释编码内容。上个月，管理层让我看一看一家潜在收购公司的软件，并根据他们已经编写的软件，就我们是否应该收购这家公司提出建议。这似乎是一个简单的代码评审案例，但真的是这样吗?
贪得的
亲爱的贪婪,
你要做的第一件事是和公司的工程师成为好朋友，因为你的公司即将让他们变得富有，然后他们都会辞职，你将不得不维护他们的代码，没有奖金或股票分红的好处。而且，根据我的经验，无论你说什么，管理层都会做他们想做的事，但作为一名工程师，你必须尽最大努力。让我看看能不能想出一个更有用的答案。
你是正确的，你被要求做的是一个有效的代码审查，但它是一个有相当多的附加条件，而且它是在非常不同的环境下进行的，与可能在您的公司内部进行的审查。把这个代码审查看作是一次法律取证。有人告诉我，法律取证不像那些有趣的法庭戏剧，两个律师问一些有礼貌的问题，试图欺骗被检查者，让他说出证明他们有罪的信息。这更像是一场审讯，多位律师可以用他们喜欢的语气问任何他们想问的问题。在这种情况下，你应该表现得像那些律师一样。您的工作是尽可能多地从收购目标的工程师那里获得信息，因为在三个月内，您将维护他们的代码。不要让他们用一个大的。zip代码文件欺骗你。确保你得到的不仅仅是代码，还有他们的工具、存储库和工程师时间。让他们中的一个或多个与您一起坐在一个房间里，尽可能长时间地讨论什么是系统，它应该如何工作，以及在代码中发生什么。
还要确保与工程团队安排几次下班后的聚餐，并获得许可购买你认为需要的饮料，以便让他们告诉你代码中真正的尸体埋在哪里。最后那个建议不是开玩笑，而是非常严肃的。如果你想从工程师那里得到信息，给他们充足的食物和饮料。从你的公司至少带一个其他的工程师，一个你信任的，可以做笔记，也可以扮演好警察的人。当你问一个尖锐的问题时，你的好警察应该软化你说的话，这样你面试的团队实际上会愿意遵守你的要求。我曾考虑雇一个人跟着我，扮演“好警察”，让我远离麻烦，但我认为在我职业生涯的这个阶段，一个随从并不是一个好主意。
最后，不要相信演示。演示可以也必将被伪造。在向管理层提出任何严肃的建议之前，请确保您可以查看系统和代码。一旦您提出了建议，就要做好处理代码的准备，因为即使您说系统包含一个功能，一旦执行，将导致全人类的灭亡，这可能不会阻止管理层决定这笔交易确实是一笔好交易，然后让您继续面对如何使其发挥作用的问题。
KV
相关文章
在queue.acm.org
超越服务器整合
Werner Vogels
http://queue.acm.org/detail.cfm?id=1348590
Web服务:承诺与妥协
阿里·阿尔桑贾尼，布伦特·海尔彭，乔安妮·马丁和佩里·塔尔
http://queue.acm.org/detail.cfm?id=639315
理解问题
乔治Neville-Neil
http://queue.acm.org/detail.cfm?id=1180184
数字图书馆是由计算机协会出版的。版权所有©2015 ACM, Inc.
没有找到条目