【入門編】HHVM型チェッカーの『Incremental Check』を最大限活用するコード分割のベストプラクティス – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

こんにちは！Hack言語の世界へようこそ。
他のプログラミング言語からHackを学び始めると、その強力な静的型システムと、HHVM（HipHop Virtual Machine）が叩き出す圧倒的な実行速度に驚かされることが多いですよね。

でも、コードベースが数百万行規模に成長してくると、ある壁にぶつかります。そう、「型チェック（`hh_client`）の待ち時間」です。

「ちょっとしたタイポを直しただけなのに、なぜ型チェックに数秒（あるいは数十秒）もかかるんだろう……？」

ここをクリアすれば、Hackの恩恵を100%受けつつ、開発フィールを爆速に保つプロフェッショナルなモジュール設計がバッチリマスターできますよ。今回は、HHVM型チェッカーの心臓部である「Incremental Check（インクリメンタルチェック）」を極限まで引き出すコード分割のベストプラクティスを、優しく、そしてディープに解説していきますね。

—

1. HHVM型チェッカーは裏側でどう動いているのか？

まず、HHVMの型チェッカー（`hh_server`）がなぜ速いのか、その秘密を少しだけ覗いてみましょう。

通常のコンパイラは、コードを変更するとファイル全体を上から下までもう一度スキャンし直します。しかし、HHVMの型チェッカーは、メモリ上にコード全体の「依存関係グラフ（Dependency Graph）」を常駐させています。

[User.hack] ──(依存)──> [Database.hack] ──(依存)──> [Config.hack]

あなたが `User.hack` の中身を書き換えたとき、HHVMは「このファイルの変更が、他のどのファイルに波及する（影響を与える）か」をグラフ構造から瞬時に逆引きします。

これが Incremental Check（差分型チェック） です。
変更されたファイルと、それに直接・間接的に依存している最小限のノードだけを再評価するため、数万ファイルのプロジェクトでも一瞬で型チェックが終わるわけです。

—

2. だけど、依存関係が「スパゲッティ」になると…？

ここで問題が発生します。もし、あなたのコードベースで「あらゆるファイルが他のすべてのファイルを読み込んでいる（循環依存や巨大なハブファイルがある）」状態だったらどうなるでしょうか？

[GodObject.hack]
▲ ───┬─── ▲
│ │ │ (全ファイルが依存し合っている)
[A] [B] [C]

`GodObject.hack` をたった1行変更しただけで、HHVMの脳内では「すべてのファイルが壊れたかもしれない！全部再チェックだ！」と判定されてしまいます。これが、インクリメンタルチェックの恩恵が消え去り、型チェックが遅くなる最大の原因です。

これを防ぐためには、「依存の方向を一方向に保ち、モジュールを綺麗に隔離する」必要があります。

—

3. 実践！インクリメンタルチェックを最大化するモジュール設計

ここからは、具体的なコードと設計パターンを見ていきましょう。
厳格なモード（`<<__STRICT__>>`）を前提に、依存関係を美しくコントロールする例を作成しました。

よくない例：すべてを知る「巨大なコンテキストクラス」

<<__STRICT__>>

namespace App\Bad;

// このクラスにあらゆるビジネスロジックとDB接続が詰まっている
class ApplicationContext {
// ここを変更すると、アプリ全体の全ファイルが再チェック対象になる！
public static function getDbConnection(): \PDO {
// …
}

public static function calculateTax(float $price): float {
// …
}
}

このアプローチは、どこからでもアクセスできて一見便利に見えますが、HHVMのインクリメンタルチェックにとっては「核弾頭」のようなものです。このファイルをいじった瞬間に全ファイルの型チェックが走ります。

良い例：責任を分離し、インターフェースで依存を断つ

インクリメンタルチェックを味方につけるには、「変更されにくいコアな定義」と「頻繁に変更される実装」を切り離し、依存の矢印を一方通行にします。

<<__STRICT__>>

namespace App\Good\Contracts;

// 1. 変更が極めて少ないインターフェース（契約）を定義する
interface ITaxCalculator {
public function calculate(float $price): float;
}

<<__STRICT__>>

namespace App\Good\Services;

use namespace App\Good\Contracts;

// 2. 実装クラスはインターフェースに依存するが、他からこのクラスへの依存は最小限にする
final class StandardTaxCalculator implements Contracts\ITaxCalculator {
public function calculate(float $price): float {
return $price 0.10;
}
}

このようにコードを分割すると、`StandardTaxCalculator.hack` を修正しても、それに依存していない他のサービス（例えばユーザー認証モジュールなど）は、HHVMの依存関係グラフにおいて「再評価のスキップ対象」になります。結果として、型チェックの応答速度が劇的に向上します。

—

4. 陥りがちな文法エラーとアンチパターン

Hackでモジュール分割を進める際、初学者がよくハマるポイントをいくつか押さえておきましょう。

アンチパターン①：グローバル関数やトップレベル変数の乱用

Hackではファイルをまたいだトップレベルの関数や定数を定義できますが、これらは依存関係の追跡を曖昧にします。

// 避けるべき例 (global_constants.hack)
namespace App;

// これを変更すると、これを読み込んでいる全てのファイルの型チェックが強制されます
const int MAX_RETRY_COUNT = 3;

対策: 定数は可能な限りクラスの `const` や `enum` として定義し、スコープと依存先を明確に絞り込みましょう。

アンチパターン②：不必要な `type` や `newtype` の巨大な共通定義ファイル

「型の定義を一つにまとめよう」として、数百行のエイリアスが書かれた `types.hack` を作っていませんか？
そのファイルに手を加えた瞬間、プロジェクト全体のファイルが再チェックの対象になり、インクリメンタルチェックが完全に死んでしまいます。

対策: 型定義は、それを使用するモジュールの近傍（同じディレクトリやクラス内）に配置し、共有範囲を必要最小限に留めましょう。

—

ここをクリアすれば、Hackの基本はバッチリマスターできますよ！

HHVMの型チェッカーは依存関係グラフで差分チェック（Incremental Check）を行っている
巨大な共通ファイルや循環依存は、差分チェックの恩恵を台無しにする
インターフェースを活用し、変更の波及範囲を小さくするモジュール設計を心がける

Hackの厳格な静態型システムは、あなたのコードを堅牢にするだけでなく、正しい設計（関心事の分離）を優しく、しかし強制的に導いてくれる最高の相棒です。

モジュール間の依存関係を意識した美しいコードを書いて、快適な爆速Hackライフを楽しんでくださいね！それではまた！