HHVMの型チェッカーを「最速」で回す――大規模モノレポにおけるモジュール分割の極意
こんにちは。HHVMアーキテクチャの深淵を覗き込んでいる皆さん、ようこそ。
Hack言語の魅力は、何といっても「型による絶対的な安全性」と「HHVMによる爆速実行」ですよね。しかし、コードベースが数百万行を超えるモノレポになると、型チェッカー（`hh_client`）との戦いが始まります。「コードを一行変えるたびに数分待たされる……」そんな経験はありませんか？
今日は、Hackの型チェッカーを最大限に高速化し、開発体験（DX）を劇的に向上させるための「コード分割のアーキテクチャ」について、深掘りしていきましょう。
—
1. なぜ型チェックは「重く」なるのか？
型チェックが遅いのは、チェッカーが「依存関係の全貌を解析しようとするから」です。Hackの型システムは強力ですが、AというファイルがBをインポートし、BがCを……と繋がっていくと、チェッカーは依存グラフの深淵まで探索し、矛盾がないかを確認し続けます。
この「探索範囲」を最小化することが、高速化の鍵となります。
脳内イメージ：巨大な糸電話
モノレポ全体が一つの巨大な塊だと、一つの糸を弾くだけで全域に振動（再計算）が伝わります。これを、小さな「独立した箱」に分けることで、振動の伝播を遮断するのです。
—
2. 実践：モジュール分割の戦略
型チェッカーを高速化するための基本戦略は、「依存関係の一方向化」と「インターフェースの抽象化」です。
悪い設計（密結合）
// User.hack
// 決済、通知、ログ、すべてに依存している
class User {
public function process(Payment $p, Mailer $m, Logger $l): void { … }
}
この状態だと、`Payment`を少し直すだけで`User`の型チェックが走り、さらには`User`に依存するすべてのクラスまで再チェックが走ります。
良い設計（疎結合・インターフェース分離）
// 依存をインターフェースに限定する
interface IPaymentProcessor {
public function pay(int $amount): void;
}
class User {
// 具体的な実装ではなく、抽象に依存させる
public function __construct(private IPaymentProcessor $payment) {}
}
このように「具体的なクラス」ではなく「インターフェース」を境界線にすることで、型チェッカーはインターフェースさえ変わらなければ、その裏側の実装を再チェックする必要がなくなります。
—
3. 陥りやすい罠：`mixed`型と型推論の過信
型チェッカーを高速化しようとするあまり、安易に`mixed`型に逃げていませんか？
// 危険なコード例
function processData(mixed $data): void {
// ここで型推論を諦めると、チェッカーは「推論」を放棄し、
// 後続の解析にコストをかけます
}
実は、型を曖昧にすることは、チェッカーにとって「ここで解析を止めてくれ」という信号にはなりません。むしろ、`mixed`から何らかの型へ絞り込むためのチェック（`is`演算子や`as`キャスト）が大量に発生し、逆に解析負荷を高めることがあります。
「型を明示する」ことは、チェッカーへの「道しるべ」です。 迷わせないコードは、必然的に速くチェックが終わります。
—
4. モジュールを分割する際の「黄金ルール」
大規模プロジェクトで型チェック時間を削るための、現場レベルのチェックリストです。
- 依存関係をグラフ化せよ: 循環参照は型チェッカーの最大の敵です。`A -> B -> A` となっている箇所があれば、即座にリファクタリングして断ち切りましょう。
- 名前空間（Namespace）を境界に: 適切な名前空間の分割は、型チェッカーのキャッシュ効率を向上させます。
- 型定義専用のファイルを分ける: 定数やType Aliasを一つの巨大なファイルに詰め込まず、機能単位で小さなファイルに分散させてください。
—
最後に：型チェッカーは「敵」ではなく「相棒」
皆さんが書くHackのコードが型チェッカーを迷わせないとき、HHVMは驚くほどの速さで答えを返してくれます。大規模なモノレポであっても、アーキテクチャさえ正しければ、型チェックの待ち時間は数秒以下に抑えることが可能です。
型を厳格に定義することは、単なる制約ではありません。それは、「自分自身が、どのモジュールに何の影響を与えているかを明確にする」という、エンジニアとしての責任ある対話です。
ここをマスターすれば、皆さんはもうHackの初学者ではありません。大規模アーキテクチャの設計者への第一歩です。自信を持って、より速く、より堅牢なコードを書いていきましょう！
また次回の講義でお会いしましょう。質問があれば、いつでもコードベースの奥深くからコメントを送ってくださいね。