如何处理源代码中功能和产品名称的变化？
处理源代码中不断变化的产品和功能名称的好策略是什么？这是我一次又一次遇到的情况（你们大多数人都能体会到吗？）...
- 产品名称以“DaBomb”开头
- 主要功能是“爆炸器”、“灯笼”和“旗帜”。
- 流逝，功能名称变为“Boom”、“Lighthouse”和“MarkMan”
- 时间流逝，产品名称变为“DaChronic”
- ……
- 时间
- 废话、废话、废话……一遍又一遍 。
现在我们有了一个庞大的代码库，目录树和源文件中散布着 50 个不同的名称，其中大多数都已过时 只有退伍军人才能记住每个名字的含义、完整的病因历史等等。
解决这个混乱的办法是什么？
澄清：我不是指客户看到的名称，而是指开发人员看到的目录、源文件、类、变量等的名称，其中不断变化的产品和功能名称融入其中。
What is a good strategy for dealing with changing product and feature names in source code. Here's the situation I find myself in over and over again (most of you can relate?)...
- Product name starts off as "DaBomb"
- Major features are "Exploder", "Lantern" and "Flag".
- Time passes, and the Feature names are changed to "Boom", "Lighthouse" and "MarkMan"
- Time passes, and the product name changes to "DaChronic"
- ...
- ...
- Blah, blah, blah...over and over and over
And now we have a large code base with 50 different names sprinkled around the directory tree and source files, most of which are obsolete. Only the veterans remember what each name means, the full etimologic history, etc.
What is the solution to this mess?
Clarification: I don't mean the names that customers see, I mean the names of directories, source files, classes, variables, etc. that the developers see where the changing product and feature names get woven into.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
鉴于您的澄清，您“不是指客户看到的名称，[您]是指开发人员看到的目录、源文件、类、变量等的名称”，是的，这可能是一个恼人的问题。
当我们制定了始终为代码库中的每项内容仅使用一个名称的政策时，我所在的团队的应对方式是最好的。如果名称稍后发生更改，我们要么在代码中保留旧名称，要么将旧名称的所有实例迁移到新名称。 重要的是永远不要在代码中使用新名称，除非旧名称的所有实例都已迁移。这样，您只需在头脑中保留两个名称：“旧名称”，在代码中使用，以及其他人使用的名称。
如果我们知道“品牌名称”可能会改变，那么在开始时我们也经常为事物选择一个非常通用/描述性的名称。
Given your clarification that you "don't mean the names that customers see, [you] mean the names of directories, source files, classes, variables, etc. that the developers see", yeah, this can be an annoying problem.
The way teams I've been on have coped with best when we've had a policy of always using only one name for each thing in the code base. If the name changes later on we either stay with the old name in the code, or we migrate all instances of the old name to the new name. The important thing is to never start using the new name in the code unless all instance of the old name have been migrated. That way you only ever have to keep 2 names for something in your head: the "old name", used in the code, and the name everyone else uses.
We've also often chosen a very generic/descriptive name for things when starting out if we know the "brand name" is likely to change.
我认为重命名为更好的命名约定只是另一种形式的重构。创建分支，执行重命名，运行单元/集成测试，提交，合并，重复。这一切都与过程控制有关，以保持项目的一致性。
I consider renaming to better naming conventions just another form of refactoring. Create a branch, perform the renames, run unit/integration tests, commit, merge, repeat. It's all about process control to keep consistency in the project.
解决混乱的办法就是从一开始就不要制造它。一旦命名了代码路径，就很少有充分的理由来更改它，并且永远没有充分的理由在旧名称旁边使用新名称。当“Exploder”变成“Boom”时，你有两个选择：要么继续只使用Exploder，不再在任何地方提及Boom，要么将Exploder的所有实例更改为Boom，然后继续只使用Boom，不再提及Exploder。
如果您在同一代码库中同时使用 Exploder 和 Boom，那么您就错了。
另外，我知道您澄清过，您不是在谈论用户可见的名称，但是，如果您开始使用自己的内部名称，这些名称与代码的功能相关，并且完全独立于市场营销想要称呼的产品/feature，那么这不太可能成为一个问题。如果您已经在内部将 Exploder 称为 TNT，那么如果将 Exploder 更改为 Boom 会有什么区别呢？
The solution to the mess is to not create it in the first place. Once a code path is named, there's rarely a good reason to change it and never a good reason to use a new name alongside the old one. When "Exploder" becomes "Boom", you have two choices: Either keep using Exploder exclusively, and never mention Boom anywhere, or change all instances of Exploder to Boom and then continue on using Boom exclusively and never mention Exploder again.
If you're using both Exploder and Boom in the same code base, you're doing it wrong.
Also, I know you clarified that you're not talking about the user-visible names, but, if you start out working with your own internal names which are relevant to what the code does and completely independent of what marketing wants to call the product/feature, then this is much less likely to become an issue. If you're already referring to Exploder internally as TNT, then what difference does it make if Exploder gets changed to Boom?
您如何处理本地化？同样的事情；同样的方法。
How do you deal with Localization? Same thing; same method.
我们使用内部和外部名称。它可以像静态变量定义一样简单，
并且在代码中您将始终使用对 EXPLODER 的引用。路径名等也是如此——无论如何，在不同的地方对这些路径进行硬编码是不行的。如果有些人开始挖掘内部内容（例如 JS 源代码或 ini 文件或其他文件），谁会关心他们是否发现了 Exploder？
We use an internal and and external name. It could be as simple as a static variable definition like
And in code you'll always use the reference to EXPLODER. Same for path names and the like - hard coding those paths at different places is a no-go anyway. If some guys starts digging through internal stuff (like JS sources or ini files or whatever), who cares if they discover Exploder?
只需使用内部名称，并忽略对营销/官方名称的更改：https://softwareengineering.stackexchange.com/a/208578/ 55472。
Just use internal names, and ignore changes to marketing/official names: https://softwareengineering.stackexchange.com/a/208578/55472.