「HH_FIXME」は敗北宣言か、それとも戦略的撤退か？ ―― Hack型システムを支配する技術的負債の統治術
HHVM/Hackの世界へようこそ。諸君が「Strict Mode」の恩恵を享受し、`hh_client`の冷徹なまでの正確さに救われていることを願う。
しかし、大規模なプロダクションコードを扱っていれば、必ずあの忌々しいコメントに直面するはずだ。そう、`/ HH_FIXME[XXXX] /` だ。
多くの凡庸なエンジニアは、これを「型チェッカーを黙らせるための魔法の呪文」だと勘違いしている。だが、我々コアコミッターの視点から言わせれば、`HH_FIXME` は型システムという強固な城壁に自ら穿つ「破城槌」に他ならない。無計画な使用は、静的解析が保証する安全性を内側から崩壊させる。
今日は、この「劇薬」をいかに制御し、技術的負債を資産へと変えるための「統治術」を伝授しよう。
—
1. なぜ HH_FIXME が「危険」なのか：型伝搬の汚染
Hackの型チェッカーは、単なる文法チェックではない。それは、プログラム全体のデータフローを証明する数学的エンジンだ。
`HH_FIXME` を置いた瞬間、その箇所の型推論は「不透明」になる。チェッカーはそこを `any` や `dynamic` として扱うしかなくなり、その不透明さは呼び出し元、さらにはその先の関数へと連鎖的に波及していく。
// 悪い例：安易なFIXMEが型安全性を破壊する
function get_user_age(dict
/ HH_FIXME[4110] 本来は int だが、APIの型が不安定なので黙らせる /
return $data[‘age’];
}
// ここで型チェッカーは「intを返す」と信じ込むが、
// 実行時に $data[‘age’] が string だった場合、HHVMは Runtime Type Violation を投げる。
// 静的解析の死角で爆弾が爆発するわけだ。
HHVMのJITコンパイラは、型情報をもとに高度な最適化を行う。型チェッカーを騙すことは、JITに対しても「最適化のヒントを誤認させる」リスクを孕んでいることを忘れてはならない。
—
2. 戦略的「隔離」：FIXMEを局所化するデザインパターン
実務において、どうしても `HH_FIXME` を避けられない場面はある。例えば、古いレガシーライブラリとの境界や、極めて動的な構造を持つ外部APIレスポンスのパースだ。
その際の鉄則は、「FIXMEの影響範囲を最小限の関数内に閉じ込め、即座に型安全な世界へ引き戻す」ことだ。
プロダクション級の設計例：Type-Safe Wrapper
外部APIから不透明な `dynamic` なデータが降ってくるケースを想定しよう。
final class UserInflowController {
/
- 外部SDKが返す「型定義の壊れたオブジェクト」を安全なShapeに変換する
/
private function sanitizeExternalPayload(mixed $raw_payload): UserProfileShape {
// 1. まずは型安全な「入れ物」を定義する
// shapeを使用することで、後続のロジックでキーの存在と型が保証される
/ HH_FIXME[4110] 外部SDKの戻り値が mixed のため、強制的にキャストが必要 /
$data = (dict
return shape(
‘id’ => TypeAssert\is_int($data[‘id’] ?? null),
‘email’ => TypeAssert\is_string($data[‘email’] ?? ”),
‘retry_count’ => $this->parseRetryCount($data),
);
}
private function parseRetryCount(dict
// 複雑な型変換が必要な箇所だけを小さなメソッドに切り出し、
// そこでだけFIXMEを許容する。
/ HH_FIXME[4062] nullableなアクセスを承知の上で実行 /
$count = $data[‘meta’][‘retry’] ?? 0;
return (int)$count;
}
}
このパターンの肝は、`HH_FIXME` を使った直後に `TypeAssert`（または自前の検証ロジック）を通し、「型チェッカーの嘘を、実行時の真実で上書きする」点にある。これにより、これ以降のビジネスロジックは `HH_FIXME` の汚染から完全に解放される。
—
3. 技術的負債を可視化する「負債管理術」
`HH_FIXME` を書くとき、君は未来の自分（あるいは同僚）から時間を前借りしている。借金には「返済計画」が必要だ。
我々のチームでは、以下のルールを徹底している。
1. エラーコードの明示: `HH_FIXME[4110]` のように必ずエラー番号を書く。
2. 「なぜ」の記述: なぜ型を合わせられなかったのか、依存先のどのライブラリが原因かを必ず付記する。
3. 期限とチケット番号: `TODO: JIRA-1024` のように、修正タスクと紐付ける。
負債を追跡するコード例
/
- @TODO 2024-Q4までに legacy_module を v2 に上げ、このFIXMEを削除する
- @see https://jira.internal/issue/TECH-888
/
/ HH_FIXME[4101] LegacyModule はジェネリクスに対応していないため /
$service = new LegacyModule();
さらに、CI（継続的インテグレーション）において `grep` をかけ、`HH_FIXME` の総数をグラフ化せよ。数が増え続けているプロジェクトは、アーキテクチャが腐敗し始めている証拠だ。
—
4. コアアーキテクトからの助言：`dynamic` と `HH_FIXME` の使い分け
最近のHackでは `dynamic` 型が導入された。これは「型チェックを意図的に緩める」ための型だが、`HH_FIXME` とは明確に使い分けるべきだ。
- `dynamic` を使うべき時: 関数が本質的にどんな型でも受け入れ、そのままバイパスするような柔軟性が必要な場合（例：シリアライザ）。
- `HH_FIXME` を使うべき時: 本来は厳格な型があるべきだが、ライブラリの不備や一時的な実装の都合で「今だけ」型チェッカーを無視したい場合。
`HH_FIXME` は「不具合の隠蔽」ではなく、「型システムの限界に対する注釈」でなければならない。
—
結論
Hackを掌握するエンジニアとは、`HH_FIXME` を一箇所も書かない人間ではない。「どこに、なぜ、いつまで FIXMEが存在するか」を完全にコントロール下に置いている人間のことだ。
静的型システムは君を縛る鎖ではない。自由な開発を支えるための「重力」だ。重力を無視して飛ぼうとすれば、いつか地面に叩きつけられる。`HH_FIXME` という小さな「重力異常」を適切に管理し、堅牢なシステムを構築してほしい。
諸君の `hh_client` が常に `No errors!` を返すことを願っている。たとえその裏に、注意深く管理された数個の `FIXME` が隠れていたとしても。