在源代码中处理更改产品和功能名称的好策略是什么。这是我一遍又一遍地发现自己的情况（你们大多数人都可以联系起来？）......
现在我们有一个庞大的代码库，在目录树和源文件周围散布着50个不同的名称，其中大部分已经过时了。只有退伍军人才能记住每个名字的含义，完整的历史记录等等。
这个混乱的解决方案是什么？
澄清：我不是指客户看到的名称，我指的是开发人员看到更改产品和功能名称的目录，源文件，类，变量等的名称被编织进去。
答案 0 :(得分：6)
鉴于您的澄清，“您不是指客户看到的名称，[您]是指开发人员看到的目录，源文件，类，变量等的名称”，是的，这可能是令人讨厌的问题
当我们有一个总是只为代码库中的每个东西使用一个名称的策略时，我所处的团队的方式已经得到了最好的应对。如果名称稍后更改，我们将保留代码中的旧名称，或者将旧名称的所有实例迁移到新名称。 重要的是永远不要在代码中开始使用新名称，除非迁移了旧名称的所有实例。这样你只需要为头脑中的某些东西保留2个名字：“旧名“，在代码中使用，以及其他人使用的名称。
如果我们知道“品牌名称”可能会发生变化，我们也经常在开始时选择一个非常通用/描述性的名称。
答案 1 :(得分：4)
我认为重命名为更好的命名约定只是另一种形式的重构。创建分支，执行重命名，运行单元/集成测试，提交，合并，重复。所有这些都与过程控制有关，以保持项目的一致性。
答案 2 :(得分：4)
混乱的解决方案是首先不创造它。一旦命名了代码路径，就很少有理由对其进行更改，并且永远不会将旧名称与旧名称一起使用。当“Exploder”成为“Boom”时，你有两个选择：要么一直使用Exploder，也不要在任何地方提到Boom，要么将Exploder的所有实例更改为Boom然后继续专门使用Boom而不再提及Exploder。
如果你在相同的代码库中同时使用Exploder和Boom，那你就错了。
此外，我知道你澄清说你不是在谈论用户可见的名字，但是，如果你开始使用你自己的内部名称，这些名称与代码的作用有关，并且完全独立于营销需要的内容。调用产品/功能，这不太可能成为一个问题。如果您已经在内部将Exploder称为TNT，那么如果将Exploder更改为Boom，它会有什么不同？
答案 3 :(得分：0)
您如何处理本地化？一样;同样的方法。
答案 4 :(得分：0)
我们使用内部和外部名称。它可以像静态变量定义一样简单，如
public static final String EXPLODER = "Boom";
在代码中，您将始终使用对EXPLODER的引用。对于路径名称等也是如此 - 无论如何，在不同位置对这些路径进行硬编码是不可取的。如果有些人开始挖掘内部资料（比如JS资源或ini文件或其他东西），谁会关心他们是否发现了Exploder？
答案 5 :(得分：0)
只需使用内部名称，并忽略对营销/官方名称的更改：https://softwareengineering.stackexchange.com/a/208578/55472。