厳格モード（strict mode）が守る、JavaScriptアーキテクチャの防波堤
モダンなフレームワークがブラックボックス化を進める中、あえてJavaScriptの「原始的な挙動」を語ることには意味がある。なぜなら、V8やSpiderMonkeyといったブラウザエンジンが解釈するコードの基礎体力が、アプリケーションの堅牢性を決定づけるからだ。
今回は、現代の開発において空気のように存在しているはずの `’use strict’` が、なぜアーキテクチャの観点で「絶対的な正義」なのかを、泥臭い内部挙動と絡めて解き明かそう。
—
1. 暗黙のグローバル変数は、静かなる破滅の入り口
JavaScriptの歴史的経緯が生んだ最大級の負債が「暗黙のグローバル変数」だ。`var`を忘れ、あるいはタイポをして代入を行った瞬間、エンジンはそれをグローバルオブジェクト（ブラウザなら`window`）のプロパティとして生成する。
‘use strict’;
function calculateMetrics() {
// 厳格モード下ではReferenceErrorがスローされる
// これにより、意図しないスコープ汚染をコンパイル/実行時に即座に検知できる
data = { score: 100 };
}
この「暗黙の生成」は、小規模なスクリプトでは無視できるかもしれない。しかし、複雑な非同期処理が絡み合うSPA（Single Page Application）において、意図せぬグローバル変数はメモリリークの温床となる。ガベージコレクタ（GC）はグローバルオブジェクトから参照されているオブジェクトを「生存している」と見なすため、いくら関数が終了してもメモリが解放されないのだ。
2. スコープの境界線を強制する「厳格」という規律
厳格モードは、単にエラーを出すためのルールではない。エンジンの最適化パスを有利に進めるための「宣言」でもある。
`this` の挙動と非同期競合
非同期コールバックやイベントハンドラにおいて、`this` がグローバルオブジェクトを指してしまう挙動は、多くのエンジニアを悩ませてきた。`’use strict’` は、関数がメソッドとして呼び出されない限り `this` を `undefined` に固定する。
‘use strict’;
function contextGuard() {
// 通常モード: windowオブジェクトが返る（危険な挙動）
// 厳格モード: undefinedが返る（早期リターンやデバッグで即座に気づける）
console.log(this);
}
contextGuard();
この挙動は、非同期処理の競合を防ぐための防波堤になる。`undefined`であれば、誤ったスコープでのプロパティ操作に対して即座に例外が飛ぶ。一方で、`window` を参照してしまうと、アプリは沈黙したままバグを抱え込み、レンダリング負荷や予期せぬDOM操作を引き起こす。
3. 最適化パスと内部挙動
V8のような現代のJIT（Just-In-Time）コンパイラは、コードの「静的な構造」を極めて重視する。`’use strict’` を指定することで、エンジンはコードの曖昧さを排除し、よりアグレッシブな最適化を行えるようになる。
特に重要なのは「変数へのアクセス」だ。
- 名前解決の高速化: 厳格モードでは `with` 文が禁止される。`with` 文は実行時にスコープチェーンを動的に拡張するため、コンパイラが変数の格納先を特定できず、最適化の足を引っ張る。
- 巻き上げの予測可能性: `var` による巻き上げの混沌を避け、`let`/`const` と組み合わせて厳格モードを用いることは、エンジンの隠しクラス（Hidden Classes）の生成を安定させ、プロパティアクセスのオーバーヘッドを最小化する。
4. 実務レベルで「厳格」を運用するアーキテクチャ
今さら言うまでもないかもしれないが、ES Modulesを利用しているなら心配はいらない。ESMはデフォルトで厳格モードが適用されているからだ。しかし、レガシーなビルドパイプラインや、IIFE（即時関数）を多用する環境では、今一度以下の運用を徹底してほしい。
// モジュール単位での強制
(function() {
‘use strict’;
// 1. 重複プロパティの禁止: オブジェクトリテラルでの重複キーをエラーにする
// 2. 引数の重複禁止: 関数定義の重複引数をエラーにする
// これらは、意図せぬデータの上書きをコンパイルレベルで阻止する
const config = {
api: ‘v1’,
api: ‘v2’ // 厳格モード下ではSyntaxError
};
})();
結論：コードの「健全性」を機械に委ねる
厳格モードとは、人間が書く「曖昧なJavaScript」を「計算機が解釈可能な厳密なロジック」へと強制的に変換する儀式だ。
パフォーマンス最適化とは、単にアルゴリズムをいじることではない。「エンジンが迷いなく、最速で実行できる構造を提供すること」に他ならない。`’use strict’` は、その構造を維持するための最も低コストで、かつ強力なアーキテクチャ上の制約だ。
バグが発生してからデバッグに時間を費やすのではない。バグが生まれる余地そのものを、言語仕様の境界線で切り捨てる。それこそが、伝説的なコードベースを維持する唯一の道であると、私は確信している。
コメント