重复每个模块组件的模块名称

Question

着名的Angular App Structure最佳实践建议博客文章概述了新推荐的angularjs项目结构,该结构现在面向组件,而不是面向功能,或者在最初的github问题中命名- "按功能组织".

博客文章建议每个模块中的每个文件都应该以模块名称开头,例如:

userlogin/
    userlogin.js
    userlogin.css                
    userlogin.html                
    userlogin-directive.js
    userlogin-directive_test.js
    userlogin-service.js
    userlogin-service_test.js 

问题是:在模块中的每个文件名中重复模块名称的优点和缺点是什么,而不是命名功能的文件？例如:

userlogin/
    userlogin.js
    userlogin.css                
    userlogin.html   
    controllers.js             
    directives.js
    services.js

---

我问的原因是我来自一个Django与项目和应用有一些类似想法的世界.每个应用程序通常都有它自己的models.py,views.py,urls.py,tests.py.脚本名称中没有重复的应用程序名称.

我希望我没有跨越基于意见的路线,并且有正当理由遵循这种方法.

Answer 1

有一个很好的理由,它是为任何非平凡的代码库(特别是涉及大型开发团队时)改进一个非常重要的方面,即我们称之为"可概性".

"可概性"是代码库组织(文件夹结构,文件命名,元对象等)的能力,以提供对已实现软件的快速和信息性概述.

由于以下原因(非详尽列表),"可概性"的重要性随着代码库的大小和开发团队在项目*上的大小呈指数级增长:

1. 当代码库很大时,代码的某些部分在特定时间段内保持不变的概率增加(因为增加了这个"冷"时期的持续时间).

2. 当新成员加入团队时,您希望他们尽快加快速度(并且不会让他们在此过程中感到沮丧)."可概性"有助于为整个项目提供良好的高级抽象,并且通常也能很好地理解事物的工作方式(通常情况下它会产生一种熟悉感;就好像你以前见过代码库一样 - 虽然你还没有).

"所以,好的,"可概性"很重要.这就是为什么我们有这个漂亮的,以组件为中心的结构等等.但为什么要为每个文件添加组件名称？"

嗯,这可能听起来很有趣,但前缀所有与组件相关的文件名确保了特定的订单.例如,HTML部分或CSS将始终出现在控制器之前:

...               
userlogin.html                
userlogin-controller.js
...

如果不是前缀,那么根据组件的名称,您最终会得到各种订单.例如:

...                       ...                      ...
controller.js             controller.js            bookself.html
...                       ...                      ...
service.js         VS     service.js        VS     controller.js
...                       ...                      ...
userlogin.html            zombi.html               service.js
...                       ...                      ...

使用前缀可确保文件按特定顺序显示:控制器始终位于HTML部分,服务等之后.例如:

...                             ...                         ...
userlogin.html                  zombi.html                  bookself.html
...                             ...                         ...
userlogin-controller.js    VS   zombi-controller.js    VS   bookself-controller.js
...                             ...                         ...
userlogin-service.js            zombi-service.js            bookself-service.js
...                             ...                         ...

这可能看似微不足道,但事实并非如此; 特别是当人们习惯它.
请注意,人类的头脑非常善于识别视觉模式(如文件浏览器中文件夹和文件结构的树节点表示所创建的视觉模式).

即控制器不驻留在名为"<component> -controllers.js"的文件中.
它驻留在第一个文件中,该文件的名称比以前的文件长得多.
服务(如果有的话)驻留在末尾较小名称的文件中,等等.

搞砸了(因为起始字母搞乱了订单或由于长/短组件名称弄乱了它们的相对长度)并且你自己的情况类似于必须从硬盘读取内容,而不仅仅是阅读它来自RAM.(没有开发者想去那里:))

_{*:实际上,这就是我们所说的"开发团队流量",这在这里很重要,即团队成员离开的频率(例如,工作于其他事情,离开公司等)或新成员将被引入.
通常,团队越大,流量越大.}

Answer 2

这都是关于组织大型项目(代码库):

我发现名称和文件夹层次结构对于组织大型项目非常有价值.同样,有意义的等级名称对我有很大的帮助.

来自ASP.NET世界,项目规模巨大,我们有:

解决方案 - >管理项目(程序集) - >包含文件夹 - >和子文件夹,用于文件.

因此,一个ASP.NET MVC项目将有一个家庭控制器在Controllers该文件夹中的MVC介绍项目,并Views在浏览文件夹.

在我的项目中使用AngularJS时,我喜欢命名方法

App(Module)-type(directive/service)-(sometimes more detail)

这是为应用程序命名文件夹,并在文件夹中为其类型提供指令和服务,文件夹以应用程序命名,应用程序通常在功能上命名,或者在ASP.NET视图之后命名(如我的视图可能Account-Login).

这一切都是因为我的项目非常庞大.我最终得到了许多AngularJS apps,疯狂的数字directives,甚至是相当数量的services.

当您的项目很小甚至是中等规模时,优势是有争议的.但是当你的项目变得越来越大时,组织就变得至关 两者都可以帮助您找到所需的代码,并继续传播更多代码.

Answer 3

TL;博士; 虽然其他答案在大多数问题上都没有错,但他们未能认识到今天开发人员可用的文件导航工具的重要性.

快速浏览项目文件

一旦我们熟悉了一个项目,我们就会想要在不查看源树的情况下在文件之间导航.我们的命名方案将在允许我们快速导航方面发挥重要作用.我们可以通过输入文件名的片段来非常快速地导航到文件.例如,如果您的模块名称是,forsee您可以通过在文件搜索框中键入来查看forsee javascript文件列表fo.js(假设您的编辑器具有此功能).在Chrome开发工具源标签有这个功能内置.你可以在这里看到它(打开开发工具并按下Cmd + O):

我曾经认为在模块名称之前添加所有文件名是有效搜索所必需的,但后来意识到这根本不是真的.我们可以有效地搜索fo/js:

因此,现在应该清楚的是,无论模块名称是否附加到文件名,我们都可以快速导航到文件.

Overviewability

我同意ExpertSystem,将文件分组在一起可以让您一目了然地看到事物.但是,再次预先添加模块名称并不是必需的.而是在编辑器中激活相应的选项:

在上面的屏幕截图中,我激活了" 按类型排序"选项以启用按文件扩展名排序文件.

为什么我们不应该

如果在小屏幕(即笔记本电脑)上编码并使用左侧轨道树视图来导航文件夹结构,则较短的文件名将更好地服务于有限的屏幕空间.模块文件夹名称将是可见的,因此查看为每个文件重复的名称没有用.

注意事项

显然,我上面提到的大部分内容都依赖于开发人员使用正确的工具并且知道如何使用它们.如果您的团队没有这些工具,或者您怀疑他们有效使用这些工具的能力,培训他们,或坚持使用超详细的命名方案.

结论

使用当今开发人员可用的高级工具,重复每个文件的模块名称是不合时宜的.但是,过于冗长的文件命名不会造成任何严重的危害或效率问题.在构建新项目时,我们必须做出许多其他架构决策,这些决策远比这个更重要.

_{BTW:我根据ExpertSystems建议命名js文件.即,dialog.js,dialog-ctrl.js,dialog-services.js,等,这是有道理的,他所陈述的理由,但是,当一个模块有多个谐音也最好不要遵循这个命名模式的HTML文件.}