如何确定源代码管理中是否有有用的已删除代码？

因此，我正在阅读此问题，是否应该删除未引用的代码？

一些建议是删除未引用的代码，因为该代码在源代码控制中以供将来参考。

您如何组织此删除的代码，以便您（或其他程序员）的更高版本以后可以找到它？您是否制作了一个单独的分支或以某种方式在源代码管理中对其进行了标记？

以前我从未从源代码控制中恢复已删除的代码，我只是将其用于跟踪仍在运行的代码的更改。在包含其他人的实验性工作之前，我已经引用过分支，所以也许这是标记在主干中删除的有趣代码段的好方法吗？

除非您在分支机构中进行实验并且不确定是否最终将重新集成哪种解决方案，否则通常不会引用已删除的代码。

你可能会，在非常罕见的场合，明确挖删除代码，你依稀记得解决你有问题，现在。但是，您会看到已删除的代码的更典型的原因是，当您浏览待办事项列表以了解有关应用程序的当前代码或行为及其历史代码或行为的某些信息时。

具体来说，您可能会...

• 进行常规代码审查/了解重构
• 寻找引入错误X的提交
• 满足您的好奇心/寻找解决错误的提交
• 重新实现功能或类似功能
• 了解似乎可以与不存在的代码结合使用的代码或数据

...等

在那种情况下，您通常不会恢复旧代码。您只是使用已删除的代码作为上下文或指导来了解现在所看到的内容。

我猜，答案是：绝大多数程序员都不在乎引用已删除的代码。有几个原因。我想到的一些原因是：

• 可能最重要的是，纯粹的懒惰...

• 大多数人从未感到有必要重新编写某些代码，因此他们没有任何经验可以激励他们简化重新编写代码的工作。

• 由于某种原因，删除了大多数已删除的代码。通常，它会被其他一些更好的，功能上等效的或更强大的代码代替。为什么有人要复活劣等密码？

  请注意，这也是一个心理问题：大多数程序员都为他们的工作成果感到骄傲。怎么会想到，它们所取代的东西仍然有价值？

• 由于大多数代码不是纯粹删除而是替换，因此，如果由于新代码引入的某些回归而确实需要跟踪删除的代码，则在过渡中已更改的接口将提供足够的信息。

但是，不管您可以为这种无用的代码置之不理或多或少有正当理由，我认为对于程序员而言，这实际上只是“不在乎”。而且，即使您尝试以某种方式标记已删除的内容，也要准备好被这种努力彻底忽略...

这个问题可能取决于“如何保持VCS签入对漏洞数据库和系统要求的可跟踪性？”

人们倾向于从Source控制中恢复代码的时间通常是那些您发现某些意外损坏并需要重新带回的时间。

在这种情况下，对于某些人来说，寻找特定的已删除代码最重要的一点是，他们可以通过查看需求数据库和错误跟踪工具轻松地对其进行跟踪。因为他们很可能正在搜索特定需求，或者描述功能的词语。他们不太可能知道源文件的名称或已删除的类/函数。

如果您想跟踪一些有趣的/实验性的代码，这些代码需要在发布之前被取出，您可以简单地使用一些“错误”凭单按照“为...删除未使用的代码...”来跟踪它。或者，可能会向系统中引入用于原型功能的新型票证。

因此，要直接回答问题-不要在VCS系统中使用分支机构/标记来跟踪已删除的代码-请使用更改跟踪工具。

该建议适用于将过时的代码“以防万一”保留在代码库中的人员。由于代码仍将存在于源代码管理中，因此您不必担心将其删除。您实际上并不需要真正组织删除的代码，因为要点是不再需要它了。您只需添加提交消息，该消息指示在提交中已更改和删除的内容。与已删除代码最相关的提交消息是最初添加代码时的消息，而不是再次删除代码时的消息。

“实验性工作”实际上是一个不同的问题。为此，您应该有一个单独的分支。