项目组织和命名约定

这在某种程度上是后续每个模块组件重复模块名称 https://stackoverflow.com/questions/25005897/repeating-module-name-for-each-module-component问题。

我们决定遵循中的建议Angular 应用程序结构的最佳实践建议 https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/pub博客文章 Angular 项目组织和命名约定，同时构建一个用于测量连接质量的小型内部应用程序。

这就是我们目前所拥有的：

$ tree -L 1
.
├── app-config-service.js
├── app-config-service_test.js
├── app-connection-service.js
├── app-connection-service_test.js
├── app-controller.js
├── app-controller_test.js
├── app-countdown-directive.js
├── app-countdown-directive_test.js
├── app-footer-directive.js
├── app-footer-directive_test.js
├── app-footer-service.js
├── app-footer-service_test.js
├── app-math-service.js
├── app-math-service_test.js
├── app-stats-directive.js
├── app-stats-directive_test.js
├── app-status-directive.js
├── app-status-directive_test.js
├── app-status-service.js
├── app-status-service_test.js
├── app-time-directive.js
├── app-time-directive_test.js
├── app.css
├── app.js
├── bower_components
├── config.json
├── countdown.html
├── footer.html
├── img
├── index.html
├── ping
├── stats.html
└── status.html

正如您所看到的，有几个指令、服务、部分、单个控制器、模块声明文件以及与主题文件无关的配置和特定于应用程序的配置。这确实变成了一堆乱七八糟的文件，并且不太可读且易于使用。

这可能是因为我们只有一个模块并把所有东西都放在里面。

是否可以使用良好的旧的面向组件的方法并为它们提供特殊的目录services, controllers, directives and partials对于这样一个简单的应用程序？这是否意味着新的“按功能组织”方法仅适用于重要的大型应用程序？

你说你决定“按照中的建议进行操作Angular 应用程序结构的最佳实践建议 https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/pub博客文章”，不过你好像没跟上……

根据推荐的方法，每个组件/功能应该位于其自己的目录中（在components目录）。

由于所指出的原因吉尔伯曼 https://stackoverflow.com/questions/25769920/project-organization-and-naming-conventions#answer-25778519并且在上述内容中也有详细说明博客文章 https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/pub以及在每个模块组件重复模块名称 https://stackoverflow.com/questions/25005897/repeating-module-name-for-each-module-component，按功能组织目录更有意义（例如foo-feature 目录包含与该功能相关的所有指令、服务、控制器、部分等）而不是按类型组织（例如一个目录中的所有控制器，另一个目录中的所有服务）等。

无论如何，以上所有内容都是指南（更多的是一种思维方式），而不是可以决定将每个文件放置在何处的精确配方或确定性算法（例如是否会有一个components/lib/目录，服务将进入功能的目录还是在components/common/目录等）。
您需要了解准则（以及试图实现的目的/需求）并制定适合您团队风格的惯例。

有时您不确定将文件放在哪里。您可以与团队进行辩论，做出决定并遵循该决定。 这是完全正常的（尤其是一开始），但你会发现随着时间的推移，这种情况会越来越少。

也就是说，我希望您的目录和文件结构更像这样（对哪些服务可能更通用/更像实用程序做出一些假设）：

app/
|___ app.css
|___ app.js
|___ app-controller.js
|___ app-controller_test.js
|___ bower_components
|___ config.json
|___ index.html
|
|___ components/
|    |___ common/ or util/
|    |    |___ config-service.js
|    |    |___ config-service_test.js
|    |    |___ connection-service.js
|    |    |___ connection-service_test.js
|    |    |___ math-service.js
|    |    |___ math-service_test.js
|    |
|    |___ countdown/
|    |    |___ countdown.html
|    |    |___ countdown-directive.js
|    |    |___ countdown-directive_test.js
|    | 
|    |___ footer/
|    |    |___ footer.html
|    |    |___ footer-directive.js
|    |    |___ footer-directive_test.js
|    |    |___ footer-service.js
|    |    |___ footer-service_test.js
|    |
|    |___ img/
|    |    |___ ...
|    |
|    |___ stats/
|    |    |___ stats.html
|    |    |___ stats-directive.js
|    |    |___ stats-directive_test.js
|    | 
|    |___ status/
|    |    |___ status.html
|    |    |___ status-directive.js
|    |    |___ status-directive_test.js
|    |    |___ status-service.js
|    |    |___ status-service_test.js
|    |
|    |___ time/
|         |___ time-directive.js
|         |___ time-directive_test.js
|
|___ misc/
     |___ ping