我的团队正在开发一个转换项目,将一个产品(但有很多方面)从VB6转换为.Net(我们有超过~300k的LOC).在我加入之前,决定无论程序集的位置或文件夹结构如何,所有类/结构都将位于一个名称空间中:
.
他们甚至可以更改自动生成的应用程序设置设计器代码,资源设计器代码等,以强制统一.我如何说服他们命名空间使用是好的？命名空间的正确用法是什么,有哪些优点和缺点？我想我很难理解为什么我的同事会经历如此多的麻烦来节省一些使用线路.任何外部的,有信誉的参考支持您的论点将非常感激.请帮忙!
我读了很多好的答案(例如,驱动器文件夹的图像很好,就像对象/概念分离/组织一样).
尽管如此,其他一些不那么"技术性"的论点可能有所帮助,而不是解释为什么命名空间比替代方案更好,而是要找出不使用命名空间的坏理由.
权威论证每个C#,VB.NET,Java,C++,无论开发人员在这个星球上有什么价值,都承认命名空间/包是件好事.嘿,他们甚至在Mozilla的JavaScript中考虑它.
我猜你在Stack Overflow上的问题有"权威论证"触摸...... ^ _ ^
旧习难改我相信你正陷入"旧习惯"的境地.
虽然我对VB.NET没有直接的经验来反对VB6的旧习惯,但是对于C++来说,我是针对精简的C类C++做的.
在处理遗留习惯时,一半的工作是发现他们已经使用了命名空间,而没有承认它.
例如(对于与"旧时尚",类似C的代码冲突的C++开发人员来说,这是最正确的,但我认为它在任何地方都是可行的),他们是否为其符号使用前缀.
他们有没有:
帐户用户
账户价格
帐户 ID
登录用户
登录密码
类/符号,并说明帐户的"用户"与登录的"用户"不同,因此,区分它们的前缀是什么？
当模式为模块添加符号时,"模式"会直接通过天花板(如果代码足够大,则代码就是这种情况):
你有MyUtil DLL,以及MyKernel DLL和MyGui DLL吗？那么,你有:
MyUtil_ Something
MyUtil_ SomethingElse
MyKernel_ YetAnotherObject
MyKernel_ AnotherThing
MyGui_ SomeGui
类/符号？
如果是,那么他们应该承认他们已经在使用名称空间.
如果没有,那么你的代码库太小了(但你的"9个项目"告诉我它不是),或者它们经常出现名称冲突的问题......这可以通过前面解释的前缀来解决,或者甚至更好,通过命名空间.
另一半的工作是让他们解释为什么他们的"命名空间"比语言中内置的更好(这是你应该避免因为致命暴露脑死亡推理而沮丧地撞到墙壁的那一刻) .
再一次,你可以使用权威论证(什么？你相信知道比微软的Top Gun工程师更好吗？),但在这种情况下,你应该举例说明为什么.NET(或其他)命名空间比他们使用(或不使用)的人.
对于VB.NET/.NET,已经有足够多的好参数,我不会继续讨论C++命名空间背后的问题,因为它不属于主题.
但至少,使用内置命名空间使上面提到的前缀可选.从互联网上引用一个例子(我对VB.NET不是很了解):
Imports MyWholeProject
Class HelloWorld
Public Sub Main()
Dim o As MyModuleAAA_MyObject = New MyModuleAAA_MyObject
Dim t As MyModuleBBB_MyThing = New MyModuleBBB_MyThing
Dim g As MyModuleCCC_MyGizmo = New MyModuleCCC_MyGizmo
REM etc.
End Sub
End Class
比启用的命名空间更冗长:
Imports MyWholeProject.MyModuleAAA
Imports MyWholeProject.MyModuleBBB
Imports MyWholeProject.MyModuleCCC
Class HelloWorld
Public Sub Main()
Dim o As MyObject = New MyObject
Dim t As MyThing = New MyThing
Dim g As MyGizmo = New MyGizmo
REM etc.
End Sub
End Class
冗长导致更加模糊的代码,从而导致错误.当然,你可以用不太长的东西代替MyModuleAAA,比如MMAAA ...但是,它会导致更加模糊的代码等等.
Googling可以在以下网站上找到更多用于.NET的命名空间:http://www.vbdotnetheaven.com/UploadFile/ggaganesh/NamespacesInVbDotNet04202005005133AM/NamespacesInVbDotNet.aspx
项目/职业相关的原因这些原因更多地与项目/职业管理相关......
如果您的应用程序是一个老垂死的牛,更改标签或组合的内容值2天的工作(它确实发生),那么也许没有必要进行重构的额外工作.另一方面,如果重构是自动化的,那么无论如何都应该这样做.
但是如果你的应用程序应该在将来使用,那么破坏它以保持它过去是一个坏主意.总有一天你会付钱的.应该通过避免维护赢得的每个小时将被支付两倍或十倍的一天它将变得不可避免(你知道,那天你没有时间正确地做它,因为它是紧急的......)
这个论点适用于具有职业生涯并且必须保住工作的工程师:与应用程序一样,软件工程师也可能过时.
这意味着过时的开发人员在申请其他工作时也会失败.因为,嘿,谁愿意为那些不像命名空间这么简单的人买单？
当它与当前最先进的技术相结合时,经验是一件好事.如果没有,那么在我的时代,当我们不需要所有那些像物体一样的小玩意时,它只是恐龙般的愤世嫉俗和无用的漫无边际的" 如何更好(阅读:更简单)".
通过拒绝适应语言的新功能(通常因为" 我们知道更好,你知道吗？ "),工程师们只是穿上混凝土鞋,而竞争对手可能会穿上跑鞋.这意味着过时团队制作的应用程序最终会丢失.期.
以类似的方式,团队将聘请新的工程师,他们可能知道这些功能,谁会变得惊讶,然后对他们只是像几十年前的祖母那样编程这一事实感到沮丧.过时的团队不会让新工程师保持很长时间(至少,那些值得付出代价的工程师).
请注意,处理过时的产品可以让顶级经理更容易决定从头开始重写它...而且可能在其他地方,与薪酬较低的工程师和经理......
命名空间的正确使用是提供逻辑分组的类,接口,枚举等的有序结构.这就像将所有文件放在一个文件夹中......或者更糟糕的是,将它们全部放在C:驱动器的根目录中......
我很难指出你的团队是非常短视的,这不是我开始质疑其他团队政策和程序的地方 - 但如果我在你的位置,我会坚持我的枪.
京公网安备 11010802040832号 | 京ICP备19059560号-6 