项目组织和命名约定 [英] Project organization and naming conventions

问题描述

这是一个有点后续<一个href=\"http://stackoverflow.com/questions/25005897/repeating-module-name-for-each-module-component\">Repeating模块名称每个模块组件问题。

This is somewhat a follow-up to Repeating module name for each module component question.

我们已经决定跟随在角应用结构的最佳实践建议建议博客帖子角项目组织和命名约定，同时建立用于测量连接质量一个小型的内部应用程序。

We've decided to follow the suggested in Best Practice Recommendations for Angular App Structure blog post angular project organization and naming conventions while building a small internal application for measuring connection quality.

这就是我们目前已经得到了：

And this is what we've got at the moment:

$ 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

正如你所看到的，有几个指令，服务，谐音，单个控制器，模块声明文件和配置夫妇和具体应用，无关的主题文件。这真的成​​为档案很乱，不是很可读和易于使用。

As you can see, there are several directives, services, partials, single controller, module declaration file and couple config and app-specific unrelated to the topic files. This really becomes a mess of files and is not quite readable and easy to work with.

这可能是因为的我们只有一个单一模块的，并保持里面的一切。

This is probably because we have only one single module and keep everything inside it.

什么情况下可以使用好老的面向构件的方法，并有服务，控制器特殊目录， 指令和谐音对于这样一个简单的应用程序？这是否意味着新的按功能组织的工作方法只对非平凡巨大的应用？

Is it okay to use the good old component-oriented approach and have special directories for services, controllers, directives and partials for such a simple app? Does this mean that the new "Organized by feature" approach work only for non-trivial huge applications?

推荐答案

你说你决定的跟着中的为角应用结构博客文章最佳实践的建议的，但你似乎并不遵循它...

You say that you decided to "follow the suggested in Best Practice Recommendations for Angular App Structure blog post", but you don't seem to have followed it...

根据建议的方法，每个组件/功能应该在自己的目录（下组件目录）。

According to the recommended approach, each component/feature should be in its own directory (under a components directory).

有关的原因所指出的<一个href=\"http://stackoverflow.com/questions/25769920/project-organization-and-naming-conventions#answer-25778519\">Gil伯曼并还详细说明在上述博客帖子以及在<一个href=\"http://stackoverflow.com/questions/25005897/repeating-module-name-for-each-module-component\">Repeating每个模块组件模块名称，它更有意义，组织由功能的目录（如富 -feature目录包含所有指令，服务，控制器，谐音等有关该功能），比按类型组织（如在一个目录下的所有控制器，在其他所有服务）等。

For the reasons pointed out by Gil Birman and also detailed in the aforementioned blog post as well as in Repeating module name for each module component, it makes more sense to organize the directories by feature (e.g. the foo-feature directory contains all directives, services, controllers, partials etc related to that feature) than organizing by type (e.g. all controllers in one directory, all services in another) etc.

在任何情况下，所有以上是指引（思考更多的方式），而不是一个precise配方或确定的算法，可以决定你在何处放置每个文件（例如，有将是一个组件/ lib中/ 目录，将服务功能的目录中或组件/普通/ 目录等）去下。结果
你需要了解的指导方针（和目的是什么/需要试图完成），并制定适合自己球队的风格约定。

In any case, all the above are guidelines (more a way of thinking) and not a precise recipe or a deterministic algorithm that can decide for you where to place each file (e.g. is there going to be a components/lib/ directory, will a service go inside a feature's directory or under a components/common/ directory etc).
You need to understand the guidelines (and what purpose/need the are trying to fulfil) and develop a convention that suits your team's style.

有些时候，你不会知道在哪里放置文件。您可以与团队进行辩论，做出决定，并与该走了。
这是完全正常的（尤其是在第一），但你会发现，随着时间的推移，这种情况下会出现越来越多的很少。

There are times when you won't be sure where to place a file. You can have a debate with the team, make a decision and go with that. This is totally normal (especially at first), but you'll find out that as time goes by, such cases will arise more and more rarely.

这是说，我希望你的目录和文件结构更像是（使一些假设关于哪些服务可能是更通用/公用事业等）：

That said, I would expect your directory and file structure to be more like that (making some assumptions about which services might be more generic/utility-like):

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

这篇关于项目组织和命名约定的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！