javascript - 为每个模块组件重复模块名称

Question

著名的Best Practice Recommendations for Angular App Structure博客文章概述了新推荐的 angularjs 项目结构，它现在是面向组件的，而不是面向功能的，或者如 initial github issue 中所命名的那样。 - “按功能组织”。

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

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世界上有一个有点相似的想法 projects and apps .每个应用通常都有自己的 models.py、views.py、urls.py、tests.py。脚本名称中没有重复的应用程序名称。

我希望我没有越过基于意见的界限，并且有遵循该方法的正当理由。

Answer 1

这是有充分理由的，它是为了改进任何重要代码库的一个非常重要的方面(尤其是当涉及大型开发团队时)，即我们所说的“可查看性”。

“概览能力”是指代码库的组织(文件夹结构、文件命名、元对象等)提供已实现软件的快速且信息丰富的概览的能力。

由于以下原因(非详尽列表)，“可概览性”的重要性随着代码库和项目开发团队的规模呈指数级增长*:

1. 当代码库很大时，代码的某些部分在特定时间段内保持不变的可能性会增加(随着此“冷”期的持续时间增加)。

2. 当新成员加入团队时，您希望他们尽快跟上进度(而不是让他们在此过程中感到沮丧)。 “Overviewability”有助于提供对整个项目的良好的高级抽象，并且通常还可以很好地了解事情是如何工作的(通常它会产生一种熟悉的感觉；就好像你以前看过代码库一样——尽管你还没有)。

---

“那么，好吧，“可查看性”很重要。这就是为什么我们有这种以组件为中心的良好结构等。但是为什么在每个文件前加上组件名称前缀？”

嗯，这听起来可能很有趣，但是为所有与组件相关的文件名添加前缀可以确保特定的顺序。例如。 HTML 部分或 CSS 将始终出现在 Controller 等之前:

...               
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
...                       ...                      ...

使用前缀确保文件以特定顺序出现: Controller 总是在 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
...                             ...                         ...

这可能看起来微不足道，但事实并非如此；尤其是当一个人习惯了它。
请注意，人脑非常擅长识别视觉模式(例如文件浏览器中文件夹和文件结构的树节点表示所创建的模式)。

即 Controller 不在名为“ -controllers.js” 的文件中。
它驻留在第一个文件中，该文件的名称明显比前面的文件长。
服务(如果有的话)驻留在末尾名称较小的文件中，等等。

搞砸了(即因为首字母弄乱了顺序，或者因为长/短组件名称弄乱了它们的相对长度)你自己的情况类似于必须从硬盘读取一些东西，而不是只是从 RAM 中读取它。 (没有开发人员想去那里:))

---

<子>*:实际上，这里重要的是我们所说的“开发团队通量”，即团队成员离开(例如从事其他工作、离开公司等)或引入新成员的频率。
通常，团队越大，通量越大。