大規模なJavaScriptアプリケーションの構造はどのようになっていますか？

最近、OBIEE Mobile App Developer用に記述されたJavaScriptプラグインと、さまざまなプロジェクト用のカスタムライブラリを紹介しました。

OOPのバックグラウンドから来て、私はこれらのプロジェクトの構造について少し混乱しています。何千行ものファイルが表示されています。私は物事をファイルとクラスに分割することに慣れていますが、これは別のフレームワークであることを理解しています-たとえば、ファイルサイズが問題です-しかし、それをすべて行うより良い方法が必要ですか？

スクリプトの長さは、読みやすさと保守性だけでなく、プログラムの動作に関する個人の一般的な理解にも影響します。

大規模なアプリケーションはどのように構成されていますか？このための一般的なOOP設計パターンはありますか？

JavaScriptパターンに慣れていない場合、大規模なアプリケーションやライブラリの多くがRevealing Module Patternを使用していることを伝えることができますが、ニーズに応じて使用できるパターンは他にもたくさんあります。

ただし、明らかにするモジュールパターンは、大きなファイルを分割して論理的に整理するための優れた方法を提供するはずです。あなたがJavaScriptで任意のデザインパターンで作業しているときしかし、あることに注意してください、これは非常に混乱になることができます。this、new、prototype、.call()および.apply()賢明な使用を試みてください。

大規模なプロジェクトで作業しているとき、これらは次の場合にも役立ちます。

• 可能であれば、TypeScriptまたはES6に切り替えます。
• 書くモジュラーコードを。さまざまな方法とサードパーティのライブラリがありますが、それらのいずれかが何もないよりはましです。
• タスクランナー/ビルドシステムを使用してタスクを自動化します。
• デザインパターンについてお読みください。これは良いスタートになるかもしれません。上で言ったように、Removing Module Patternは非常に便利です。特に、人気のあるすべてのパターンを習得する時間が必要だと思う場合は特に便利です。
• ライトユニットテストを。動的言語での作業はより困難な場合があります。アプリケーションの重要な部分をテストすると、多くの時間を節約できます。
• コードの記述とバグの検出の両方で実際に役立つIDEまたはテキストエディタを使用します。WebStormは良い選択です。崇高なテキストも。
• IDEがデバッガを提供していない場合は、お気に入りのWebブラウザのデバッガをマスターしてみてください。
• ライブラリを使用します。プロジェクトの性質に応じて、見つけることができる最高のサードパーティコードを採用するようにしてください。Webアプリケーションを作成している場合は、Angular、React、そして古き良きbackbone.jsをご覧ください。Node.jsアプリケーションを作成している場合は、時間をかけてNPMリポジトリーを検索してください。ちょうどあなたがやろうとしていたことをすでに何個のパッケージが行っているかに驚くでしょう。
• あなたがプロジェクトに取り組んでいる唯一の人であるとしても、Gitのようなバージョン管理システムを使用し、厳しすぎず、意見を表明するコーディング基準に従います。従う。
• TypeScriptまたはES6を選択し、JavaScriptのクラスレスOOPを理解している場合でも、特にデバッグ中にプロトタイプOOPが役立ちます。

私はC ++開発者で、最近Web開発を始めました。大規模なデスクトップアプリをWeb環境に移植しています。同じパターンを使用して、C ++コードを構造化したようにJavaScriptコードを構造化します。全部で約25〜30個のファイルがありますが、最終的には必要に応じてクラブを行い、すべてを縮小して3〜5個に減らします。

私にとっては、良くも悪くも変化したのは言語だけであり、パラダイムではありません。JavaScriptは、すべての欠点とフラストレーションのために、機能的なスタイルとOOPスタイルの素晴らしい融合です。これまでのところ、物事はうまく機能しています。

最後に、私が早い段階で気づいたことの1つは、JavaScriptを使用するとC ++よりもはるかに簡潔なコードを記述できることでした。この問題に対処すると、実際に異なるはずの何かは表示されません。設計とアルゴリズムは、結局言語にとらわれません。

もちろん、プロジェクトごとに大きく異なりますが、一般的に受け入れられている慣習は、ライブラリまたはモジュールとして機能することを目的として、それらを単一の大きなファイルに入れ、カプセル化を使用してその内部（「プライベート」 ）外部への漏れからのインターフェース。また、ライブラリ/モジュールを使用したい開発者にとっても役立ちます。コピーして貼り付けるフォルダやファイルの階層全体ではなく、1つのファイルをアプリケーション構成またはヘッダースニペットに追加します。また、最小化とバンドル化により、実稼働サイトではHTTP要求の数を減らすためにすべてが1つのファイルに結合される可能性が高いという事実を反映しています。

独自のアプリケーションコードはこのプラクティスに従う必要はありません。おそらく従うべきではありません。アプリを使用するのはアプリだけなので、ファイルを追加する必要があるのは1回だけで、おそらく最小化とバンドル化を処理するためにプラットフォームに頼ることができます。

コードで作業する場合、通常、さまざまなコンポーネントはモジュールに分割され、各モジュールは通常単一のクラスを実装し、各コンポーネントは個別のファイルに格納されます。実稼働中、これらのファイルは、Browserify（http://browserify.org/）やRequireJSなどを使用してHTTPリクエストの数を減らして、1つのファイルにまとめられます（そのため、数千行のコードが表示されます）。依存関係が正しい順序でロードされるようにするためにも

これらのモジュールのクラスがどのように実装されるかについては、基礎となるメカニズムの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を使用して作成されます。非常に多くのプロパティを持つオブジェクトの場合、これによりソースファイル内のコードの量が減り、プログラマによる入力の量が減ります。

あなたが慣れているOOPの方法でJavaScriptを書くことはまだ可能であり、推奨されます。JavaScriptの最も重要なデザインパターンを説明した優れた本を次に示します。

https://addyosmani.com/resources/essentialjsdesignpatterns/book/

多くのJavaScriptフレームワークもあり、主な目的はコードを異なるファイルやモジュールに分割できるようにすることです。作業している特定のフレームワークですべてのコードを1つのファイルに収める必要がある場合は、間違いなく切り替えを検討する必要があります。