更改公司名称...我们是否更改名称空间?

时间:2009-09-04 18:23:22

标签: namespaces refactoring

我们计划很快改变公司名称。我们所有的命名空间,项目等都使用XYZ.ComponentName。

我的问题是我们应该更改命名空间吗?将所有旧组件更改为ABC.ComponentName?保留旧的,但任何新的开发成为ABC.ComponentName?只要坚持旧名称?

9 个答案:

答案 0 :(得分:14)

它取决于。

要考虑的一些事项:如果更改命名空间意味着在CVS中移动文件,那么会因为丢失历史记录而受到惩罚。如果更改命名空间意味着手动工作,那么您将错过位置并导致错误。

此外,您是否拥有代码/库的外部用户?如果他们因为你重新命名公司而不得不改变他们的代码,他们就会生气。

我倾向于按原样保留代码。命名空间除了防止冲突外没有意义;在这一点上它只是营销。但对于新产品,我肯定会使用新名称。

在我以前工作的地方,我们有一些公司名称或应用程序名称更改,这总是有问题的。一个应用程序被推迟了几个星期,同时他们在最后一刻解决了全局命名空间更改中的错误。另一个应用程序从未采用新名称,并且始终在内部引用过时的名称,可能会让新用户感到困惑。想象一下,如果Java中的所有内容仍称为“Oak”。

答案 1 :(得分:5)

您是否将这些组件出售给第三方?如果没有,那么这不值得努力。如果是,那么命名空间就是营销的一部分,因此应该进行更改。

答案 2 :(得分:3)

至于您发现自己的当前泡菜,我会要求从标牌更改预算修改代码中的一些$$。如果他们不给你,请留下原来的名字。

我认为正确的答案是,首先不要在其中创建带有公司名称的命名空间。几乎每个人都知道谁签了他们的薪水;你可以通过在代码中加入名称来避免混淆。

我有一个同事有一天会发现名称空间,接下来我知道我们整个软件库必须通过几层命名空间来指定我们的公司,部门和项目。问题是,我们实际上只有一个项目(虽然你可以说服我的好处),其他部门不做软件,我们从其他公司采取的代码不遵循他的计划。所以真的只是我们必须做的很多无用的额外打字。是的,我们可以“使用”,但是根本没有真正的名称空间。哦,当然,我们的部门名称在几年之后发生了变化,当时管理层认为“分工”听起来很有意思,我们现在应该被称为“团队”。 % - (

当你有几个类时,你最好使用命名空间来命名startimg(或包含某个地方)相同的字符串。它们不是用于镜像软件开发组的当前管理报告结构。

答案 3 :(得分:2)

无论您做出哪种选择,都不要在新开发中混合两个命名空间。始终如一。如果你选择坚持使用旧的,那么新开发也应该使用它。如果你搬到一个新的,移动一切。

可能需要对您的特定场景所涉及的工作进行更多分析,以确定是否值得切换。

答案 4 :(得分:1)

从维护的角度来看,混合和匹配命名空间通常非常麻烦并且令人困惑。我会说这实际上取决于你正在处理的组件数量以及有多少应用程序依赖它们。

也许有意义的是绘制出依赖关系,并了解你手上有多少工作。

答案 5 :(得分:1)

另外,请注意您是否正在进行任何使用反射的依赖注入,因为这可能会破坏。

另一个问题是第三方代码或其他使用项目的项目,如果有的话,因为更改命名空间会破坏它们。

最安全的选择是保留名称空间。

答案 6 :(得分:0)

这取决于组件是否稳定,使用得多,如果没有太多时间改变,如果有时间钱和开发人员改变它......

很多if。

答案 7 :(得分:0)

我可能只是将它们保留原样。更改它们会在工作,测试和验证中造成噩梦,如果有人在外部使用您的库,他们还必须更改其绑定以适应此更改。

当Apple收购Next时,他们按原样保留了NS前缀,今天你可以看到Apple的开发框架。离开它们不会杀死你。

对于新的命名空间,您可以将其更改为ABC,但之后会破坏一致性,这可能会让人感到困惑 - 尤其是新开发人员。

保持原样并担心其他事情:)

答案 8 :(得分:0)

我在这样的场景中的经验是,最好保留当前的命名空间。开发的任何新库都可以在命名空间中使用新的公司名称。