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

Question

著名的Angular App
Structure最佳实践推荐
博客文章概述了新推荐的angularjs项目结构，该项目结构现在是面向组件而非功能的，或者在最初的github问题中命名为“ Organized by Feature”。

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

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

这看似微不足道，但事实并非如此。特别是当人们习惯了。
请注意，人类的思维非常擅长识别视觉模式（例如，由文件浏览器中的文件夹和文件结构的树节点表示创建的视觉模式）。

即，控制器不驻留在 名为“ -controllers.js”的文件中 。
它驻留在 第一个文件中，该文件的名称比以前的文件长得多 。
服务（如果有）驻留在 文件名的末尾 ，等等。

搞砸了（例如，由于起始字母弄乱了订单，或者由于组件名称太长/太短而弄乱了它们的相对长度），您遇到的情况类似于必须从硬盘驱动器读取某些内容，而不仅仅是阅读它来自RAM。（没有开发人员想要去那里：）

*：实际上，这就是我们所谓的“开发团队变动”，即团队成员离开的频率（例如，从事其他工作，离开公司等）或引入新成员的频率。
通常，团队越大，通量越大。