处理产品变化和源代码特征名称的良好战略是什么。 在此,我再次看到我的情况(你们大多数人可以联系)。
现在,我们拥有一个庞大的法典基础,50个不同的名称在名录树和源文档上 sp缩,其中大多数已经过时。 只有退伍军人记住每个名字的含义、完全的仇恨历史等。
如何解决这些问题?
<>扩大: 我不说客户看到的名字,我指的是目录、源文档、类别、变量等名称,即开发商看到不断变化的产品和特征名称在什么地方出现。
鉴于你所作的澄清,即“ t指客户所看到的名称,[you]指名录、源文档、类别、变数等,即开发商所看到的,”是,这是一个令人痛心的问题。
当我们采取的政策是,总是只用一个名字处理法典基中的每一件事时,我前面的团队是如何应对最好的。 如果我们后来改名,要么留在法典中的旧名下,要么我们将所有旧名移到新名上。 重要的是,除非老姓的所有情况都已迁移,否则从不开始使用新名称。 这样,你就只能把2个名字保留在你的头上:在法典中使用的“旧名称”和所有其他名称上。
如果我们知道“大名”可能发生变化,我们常常选择一个非常通用/描述性的名称。
我认为,重新命名为更好命名公约只是另一种令人信服的方式。 设立一个部门,进行更名、操作单位/融合测试、承诺、合并、重复。 它全都涉及流程控制,以保持项目的一致性。
解决办法是首先不要制造。 一旦指明了一条法律途径,就很少有很好的理由加以修改和never。 与旧名称一起使用新名称是一个很好的理由。 当“开发商”成为“Boom”时,你有两个选择: 要么完全使用开发商,要么永远不提及任何地方的布隆,要么把所有开发商的事例改变到布隆,然后继续完全使用布隆,永远不再提及开发商。
如果你在相同的法典基础中重新使用“Exploder”和“Bolum”,你将这样做是错误的。
此外,我知道你澄清说,你不谈论用户看望的名称,但如果你开始与你自己的内部名称合作,这些内部名称与《守则》的内容相关,完全独立于营销者想要称之为产品/产品,那么这个问题的可能性要小得多。 如果你在内部将开发商称为TNT,那么如果开发商改名为Bolum,会有什么区别?
你们如何处理地方化问题? 相同方法。
我们使用内部和外部名称。 它可以作为一种固定变数定义,像一个固定变数定义一样简单。
public static final String EXPLODER = "Boom";
在法典中,你总是使用EXPLODER。 前往路口和像样,在不同地方很难走这条路,这是一条不好的路。 如果一些伪装开始通过内部争 st(如联合材料来源或内部档案或任何东西),谁会发现剥削者?
仅使用内部名称,忽视营销/官方名称的变化:。