これが私が伝統的にファイルを整理した方法です。ただし、大規模なアプリケーションでは、すべてを整理したり、一意の名前を付けたりするのは非常に困難であることがわかりました。これまで行ってきた「新しい」方法は、ファイルをタイプではなく機能別に整理することです。したがって、たとえば:
js/feature1/someView.js
js/feature1/someController.js
js/feature1/someTemplate.html
js/feature1/someModel.js
ただし、多くの場合、「ユーザー」やユーザーが作成した場所のコレクションなど、必要なグローバルな「もの」があります。それで:
js/application/model/user.js
js/application/collection/location.js
このパターンが提案されたのは、機能セットで作業し、requirejsを使用して比較的少ない労力でパッケージ化してデプロイできるためです。また、機能セット間で依存関係が発生する可能性を減らすため、機能を削除したり、新しいコードで更新したりする場合は、すべてのファイルを探すのではなく、「もの」のフォルダーを置き換えることができます。また、IDEでは、作業中のファイルを見つけやすくするだけです。
私の2セント。
編集:スペックファイルはどうですか?
いくつかの考え-あなたは私が思うにあなたにとって最も自然に見えるものを選ぶ必要があるでしょう。
- スペックファイルと同じ「機能フォルダ」パターンに従うことができます。利点は、すべての仕様が1か所にあることです。欠点は、現在行っていることと同じように、1つの機能のファイルを配置する必要があることです。
- スペックは、機能フォルダの「spec」フォルダに置くことができます。利点は、他の作業を妨害することなく、単一のzipファイルにまとめることができる実際のパッケージがあることです。また、テストを作成するために直接関連するファイルを見つけるのも簡単です。これらはすべて同じ親フォルダーにあります。欠点は、本番コードとテストコードが同じフォルダーにあり、(おそらく)世界中に公開されていることです。確かに、おそらくある時点で本番JavaScriptを1つのファイルにコンパイルすることになります。したがって、それが多くの問題であるかどうかはわかりません。
- 私の提案-これが大規模なアプリケーションであり、ファイルに触れる手が数人あると思われる場合は、フォルダーに「package.json/yml/xml」ファイルのようなものを残してください。そこに、テストに必要な本番ファイル、仕様、およびデータファイルをリストします(これを行うための簡単なシェルスクリプトを作成できる可能性があります)。次に、簡単なスクリプトを作成して、ソースフォルダーで「package.whateverYouChose」ファイルを探し、テストファイルを取得して、それを使用して単体テストページを作成します。したがって、別のパッケージを追加するとします。「updateSpecRunner」またはスクリプトに名前を付けたものを実行すると、別のSpecRunner.htmlファイル(またはスペックを実行しているファイルに名前を付けたもの)が生成されます。次に、ブラウザで手動でテストするか、phantomjs/rhinoを使用して自動化できます。
それは理にかなっていますか?