継承された「var」の呪いと、ブロックスコープがもたらすメモリの解放
JavaScriptという言語は、歴史的な経緯から「あえて壊さない」という哲学のもとに進化してきた。しかし、その甘えが現場のエンジニアにとって致命的なバグの温床となることは、もはや周知の事実だ。特に、`for`ループと非同期処理、そしてかつての絶対王者`var`の組み合わせが引き起こす「クロージャの罠」は、今なおレガシーコードの墓場から我々を嘲笑っている。
今日は、単なる文法の違いではなく、ブラウザのメモリ管理やイベントループの挙動という「深淵」から、この問題を解剖していこう。
1. `var`が引き起こす「共有されたメモリ」の悲劇
まずは、この悪名高いコードを見てほしい。
// 多くのジュニアエンジニアが最初に踏み抜く地雷
for (var i = 0; i < 3; i++) {
setTimeout(() => {
console.log(`現在の値: ${i}`);
}, 100);
}
// 実行結果は 3, 3, 3 になる。なぜか？
なぜこうなるか？ `var`にはブロックスコープが存在せず、関数スコープ（あるいはグローバルスコープ）に束縛されるからだ。`i`はループのたびに新しいスコープを作らず、同じメモリ領域を使い回す。`setTimeout`のコールバックが実行される頃には、ループは既に完了しており、`i`は無情にも終了条件である「3」で止まっている。
これは単なるバグではない。「意図しない外部変数の参照」というメモリ管理上の汚染だ。
2. `let`による「イテレーションごとの独立」という革命
ES6で導入された`let`は、ただの「新しい変数宣言」ではない。これは、「各イテレーションごとに新しい環境レコード(Environment Record)を生成する」という、ブラウザエンジンの実装レベルでの劇的な変更を意味している。
for (let i = 0; i < 3; i++) {
// ここで宣言された i は、このブロック内だけの孤立した存在
setTimeout(() => {
console.log(`letなら安心: ${i}`);
}, 100);
}
// 実行結果: 0, 1, 2
このとき、エンジン内部では各ループの反復ごとに「別の`i`」がメモリ上に確保されている。これにより、クロージャがキャプチャするのは「現在のイテレーションの`i`」となり、非同期処理の競合は見事に回避される。
3. パフォーマンスとメモリ効率の「隠れたコスト」
「じゃあ全部`let`や`const`にすればいいのか？」という問いに対して、アーキテクトとしてはこう答える。「基本はそうだが、極限のパフォーマンスを求めるなら挙動を理解せよ」と。
- メモリの断片化とGC（ガベージコレクション）:
`let`はイテレーションごとに新しいスコープを作るため、ループ回数が数万回に及ぶような超巨大なデータ処理では、意図せずメモリ消費量が増大する可能性がある。とはいえ、現代のV8エンジンは非常に優秀だ。この程度のオーバーヘッドを気にする前に、ループ内での不要なオブジェクト生成やDOM操作を削減する方が、レンダリング負荷を下げる上では100倍重要だ。
- 巻き上げ（Hoisting）の真実:
`var`の巻き上げは`undefined`で初期化されるが、`let`は「一時的死域（TDZ: Temporal Dead Zone）」に置かれる。このTDZの存在は、初期化前の変数アクセスをランタイムエラーとして即座に検知できるため、コードの堅牢性は圧倒的に向上する。
4. 実務で「罠」を避けるための防衛的アーキテクチャ
現場で「なぜか値がおかしい」というバグに直面したとき、私は以下の順序でコードを診断する。
1. 即時関数（IIFE）の廃止: かつて`var`のスコープを閉じるために使われていたIIFEは、もう不要だ。`const`と`let`に置き換え、コードのネストを浅くせよ。
2. 不変性の担保: ループ内で変数を更新する必要がないなら、迷わず`const`を使う。再代入を防ぐことは、バグの発生確率を数学的にゼロに近づける唯一の手段だ。
3. 非同期のイテレーション: もしループ内で`await`を多用するなら、`Promise.all`と`map`を組み合わせるのが定石だ。
// プロフェッショナルな非同期処理の作法
const tasks = [1, 2, 3];
async function processTasks() {
// mapでPromiseの配列を作り、一気に捌く。これがレンダリングを止めない最適解
await Promise.all(tasks.map(async (i) => {
const result = await heavyOperation(i);
console.log(result);
}));
}
結論：技術は「道具」ではなく「哲学」
`var`か`let`かという議論は、単なる好みの問題ではない。それは「メモリをどう管理し、副作用をどう封じ込めるか」というアーキテクトとしての矜持に直結する。
JavaScriptの歴史的な負債を理解しつつ、現代的なブロックスコープを使いこなす。そうして初めて、我々はブラウザという不安定な実行環境の上で、堅牢で美しいアプリケーションを構築できるのだ。
さあ、エディタを開こう。そして、君のコードに潜む無駄な`var`を、すべて過去の遺物へと変えてやるんだ。
コメント