【実務・中級編】Strict Modeへの移行における『Partial Mode』の技術的負債：段階的移行の落とし穴 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

Strict Modeへの移行における『Partial Mode』の技術的負債：段階的移行の落とし穴

テックリードの私だ。コードレビューの最中、また見慣れない `mixed` の乱用や、型チェッカーの目を盗むようなキャストに遭遇した。

「まずは動かすために Partial Mode で書き始めたんですが……」

その言い訳は、技術的負債という名の爆弾を未来の自分たちにプレゼントしているに等しい。
Hack言語の真価は、その厳格な静的型システム（Strict Mode）と、それを超高速に実行するHHVMのJITコンパイルの融合にある。`1. なぜ Partial Mode は「麻薬」なのか？

Hackの最大の強みは、PHPの動的動作者から段階的に移行できることにある。だが、この「段階的移行（Partial Mode）」こそが、アーキテクチャを蝕むトロイの木馬だ。

Partial Mode (`

型推論が失敗した箇所は自動的に `mixed`（あるいはそれに準ずる緩い型）として扱われる。

存在しないメソッドの呼び出しも、実行時まで隠蔽されることがある。

結果として何が起きるか？ 「型安全のグラデーション」という名のカオスだ。Strictなコンポーネントが、Partialなコンポーネントから返される `mixed` に汚染され、アプリケーション全体に型安全の保証が伝播しなくなる。HHVMの最適化エンジンも、型が確定しないコードパスにおいては真価を発揮できず、無駄なガード命令やボックス化（Boxing）のオーバーヘッドを背負うことになる。

—

2. 移行期によくある「最悪の型不整合」パターン

Strict Modeへ移行する際、開発者が最も頭を悩ませるのが、外部入力やレガシーな配列（Array/Dict）の境界領域だ。

特にやりがちなアンチパターンを見てみよう。

❌ 危険なアンチパターン：`mixed` とキャストの連鎖

“Argument 1 to process_user_data() must be of type array, mixed given”
> “The function idx expects an array or collection, but got a non-exact type…”

ここで安易に `As` 式や強制キャストで逃げようとするのは最悪の手だ。ランタイムエラーの温床を作るだけにすぎない。

—

3. 堅牢な設計パターン：境界の厳格なバリデーションと Shape の活用

PartialからStrictへの移行を成功させる鉄則は、「外部境界（Boundary）で型を確定させ、内部（Domain）は完全にStrictで閉じる」ことだ。

HHVMの型システムを最大限に活かすため、構造化されたデータには `shape` や `record` を用いる。以下のプロダクションコードを見てほしい。これが、我々が目指すべき洗練された移行期の設計だ。

✔️ 推奨されるプロダクションコード例

ユーザーデータの厳格な構造定義（Shape）

キーの存在と値の型をコンパイル時に完全に保証する。

/
type UserShape = shape(
‘id’ => int,
‘name’ => string,
‘email’ => string,
‘is_active’ => bool,
);

class UserProcessor {

外部からの曖昧な入力を受け取り、Strictな世界へのゲートウェイとなるメソッド。
ここで初めて型アサーションやバリデーションを行う。

/
public static function fromMixed(mixed $input): UserShape {
// HHVMの組込み関数やパターンマッチ、厳密な型チェックで検証
if (!is_dict($input)) {
throw new \InvalidArgumentException(‘Input must be a dictionary structure.’);
}

// 必須キーの存在と型の整合性を担保して Shape として返す
// ここを通過した瞬間から、このデータは完全に「安全な型」を持つ
return shape(
‘id’ => self::extractInt($input, ‘id’),
‘name’ => self::extractString($input, ‘name’),
‘email’ => self::extractString($input, ‘email’),
‘is_active’ => self::extractBool($input, ‘is_active’, true),
);
}

private static function extractInt(dict $dict, string $key): int {
$val = $dict[$key] ?? 0;
if (!is_int($val)) {
throw new \UnexpectedValueExceptionf(“Key ‘%s’ must be an int”, $key);
}
return $val;
}

private static function extractString(dict $dict, string $key): string {
$val = $dict[$key] ?? ”;
if (!is_string($val)) {
throw new \UnexpectedValueExceptionf(“Key ‘%s’ must be a string”, $key);
}
return $val;
}

private static function extractBool(dict $dict, string $key, bool $default): bool {
if (!containsKey($dict, $key)) {
return $default;
}
$val = $dict[$key];
if (!is_bool($val)) {
throw new \UnexpectedValueExceptionf(“Key ‘%s’ must be a bool”, $key);
}
return $val;
}

完全に Strict 化されたドメインロジック層
ここには mixed は一切存在しない。

/
public static function renderGreeting(UserShape $user): string {
if (!$user[‘is_active’]) {
return “Account is inactive.”;
}
// $user[‘name’] が stringであることが保証されているため、無駄なガードは不要
return \Str\format(“Welcome back, %s (%s)!”, $user[‘name’], $user[‘email’]);
}
}

—

4. アーキテクチャの観点：なぜこの設計がHHVMで爆速なのか？

上記のコードが優れているのは、単に型安全だからではない。HHVMのJITコンパイラ（Region Engine）にとって極めて最適化しやすいコードだからだ。

1. 型の確定による型特化（Type Specialization）:
境界（`fromMixed`）を抜けた瞬間、データは `UserShape` という静的な構造に落とし込まれる。HHVMはこれにより、メソッド内部でのプロパティアクセスや配列インデックスアクセスにおいて、動的な型ルックアップ（Type Check）を完全に排除し、直接的なメモリアクセスへとコンパイルできる。
2. ボックス化の最小化:
`mixed` 型の変数はHHVMの内部でヒープ上の汎用コンテナ（Box）として扱われがちだが、`int` や `string`、さらには固定長の `shape` として扱われることで、スタック上や最適化されたレジスタ上で効率よく処理される。

—

5. テックリードからの実践的アドバイス：移行のロードマップ

一気に全ファイルを `境界の特定（The Edge Identification）:
データベース、HTTPリクエスト、外部APIなど、外部世界と通信する「境界」のクラスを洗い出し、そこだけを最後に Strict 化するモジュールとして残す。
2. ドメインモデルの内側から外側へ:
ビジネスロジックの最深部（値オブジェクトや純粋関数群）から `内側（ドメイン）を完全に浄化し、最後に外側（インフラ・I/O）のバリデーションを固めるのだ。
3. CI/CDへの組み込み:
`hh_client` をビルドパイプラインに組み込み、Partial ModeからStrict Modeへの移行ファイルを徐々にホワイトリスト方式で厳格化していく。

妥協したコードは技術的負債の複利を生む。Hackの厳格な型システムを飼いならすのではなく、型システムにシステム全体をリードさせよ。その先にこそ、変更容易性と圧倒的なパフォーマンスを兼ね備えたプロダクション環境が待っている。