ソフトウェアの品質を改善するために、定量化および標準化された方法でソフトウェアを開発する
では、なぜフロントエンドを体系的にする必要があるのでしょうか。私はいくつかの点があるかと思います：
- 以前、フロントエンドの複雑さはそれほど高くなく、静的なページを表示するだけで十分でしたが、技術の進歩に伴い、エンジニアリングに役立つツールを導入しないと、多くのアプリケーションがますます複雑になっています（googleドライブ、facebookなど）。エンジニアリングの手法を導入しないと、プログラムの開発は管理しにくくなるでしょう
- フロントエンドの開発が徐々に成熟しているため、フロントエンドエンジニアリング用のツール（gulp、webpackなど）を開発する余裕があります。
実際、フロントエンドエンジニアリングは、「ああ、エンジニアリングを今すぐやろう」みたいな流行語ではありませんが、開発中は「ああ、できるなら」のように感じられます。
今日は、フロントエンドエンジニアリングを行う際の一般的な概念と構築ツールをいくつか紹介します。
Webpack
大規模なフロントエンドプロジェクトの中で、webpackはほとんど不可欠なツールです。
JavaScript初期の頃は、モジュールを管理する適切な方法がなく、モジュール化にするには、いくつかの設計パターンとエンジニア自身の経験などにしか頼ることができませんでした。
例として、モジュールをファイルで分けると、すぐに次のような依存関係の問題が発生します。
<script type="text/javascript" src="a.js"></script>
<script type="text/javascript" src="b.js"></script>
<script type="text/javascript" src="c.js"></script>
<script type="text/javascript" src="d.js"></script>
仮にdはa、b、cに依存するとして、順番が変更されるとバグが爆発します。時間が経つにつれ、全員が同じ場所ですべてをモジュール化することを望まなくなります。
依存関係メソッドを定義するCommonJSやRequireJSなどのいくつかのソリューションがあり、ライブラリを使用して依存関係の問題を解決できました。
ただし、まだいくつかの問題があります。
- 依存関係は自分で宣言する必要があります
- 動的インポート（Dynamic Import）を実行する場合、あまり解析する方法はない
webpackが登場した後、非常に強力なので、すぐに開発者に好まれました。
JavaScriptファイルに加えて、ローダーが設定されている限り、画像、フォントファイル、CSSなどをロードすることもできます。
Tree Shaking
初めてこの言葉を見たときは、すごくかっこよくて、概念的に考えやすかったと思いますね。木を振ると枯れ葉が落ちてしまいました。
ここで、枯れ葉の実は不要なコードを指します。ツリーの揺れとは、プログラムを作成するときにモジュールコードの一部しか使用しないことがあるため、ファイル全体をバンドルする必要がないことを指します。バンドルサイズを小さくすることができます。
このコードがほかの部分も使用されていないことをどのように知るかのを問題です。
一般的な静的言語では、コンパイラーに依存してこれを行うことができますが、JavaScriptでは、自分自身にのみ依存できます。幸い、webpack2後、開発者のためにツリーシェーキング関数を追加しましたが、静的に分析できるようにするためにes6インポートの構文に依存しています。
デッドコードの排除（dead code elimination）
以下のような絶対に実行しないコードを削除することができ、略してDCEと呼ばれます。
`` `javascript
if（false）{
// コード
}
条件は`false`のため、コードをここで実行することはできず、トランスパイルを実行するときにプラグを抜くことができます。
詳細については、Danの[開発モードの仕組み](https://overreacted.io/how-does-the-development-mode-work/)を参照してください。
## コード分割（Code Splitting）
コード分割の主な目的は、アプリケーションのコードとサードパーティライブラリのコードを2つのファイルに分割することです。
通常、使用するThird Partyのコードは、バージョン番号が変更のない限りほとんど変更されません。これらのコードをパッケージに分解し、CDNにアップロードしてキャッシュを有効にすることができるため、変更がある部分がリロードすることができます。アプリケーション自体のコードだけ、将来バージョン番号が変わったときに、ハッシュメカニズムで簡単に更新できます。
## 最小化
開発中は、目的を理解するために他の人（そして私たち自身）が理解できるように変数に明確な名前を付けますが、本番環境のビルドでは必要ありません。このとき、変数名を最小限に抑えることができます。
前述のように、パラメーターを渡す方法により、パラメーターで使用されているパラメーターを明確に把握できるだけでなく、最小化するのにも便利です。
## 動的なインポート(dynamic import)
ユーザーがホームページをロードするだけの場合、プロファイルページに入る必要がない場合があります。
したがってホームページに関連するコードのみをロードし、ユーザーがプロファイルページにアクセスしたときにコードをロードします。
## まとめ
Webpack構成ファイルは、使いやすい構成ファイルを書き込むのは非常に困難で、テストとパラメーターの調整に多くの時間がかかります。
完璧な構築メカニズムが必要な場合は、さまざまなプラグインを研究するのに長い時間がかかることがあります。もちろん、時間をかけて作図ツールを勉強すれば異なる意見を持つでしょう。設定の時間を節約したい場合は、`create-react-app`または`vue-cli`やその他のエコシステム構築ツールを使用することもできます。
ほとんどの設定は実際には同じですが（フロントエンド開発セクションで）、ニーズと使用条件に応じて異なる調整が必要になる場合があります。
さらに、アップグレードは非常に面倒な場合があります。たとえば、webpackのアップグレード時に、重大な変更が頻繁に発生します（それほど重大ではありませんが）。構成ファイルを変更するための調査にさらに時間がかかります。
記事のタイトルはフロントエンドエンジニアリングに関するものですが、この記事では主に構築ツールとそれに対応する概念について説明しました。