『Any』型を排除する：レガシーコードをStrict Modeへ引き上げるためのリファクタリング術
HHVM（HipHop Virtual Machine）のアーキテクチャ、そしてHack言語の核心にあるのは「妥協なき静的型付け」だ。
PHPの動的な柔軟性を捨て、型チェッカー（`hh_client` / `hh_server`）による厳密な型安全性を手に入れた我々にとって、コードベースに潜む `mixed` や、型推論の放棄によって生じる暗黙の `any` 的挙動（かつてのHHVMの遺物や不十分なアノテーション）は、パフォーマンスと堅牢性に対する最大の脅威である。
今回は、大規模なHackコードベースを完全な `// strict` モードへ移行させ、HHVMのJITコンパイラが真の最適化を発揮できる状態を作り上げるための極限の知見を共有する。
—
1. ランタイムと型チェッカーの裏側：なぜ `// partial` は遅く、`// strict` は速いのか
Hackのコードベースには、主に `// partial`（デフォルト）と `// strict` の2つのモードが存在する。
シニアエンジニアであれば、この違いが単なる「エラーの厳しさ」ではなく、HHVMのトランスレータとJITコンパイラの挙動を根本から変えるスイッチであることを知っているはずだ。
緩い型付けが招く仮想マシンのオーバーヘッド
`// partial` モードでは、型チェッカーが型を解決できない箇所について、実行時型チェック（Runtime Type Checking）やボクシング（Boxing）のコードが生成されるか、あるいは `Cell` 共用体を用いた動的なディスパッチが多用される。
これにより、以下のコストが発生する。
- メモリフットプリントの増大: プリミティブ型（`int`, `float`, `bool`）がネイティブなレジスタサイズで扱われず、型タグを持つ `TypedValue` 構造体（Cell）としてヒープやスタックに保持されるため、キャッシュ効率が低下する。
- JITの最適化阻害: TC（Translation Cache）内での型ガード（Type Guard）の数が爆発し、AOT（Ahead-Of-Time）に近いネイティブコードへのコンパイル効率が落ちる。
Strict Modeが生み出す極限のハードウェア効率
一方、`// strict` モードでは、すべての式、変数、プロパティ、パラメータ、戻り値に型が完全に確定していなければならない。
これにより、HHVMのバイトコードジェネレータは、動的な型解決のコードを完全に排除し、CPUのネイティブ命令に直結する最適化されたバイトコードを出力できる。プロパティのオフセットはコンパイル時に確定し、メソッド呼び出しのVtableルックアップも最小限に抑えられる。
—
2. 移行の最大の壁：暗黙の型不明（Any/Mixed）の特定と可視化
レガシーなHackコードベースを `// strict` へ引き上げる際、最大の障害となるのは「どこに型推論の穴があるか」の特定だ。
IDEの補完に頼るだけでは、大規模プロジェクトの海に溺れる。ここで使うべきは、`hh_client` の内臓機能と静的解析のパイプラインだ。
`hh_client –json` による型カバレッジの測定
まず、コードベース全体あるいは特定ファイルの型安全性の度合いを定量化する。
JSON形式でエラーや型情報の統計を出力する
hh_client –json
特に、型チェッカーが型を特定できずに `mixed` や推論不能とみなしている箇所をあぶり出すためには、以下のエラーコードに注目する。
- HH1002: Typehint required（型ヒントが欠落している）
- HH4101: Invalid method call on a non-object（動的呼び出しの検知）
—
3. 段階的リファクタリングの実践手順
一気に全ファイルを `// strict` に書き換えるのは、プロダクション環境においては自殺行為だ。
以下の3ステップで、安全かつ確実に要塞を築き上げる。
ステップ A: 境界領域（Boundary）の定義
外部入力（HTTPリクエスト、データベース、外部API）の境界線では、データは本質的に動的である。ここをどう扱うかが設計の分かれ目となる。
アンチパターン（レガシーな記述）:
<<__EntryPoint>>
function legacy_entry_point(): void {
$data = $_GET[‘payload’]; // mixed
process_data($data);
}
function process_data(mixed $data): void {
// ここで何でも受け取ってしまうため、型チェッカーが機能しない
echo $data[‘id’];
}
極限の対策（Strict Modeでの境界防衛）:
外部からの入力を受け取る境界では、必ず形状（Shape）や `darray` / `dict` の型アサーション、あるいは `TypeStructure` を用いたランタイムバリデーションを行う。
// strict
namespace HackEngineering\Security;
type PayloadShape = shape(
‘id’ => int,
‘name’ => string,
);
class BoundaryGuardian {
public static function processInput(mixed $raw_input): ?PayloadShape {
// 厳密なランタイムチェックを行い、型安全なShapeに昇格させる
if (!is_dict($raw_input)) {
return null;
}
// 厳密なキー存在確認と型キャスト
if (Shapes::idx($raw_input, ‘id’) is int && Shapes::idx($raw_input, ‘name’) is string) {
// ここで完全に静的型が保証されたShapeとして確定する
return shape(
‘id’ => (int)$raw_input[‘id’],
‘name’ => (string)$raw_input[‘name’],
);
}
return null;
}
}
ステップ B: コレクションの厳格化（`array` から `vec`/`dict`/`keyset` へ）
PHP由来の曖昧な `array` 型（Hackでは非推奨、または特殊な扱いに移行しつつある）を、完全にジェネリックなコレクション型に置き換える。
リファクタリング前（Partial / 曖昧な配列）:
// どちらのキー・値かわからない曖昧な配列
function calculate_totals(array $items): float {
$total = 0.0;
foreach ($items as $item) {
$total += $item[‘price’];
}
return $total;
}
リファクタリング後（Strict / 完全なジェネリクス）:
// strict
namespace HackEngineering\Finance;
type Item = shape(
‘price’ => float,
‘quantity’ => int,
);
class OrderCalculator {
/
- vec
- を用いることで、HHVMの配列最適化（packed array）の恩恵を最大化する。
/
public static function calculateTotals(vec
$total = 0.0;
foreach ($items as $item) {
$total += $item[‘price’] $item[‘quantity’];
}
return $total;
}
}
メモリ最適化の知見: `vec` や `dict` は、HHVMの内部で高度に最適化された連続メモリ領域（あるいはハッシュマップ）として表現される。要素の型が完全に静的に決定している場合、コンパイラはコンテナ要素へのアクセスの際に余計なオーバーヘッドを取り除くことができる。
ステップ C: ファイルヘッダーの書き換えと最終防衛ライン
ファイル内のすべてのメソッド、関数、プロパティに型が付与されたら、ファイルの先頭を書き換える。
// strict
namespace HackEngineering\Core;
/
- このファイルは完全な Strict Mode で動作する。
- 型チェッカーは一切の妥協を許さず、HHVMは最高速のネイティブコードを生成する。
/
final class StrictProcessor {
public function __construct(
private readonly string $identifier,
private readonly int $version,
) {}
public function execute(): void {
// 完全に型安全な処理フロー
}
}
—
4. 自動化とCI/CDパイプラインへの統合
人間は怠惰な生き物であり、コードレビューだけですべての `// strict` 漏れを防ぐことは不可能です。リポジトリの品質を恒久的に維持するためには、CIパイプラインに型チェッカーの厳格な執行を組み込む必要があります。
以下のコマンドをCI（GitHub Actionsや社内CI）の必須タスクとして組み込んでください。
エラーが1つでもあれば非ゼロ終了コードを返す
hh_server –check
さらに、既存の `// partial` ファイルが新規に増えないようにするための静的解析スクリプトを導入し、コミットフックやPRの自動チェックで `// strict` 宣言の強制（あるいは既存ファイルの段階的引き上げ進捗率の計測）を行うのが、真にスケーラブルなコードベースを維持する唯一の解法です。
—
結びにかえて
Hack言語における `// strict` モードへの移行は、単なる「コードのきれいさ」を求めるエゴではない。それは、HHVMという極限まで最適化された仮想マシンのポテンシャルを極限まで引き出し、CPUキャッシュヒット率を高め、予期せぬ実行時エラー（TypeErrorなど）を宇宙から抹殺するエンジニアリングの極みである。
レガシーなコードベースの泥沼から目を背けず、型チェッカーという最強の剣を手に取り、すべてのファイルを `// strict` へと導いてほしい。そこに広がるのは、圧倒的な速度と美しさに満ちた、真に堅牢な世界だ。