大規模なJavaScriptアプリケーションはどのように構造化されることになっていますか？
最近、OBIEE Mobile App Developer用に作成されたJavaScriptプラグインと、さまざまなプロジェクト用のカスタムライブラリがいくつか表示されました。
OOPバックグラウンドから来ているので、これらのプロジェクトの構造について少し混乱しています。-数千行のファイルが表示されています。分割に慣れています物事をファイルとクラスに入れますが、これは別のフレームワークであることを理解しています-一つには、ファイルサイズが問題ですが、それをすべて行うにはもっと良い方法があるはずですか？
スクリプトの長さは、読みやすさと保守性だけでなく、プログラムの動作に関する一般的な理解にも影響します。
大規模なアプリケーションはどのように構成されていますか？一般的なOOPこのための設計パターン？
JavaScriptパターンに慣れていない場合は、大規模なアプリケーションやライブラリの多くが Revealing Module Pattern を使用していることがわかりますが、必要に応じて他にも多くのパターンを使用できます。
ただし、モジュールパターンの表示は、大きなファイルを分割して論理的に整理するための優れた方法を提供します。ただし、JavaScriptでデザインパターンを操作する場合は、thisが非常に混乱する可能性があることに注意してください。 this、new、prototype、.call()および.apply()は賢明です。
大規模なプロジェクトに取り組んでいる間、これらは次の場合にも役立ちます。
- 可能であれば、TypeScriptまたはES6に切り替えます。
- Modularコードを記述します。さまざまな方法とサードパーティのライブラリがありますが、どれを使用しても何もないよりはましです。
- Task Runner/Build Systemを使用してタスクを自動化します。
- デザインパターンについて読んでください。 これ は良いスタートかもしれません。上で述べたように、 Revealing Module Pattern は、特にすべての人気のあるパターンを習得する時間が必要だと考える場合に非常に便利です。
- 書き込み単体テスト。動的言語での作業はより困難な場合があります。アプリケーションの重要な部分をテストすると、多くの時間を節約できます。
- [〜＃〜] ide [〜＃〜]またはText Editorそれは実際にコードを書くこととバグをキャッチすることの両方であなたを助けることができます。 WebStormは良い選択です。崇高なテキストも。
- IDEがデバッガを提供していない場合は、お気に入りのWebブラウザのデバッガを習得してください。
- ライブラリを使用します。プロジェクトの性質に応じて、見つけることができる最高のサードパーティのコードを採用するようにしてください。 Webアプリケーションを作成している場合は、Angular、Reactと古き良きbackbone.js Node.jsアプリケーションを作成している場合は、時間をかけて[〜＃〜] npm [〜＃〜]リポジトリを検索してください。あなたが今やろうとしていることを、いくつのパッケージが既に実行しているかに驚くでしょう。
- あなたがプロジェクトに取り組んでいる唯一の人であっても、Gitのようなバージョン管理システムを使用し、コーディング基準厳格すぎず、独断的ではありませんが、チームメイトも従うことができる優れたガイドラインを提供します。
- TypeScriptまたはES6を選択しても、JavaScriptのクラスレスOOPを理解している場合でも、Prototypal OOPは、特にデバッグ中に役立ちます。
私はC++開発者で、最近Web開発を始めました。大きなデスクトップアプリをWeb環境に移植しています。同じパターンを使用して、C++コードを構造化したのとまったく同じようにJavaScriptコードを構造化します。私は全部で25〜30個のファイルを持っていますが、最終的には必要に応じてクラビングして3〜5個に減らし、それらすべてを縮小します。
私にとって、変化したのは言語の良し悪しだけで、パラダイムではありません。 JavaScriptは、そのすべての欠点と不満のために、機能とOOPスタイルの素晴らしいブレンドです。これまでのところ、うまく機能しています。
最後に、JavaScriptを使用するとC++よりもはるかに簡潔なコードを記述できるため、JavaScriptを使用すると、JS以外の言語から大量のLOCを取得できる場合があります。これは、古い方法を使用していることが原因である可能性があります。この問題に対処すると、実際には異なるはずのものが何も表示されません。デザインとアルゴリズムは、結局のところ言語にとらわれません。
もちろん、プロジェクトによって大きく異なりますが、一般的に受け入れられている慣行は、ライブラリまたはモジュールとして機能することを目的としたものについては、それらを単一の大きなファイルに入れ、カプセル化を使用して内部（「プライベート」）を防ぐことです。 ）外部への漏出からのインターフェース。また、ライブラリ/モジュールを使用する開発者にとっても役立ちます。コピーして貼り付けるフォルダとファイルの階層全体ではなく、アプリケーション構成またはヘッダースニペットに追加する1つのファイルです。また、最小化とバンドリングにより、本番サイトではHTTPリクエストの数を減らすためにすべてが1つのファイルに結合される可能性が高いという事実も反映しています。
あなた自身のアプリケーションコードはこの慣例に従う必要はありません、そしておそらく従うべきではありません。アプリはそれを使用する唯一のアプリであるため、ファイルを追加する必要があるのは1回だけであり、最小化とバンドリングを処理するためにプラットフォームに頼ることができます。
JavaScriptを慣れ親しんだ方法でOOP=）で作成することはまだ可能であり、推奨されています。JavaScriptの最も重要なデザインパターンについて説明した優れた本を以下に示します。
https://addyosmani.com/resources/essentialjsdesignpatterns/book/
コードフレームワークをさまざまなファイルやモジュールに分割できるようにすることを主な目的とするJavaScriptフレームワークも数多くあります。作業している特定のフレームワークで1つのファイルにすべてのコードを含める必要がある場合は、必ず切り替えてみてください。
コードで作業する場合、通常、さまざまなコンポーネントがモジュールに分割され、それぞれが通常1つのクラスを実装し、それぞれが個別のファイルに存在します。制作中、これらのファイルは、Browserify（ http://browserify.org/ ）またはRequireJS toのようなものを使用して、1つのファイル（つまり、何千行ものコード行）にバンドルされます。 HTTPリクエストの数を減らすだけでなく、依存関係が正しい順序で読み込まれるようにする
これらのモジュールのクラスの実装方法に関しては、OOPとは基本的なメカニズムでは少し異なりますが、表面上ではそれほど異なりません。ES6ではclassキーワードも導入されているため、 MDNに関するこの記事は、開始するのに役立ちます： https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain
私は（Petriの）ネット要素と注釈を使用して、PDFフォームアプリケーション-Acrobat/JavaScript APIを使用するJavaScriptプログラムです。状況に応じて役立つ可能性があります。 。
図は、ネット要素の入出力関係と注釈の2つのフォームビューを確立するために使用されます。ダイアグラムとフォームビューに基づいて、PDFフォームアプリケーション用のJavaScriptプログラムを体系的に作成することができます。したがって、ソースコードの「読み取り」は、仕様と一致することを確認するために削減されます。ダイアグラムと2つフォームビュー。
私のソフトウェアの実装では、コンストラクターとプロトタイプを使用しています。パフォーマンスが問題になる場合は、プロトタイプをインスタンスメンバーに置き換えると、メモリ使用量が増える代わりにパフォーマンスが向上する可能性があります。配列も使用されます。パフォーマンスが問題になる場合は、直接参照が使用されます。
一部のプロパティはevalを使用して作成されます。非常に多くのプロパティを持つオブジェクトの場合、これによりソースファイル内のコードの量が減り、プログラマーによる入力の量が減ります。