コーディング面接：JavaScriptのIterator Helpersを使って遅延パイプラインを構築する方法

1. 質問と背景

数百万件のレコードを含む可能性のある同期イテレータを処理する必要があります。無効な行をフィルタリングし、ビューモデルにマッピングし、先頭100件を取得して合計金額を計算します。元のコードでは、map、filter、reduceを呼び出す前にソースを配列へと展開（spread）していたため、メモリのピークが高くなっていました。これをJavaScriptのIterator Helpersを使って書き直し、遅延性、イテレータプロトコル、早期終了、クリーンアップ、および古いランタイム向けのフォールバックについて説明してください。

2. 面接官が見ているポイント

IteratorとIterableの違いを理解しており、Iterator Helpersがさらに消費可能なイテレータを返すことを理解しているか。
map、filter、take、find、reduce、toArrayを遅延パイプラインとして組み合わせられるか。
イテレータは状態を持ち、通常は前方に一度しか進まないこと、そして早期終了によって基盤となるreturnメソッドにクリーンアップの機会が与えられることを知っているか。
無限ソースやコストの高いソース、例外、互換性、および配列の実体化が適切な境界を適切に扱えるか。

3. 回答前に確認すべき質問

ソースは同期Iterator、Iterable、または非同期ページネーションAPIのどれですか？
結果は1つの配列として返さなければなりませんか？それとも呼び出し側がストリームとして消費し続けることができますか？
N件の結果を取得した後、ネットワーク、ファイル、またはデータベースのカーソルをクローズする必要がありますか？
対象となるNodeおよびブラウザのバージョンはネイティブのIterator Helpersを提供していますか？またポリフィルの使用は許可されていますか？

4. 30秒の回答フレームワーク

まずIterableをIteratorに正規化し、filter、map、takeをチェーンさせ、配列が真に必要な境界でのみtoArrayを呼び出します。mapやfilterは即座に走査を行わず、reduceやtoArrayが消費を開始します。takeが上限に達すると、パイプラインは値の取得（pull）を停止し、リソースが解放されるようイテレータのクローズ処理を実行する必要があります。イテレータは状態を持つため、コンシューマ間で安易に共有すべきではありません。古いランタイムでは、同じセマンティクスを持つ制御されたポリフィルやジェネレータ実装を使用し、例外、早期終了、大規模ソースに対するメモリ使用量をテストします。

5. ステップバイステップの詳細な回答

ステップ 1: IteratorとIterableを区別する

IterableはIteratorを生成できるSymbol.iteratorメソッドを提供し、Iteratorはnextを提供してdoneとvalueを返します。Iterator.fromは反復プロトコルに従う入力を正規化します。Iterator Helpersはイテレータ上で動作し、遅延ヘルパーを作成します。ソース全体を自動的に配列へコピーすることはありません。

ステップ 2: 遅延map、filter、takeパイプラインを構築する

以下の関数は、結果が消費されている間だけソースを読み込みます。filterが行をチェックし、mapが変換を行い、takeが要求された件数後に停止するため、無関係なレコードが取得されることはありません。

function topAmounts(source, limit) {
  return Iterator.from(source)
    .filter((row) => row.status === "paid")
    .map((row) => ({ id: row.id, amount: row.cents / 100 }))
    .take(limit);
}

const firstHundred = topAmounts(records(), 100).toArray();

ステップ 3: 消費のタイミングとワンパスの状態を理解する

ヘルパーを作成しただけではコールバックは呼び出されません。nextをプルするか、forEach、find、reduce、またはtoArrayを呼び出すことで、ソースの値が消費されます。イテレータは現在位置を保持しているため、最初のコンシューマが状態を変更すると、2番目のコンシューマには消費し尽くされたイテレータが見えることがあります。消費済みのインスタンスを共有するのではなく、独立した結果を得るためには新しいソースイテレータを作成してください。

ステップ 4: 早期終了、return、例外を処理する

takeやfindなどの操作は、結果が得られた後に停止できます。基盤となるイテレータがreturnを提供している場合、ヘルパーは完了時や失敗時にファイルハンドルやページカーソルなどのリソースをクローズする機会を与える必要があります。ビジネスロジック側でもfinally内で自身が所有するリソースを解放し、コールバックが例外をスローしたりコンシューマが早期終了したりした際のクリーンアップを検証する必要があります。

ステップ 5: 実体化の境界とフォールバックを選択する

toArrayは残りの結果を実体化するため、ランダムアクセス、シリアライズ、または一括レンダリングで配列が必要な場所にのみ配置します。無限イテレータ、大きなページ、コストの高い計算は遅延状態のまま維持すべきです。ランタイムにネイティブのIterator Helpersがない場合は、map、filter、takeに対して制御されたポリフィルまたはジェネレータラッパーを使用します。ワンパス消費、早期終了、例外の伝播を維持し、すべてのソースを密かに配列へ変換しないようにしてください。

6. 質の高い模範解答

Iterator.fromで入力を正規化し、filter、map、takeをチェーンさせ、配列が必要な出力境界でのみtoArrayを呼び出します。ヘルパーのコールバックは消費中に実行されるため、大規模なソースが早期に展開されることはありません。takeやfindは値の取得を停止し、基盤となるカーソルがクローズできるようにreturnを使用する必要があります。イテレータは状態を持ち、通常は1回しか使えないため、独立した結果を得るには新しいソースイテレータが必要です。古いNodeやブラウザに対しては、同じ遅延・クローズのセマンティクスを持つポリフィルやジェネレータ実装を使用し、例外、早期停止、リソース解放、およびメモリピークをテストします。

7. よくある間違い

最初にソースを展開（spread）してしまう → ソース全体が実体化される → 本当に配列が必要な境界にのみtoArrayを留める。
mapの作成時にコールバックが実行されると思い込む → セットアップ中に副作用は発生しない → 消費が値のプルをトリガーすることを説明する。
1つのイテレータを再利用する → 2つ目の結果が空または不完全になる → コンシューマごとに新しいソースを作成する。
takeの後にページの要求を継続してしまう → ネットワークやリソースが無駄になる → 早期終了が基盤となるreturnを呼び出していることを検証する。
配列の結果をコピーするだけのポリフィルを作成する → 無限ソースや例外のセマンティクスが変わってしまう → 遅延性、ワンパス状態、例外の伝播を維持する。

8. フォローアップ質問と回答

フォローアップ 1: Iterator Helpersと配列メソッドの主な違いは何ですか？

配列メソッドは既に実体化された配列に対して動作し、通常は即座に走査を行います。Iterator Helpersはイテレータを受け取り、map、filter、takeなどの遅延変換を行い、コンシューマが要求した要素のみをプルします。

フォローアップ 2: それでもtoArrayを呼び出すべきなのはどのような場合ですか？

ランダムインデックスアクセス、シリアライズ、配列しか受け付けないバッチAPI、または小規模な1回限りのレンダリングなど、境界で配列が必要とされる場合に呼び出します。膨大または無限のソースに対して実体化することは避け、遅延消費を維持してください。

フォローアップ 3: なぜイテレータを安易に再利用してはならないのですか？

イテレータはカーソルを保持しており、nextによって内部状態が変化するためです。1つのコンシューマが読み取った後、2番目のコンシューマは残りの位置から受け取ることになります。再実行するにはIterableから生成された新しいイテレータが必要です。

フォローアップ 4: 早期終了によってリソースが解放されることをどのように検証しますか？

プル回数をカウントし、returnの呼び出しを記録するテスト用イテレータを使用します。takeまたはfindの後、値のプルが停止し、returnが実行されたことをアサートし、コールバック例外やコンシューマの中断ケースもカバーします。