Hackの「Strict Mode」移行：技術的負債を「資産」へと昇華させる戦略的アプローチ
Hack言語のコアを知る者として断言する。`<<__Strict>>` は単なる静的型チェックのスイッチではない。それは、君たちのコードベースが「動けばいい」という泥沼から、「計算機科学的に証明可能な信頼性」へと脱皮するためのゲートウェイだ。
大規模なPHPプロジェクトからHackへの移行において、最大の敵は「Partial Modeの妥協」と「移行の先送り」にある。本稿では、PartialとStrictが混在するカオスな環境下で、いかにして型安全性を担保し、技術的負債を確実に撲滅していくか、その極意を伝授しよう。
—
1. 混在環境の最大の罠：`mixed` という名の毒
Partial Modeにおいて、最も警戒すべきは `mixed` 型の蔓延だ。型定義が欠落した関数は `mixed` を受け取り、`mixed` を返す。これがある限り、HHVMの型チェッカー（hh_client）は「何も保証しない」という立場をとる。
負債管理の鉄則：
Partial ModeからStrictへの移行において、境界線（Boundary）を明確にせよ。外部からのデータ入力、つまり `$_GET`, `$_POST`, またはレガシーなAPIレスポンスの受け取り口にこそ、厳格なバリデーション層を配置するのだ。
推奨される境界設計パターン
「とりあえず型を付けない」のではなく、`shape` や `opaque type` を使って、境界で型を確定させる。
namespace App\Boundary;
// レガシーなAPIレスポンスを定義
type TUserPayload = shape(
‘id’ => int,
‘username’ => string,
‘metadata’ => mixed, // ここはまだ負債として残る
);
/
- 境界で徹底的に型を補足する。
- Partial Modeであっても、ここで型キャストを強要することで
- 後続のロジックをStrictに近づける。
/
function parseUser(mixed $data): TUserPayload {
if (!is_array($data) || !isset($data[‘id’], $data[‘username’])) {
throw new \InvalidArgumentException(“Invalid payload structure”);
}
// 明示的な型変換により、ここから先は型安全性を確保
return shape(
‘id’ => (int)$data[‘id’],
‘username’ => (string)$data[‘username’],
‘metadata’ => $data[‘metadata’] ?? null,
);
}
—
2. 段階的移行の技術的負債管理：`hhvm.hack.lang.check_strictest_compat` を使いこなせ
移行の際、いきなり全ファイルを `<<__Strict>>` にするのは自殺行為だ。まずは `hhconfig` を活用し、チェックレベルを段階的に引き上げる戦術をとる。
- Step 1: `nocheck` を減らし、`partial` のまま型注釈を増やす。
- Step 2: 新規作成ファイルには必ず `<<__Strict>>` を強制する（CIで `hh_client` を実行し、Strictモード以外のファイルを検知する）。
- Step 3: HHVMの `experimental_features` を活用し、新しい型システムを先行導入する。
ここで重要なのは、「型チェックの警告を握りつぶさない」ことだ。特に `HH_FIXME` を多用し始めたら、それは設計が破綻しているサインである。
—
3. 実践：保守性の高いDI設計と非同期連携
非同期処理（`Awaitable`）とStrict Modeの親和性は極めて高い。非同期境界において型を厳格化することで、レースコンディションや期待値の不一致をコンパイル時に排除できる。
堅牢な非同期APIコンポーネント例
<<__Strict>>
namespace App\Service;
/
- 非同期APIクライアントのインターフェース
- 戻り値をAwaitableで包むことで、型安全な並列処理を実現
/
interface IApiClient {
public function fetchUserData(int $id): Awaitable
}
final class UserFetcher implements IApiClient {
public async function fetchUserData(int $id): Awaitable
// 実際にはここで外部APIを叩く
// Strict Modeでは、戻り値の型が shape(‘name’ => string) であることが
// コンパイラによって保証される
return shape(‘name’ => ‘Hack Developer’);
}
}
このコードの美しさは、`Awaitable` の中身が必ず保証されている点にある。Partial Modeのコードからこれを呼び出す場合でも、型チェッカーが `Awaitable` のアンラップを強制するため、安全性が連鎖的に伝播する。
—
4. チーフアーキテクトからの助言
大規模コードベースにおいて、リファクタリングは「外科手術」だ。以下の指針を守れ。
1. 「型推論」を信じすぎない: `var` や明示的な型指定を省略する「手抜き」は、Strict移行時に最大の障害となる。
2. `Option` 型（`?T`）の活用: `null` を `mixed` で誤魔化すな。`?int` や `?string` を使うことは、HHVMに対して「nullの可能性があることを理解している」という意思表示であり、実行時のセグメンテーションフォールトを未然に防ぐ防壁だ。
3. CI/CDパイプラインを厳格化せよ: `hh_client –no-legacy-js-support` や、特定の型エラーをCIでFAILさせる設定は必須だ。人間によるレビューに頼るな。ツールが正義だ。
Hackは、PHPの柔軟性を維持しつつ、静的型言語の堅牢性を手に入れるための最強の選択肢だ。PartialからStrictへの移行は、単なるコードの書き換えではない。それは、君たちのチームが「曖昧さ」を排除し、「設計の真実」に向き合うためのプロセスだ。
コードを書くとき、いつも自問自答せよ。「この型定義は、実行時の予期せぬ失敗をどれだけ減らせているか？」と。その問いの先に、真に堅牢なアーキテクチャが待っている。