「なぜ今さら『use strict』？」――プロの現場で生き残るための静かなる防波堤
フロントエンドの最前線でコードを書いていると、ついモダンなフレームワークやビルドツールに目を奪われがちだ。しかし、どれほどReactやTypeScriptで武装していても、ブラウザという「泥臭い現場」でJavaScriptがどう動いているのかという本質を見失ってはいけない。
今日は、あえて「`use strict`（厳格モード）」という、一見地味で古臭いと感じるかもしれないテーマに切り込みたい。なぜなら、これこそがJavaScriptの混沌とした歴史の中で、僕たちが「意図しないバグ」と戦うための最も強力な防波堤だからだ。
—
「暗黙のグローバル変数」という名の時限爆弾
`use strict`を語る上で避けて通れないのが、JavaScriptの「あまりに柔軟すぎる」挙動だ。
例えば、君がコードを書いている最中、うっかり変数宣言を忘れたとする。
// 厳格モードなしの世界
function calculateTotal() {
// あぁ、letを書き忘れた！
totalPrice = 100 1.1;
return totalPrice;
}
calculateTotal();
console.log(window.totalPrice); // 110 !! なぜかグローバルに漏れ出している
このコード、今のブラウザやNode.js環境なら「動く」んだ。でも、これこそが地獄の始まりだ。`totalPrice`という変数は、関数の中だけで完結するはずが、気づけば`window`（グローバル）オブジェクトにぶら下がっている。
大規模なプロジェクトになればなるほど、この「意図しないグローバル変数」は他のライブラリと競合し、再現性の低い不可解なバグを生む。`use strict`はこの甘えを一切許さない。
—
use strictが提供する「強制的な規律」
`’use strict’;` をファイルの先頭（あるいは関数の先頭）に置くだけで、ブラウザのJavaScriptエンジンは「お行儀の悪いコード」に対して即座にエラーを投げるようになる。
‘use strict’;
function calculateTotal() {
// 厳格モード下では、宣言なしの代入は ReferenceError を引き起こす
totalPrice = 100 1.1; // Uncaught ReferenceError: totalPrice is not defined
}
このエラーを見たとき、君はどう思うだろうか？「面倒くさい」だろうか。いや、違う。「バグが発生する前に、ブラウザが親切に教えてくれた」と感謝すべきなんだ。
現場で遭遇する「use strict」の恩恵
1. 静かなる代入失敗の検知: 読み取り専用プロパティへの代入や、拡張不可なオブジェクトへの追加に対し、黙殺せずにエラーを投げてくれる。
2. thisの安全性: 厳格モードでは、関数呼び出し時の`this`が`undefined`になる。従来のモードだと`this`が勝手に`window`を指してしまい、意図しないプロパティをグローバルに生成する原因になっていた。
3. 重複の禁止: 同じ名前の引数やプロパティが定義されていると、構文解析の時点でエラーを出してくれる。
—
実践：現代の現場における「use strict」の立ち位置
さて、ここで鋭い読者ならこう思うはずだ。「今はTypeScriptを使っているし、ES Modules（import/export）を使えば自動的に厳格モードになるから必要ないのでは？」と。
確かに、ES Modules環境下では暗黙的に`use strict`が適用されている。だが、「なぜそれが重要なのか」を理解しているか否かで、コードの品質は劇的に変わる。
もし君が古いレガシーなスクリプトをメンテナンスしたり、即時関数（IIFE）で独自のロジックをカプセル化するような場面に出くわしたら、こう書くべきだ。
/
- レガシーな環境や、特定のスコープを安全に保護したい場合のパターン
/
(function() {
‘use strict’; // この即時関数内を厳格モードに固定する
const config = {
apiEndpoint: ‘https://api.example.com’
};
// 誤って上書きしようとしてもエラーになるため安全
Object.freeze(config);
config.apiEndpoint = ‘wrong-url’; // 厳格モードならここで例外が発生し、事故を防げる
console.log(‘堅牢な処理が完了しました’);
})();
—
チーフアーキテクトからのアドバイス
JavaScriptという言語は、非常に「人間味」のある言語だ。開発者がミスをしても、それを何とか補正して動かそうとする。だが、その「優しさ」は、ときとして僕たちプロフェッショナルには「甘え」になり、技術的負債として積み上がる。
`use strict`を使うことは、「言語の仕様に頼るのではなく、自分自身のコードの整合性を担保する」というエンジニアとしての姿勢そのものだ。
もし今、君のプロジェクトに`use strict`がないのなら、まずは小さなモジュールからでも導入してみてほしい。そして、ブラウザが吐き出す「エラー」を、「仕事の邪魔」ではなく「最高のコードレビュー」として受け取ってみてくれ。
そうすれば、君が書くコードは、もっともっと強固で美しいものになるはずだ。現場からは以上だ。また何かあればいつでも聞いてくれ。
コメント