ACM通信
Kode恶性
删除Kode
亲爱的KV,
你们的专栏经常讨论一些问题添加新的代码，但什么时候是合适的时间删除一段代码?我一直在处理一个庞大的遗留代码库，在我们的站立会议上出现的大多数问题都与我们认为可以从系统中删除哪些模块有关。
准备搬家
亲爱的准备好了,
我对你问题的狭隘感到惊讶和好笑。大多数软件开发人员在遇到遗留代码库时，只是想把它扔掉，然后重新开始。我不得不说，这种情况每周至少会发生在我身上一次，当我环顾四周时，我看到了作为软件而存在的令人震惊的遗产大山。
从系统中删除死代码是KV最喜欢的编程消遣之一，因为没有什么比删除一些你知道不被使用的东西更有感觉的了。代码删除就像打扫房间，只是有时候你用火焰喷射器打扫房间，老实说，这是非常令人满意的。由于您使用的是一个版本控制系统(您最好使用VCS!)，所以很容易删除代码而不用担心。如果您需要删除的代码，您可以随意从VCS中检索它。
至于什么时候应该删除代码，有几个答案。首先，当然，如果你有真正的死代码，它不再能够从系统中的任何地方访问，而且这不是简单地有条件地编译出来的测试代码(请参阅我2017年2月的专栏，“软件开发的邪恶三位一体”)，那么这些代码应该立即删除。一个好的编译器或其他工具会告诉你什么时候你有死代码，这应该会使工作相当简单。
当您拥有不经常使用但在系统中存在很长时间的代码时，问题就会出现。在这一点上，您必须多考虑一下您的代码，以及您正在查看的代码是否——为了寻求更好的术语——快死了。任何存活数年的系统都倾向于增加被使用的功能——有时是短暂的——然后丢弃或忽略。不删除死亡功能的逻辑通常是“如果它没有坏……”，这实际上是相当愚蠢的。如果您的软件非常脆弱，删除一个特性会破坏整个系统，那么您所面临的问题比需要清理代码要大得多，这意味着整个系统可能需要旋转，如果不是彻底重写的话。
一个死功能和死人不一样吗函数。死亡的特性要么完全不使用，要么只被少数用户使用。失效或几乎失效的特性的风险在于，它们会在代码中留下更大的攻击面。曾几何时，我们也关心死特性在可执行文件中留下的代码会使系统变得臃肿，但似乎只有我们这些在嵌入式系统领域工作的人仍然关心这个问题。对于现代基于服务器的系统，死亡特性给攻击者提供了一个渗透您系统的地方，这可能是您认为的最重要的风险，或者至少应该是这样。
有时候，一个死去的功能会有一小部分用户，或者是一个已经使用该功能多年的内部拥护者。在这一点上，移除变成了一个政治(也就是人类)问题。有几种方法可以解决工作中的政治问题，但如果你执行这些方法，其中一些会让你入狱10到20年。如果有噪声的少数非常小，那么特性就有可能被分解成独立的程序，这样代码就不再是更大的整体的一部分。如果问题出在开发者身上，那么就应该给他们一个新的挑战，远离他们所钟爱的功能。一旦你的开发人员有了自己喜欢的功能，你就有了一个非常不同的管理问题，这个问题我在这里就不讨论了。
您会注意到我并没有给出一个明确的时间轴来回答您的问题，这是因为除了在代码死亡时立即删除真正的死亡代码之外，没有其他方法。对于特性移除，这取决于你如何处理你的用户和开发者。不过，一个好的经验法则是，只有在主要版本发布时才删除一些特性，以限制惊喜的程度。
KV
相关文章
在queue.acm.org
代码囤积
Kode恶性
https://queue.acm.org/detail.cfm?id=2897034
幸存的软件依赖关系
拉斯考克斯
https://queue.acm.org/detail.cfm?id=3344149
编写测试计划
Kode恶性
https://queue.acm.org/detail.cfm?id=3294770
数字图书馆是由计算机协会出版的。版权所有©2020 ACM股份有限公司
没有发现记录