Hackの深淵へようこそ：Partial Modeという「甘い罠」を脱却し、Strictの真髄へ
こんにちは。Hackの進化をコードの深層から見守り続けてきたアーキテクトです。
Hackを触り始めると、まず驚くのがその型システムの厳格さですよね。しかし、既存の巨大なPHPコードベースを移行しようとすると、必ずぶち当たる壁があります。それが「Partial Mode（部分モード）」という、便利で、かつ極めて危険な道しるべです。
今日は、なぜPartial Modeが技術的負債を生むのか、そしてどうすれば「真のStrict」に辿り着けるのか、その極意を伝授しましょう。
—
1. なぜPartial Modeは「諸刃の剣」なのか？
Hackには、ファイル単位で型チェックの厳しさを選べる仕組みがあります。
- Partial Mode (`: 型定義が曖昧でも許容される。「動けばいい」を許す、移行期の甘い設定。
- Strict Mode (`: 全ての型が明示的でなければならない。「妥協を許さない」究極の安全性。
Partial Modeの最大の落とし穴は、「型チェックがサボる場所を作る」ことにあります。型チェッカーは、Partialなファイルから情報が漏れ出しても、それをエラーとして弾きません。
陥りやすい「見えない不整合」のイメージ図
[Strictファイル] —-> [Partialファイル] —-> [動的型付けのPHP関数]
↑ ↑
型が保証される 「何が返ってくるか不明」
→ ここで型が濁る！
StrictなコードからPartialなコードを呼び出した瞬間、型システムは「あとは野となれ山となれ」と諦めてしまいます。この「諦め」が蓄積されると、システム全体が「動いてはいるが、いつ爆発するかわからない」不安定な状態に陥るのです。
—
2. 実践：Partial Modeが生む「型不整合」の典型例
例えば、以下のようなケースを考えてみてください。
// file: LegacyData.hh (Partial Mode)
0 ? dict[‘name’ => ‘Alice’] : null;
}
この `get_user_data` をStrictなファイルから呼ぶとどうなるでしょうか？
// file: AppController.hh (Strict Mode)
爆弾（nullや予期せぬ型）が型チェックをすり抜けて持ち込まれるのです。
—
3. Strictへの移行：技術的負債を解消するステップ
では、どうやってStrictへと移行すべきでしょうか？闇雲に `// strict` に書き換えても、何千ものエラーが出て戦意喪失してしまいますよね。以下の手順で「外堀」から埋めていくのがプロのやり方です。
ステップ1：戻り値と引数の明示
まずは、Partialファイルの関数に型定義を一つずつ追加しましょう。
// 修正前
function get_user_data($id) { … }
// 修正後
function get_user_data(int $id): ?dict
ステップ2：型チェッカーの警告を潰す
型チェッカー（`hh_client`）を回し、出たエラーを一つずつ修正します。ここで重要なのは「`mixed`型」から逃げないことです。`mixed`は思考停止の証。可能な限り具体的な型を当てはめてください。
ステップ3：Strictモードへ昇格
全ての型定義が完了したファイルから、ヘッダーを `最後に：型は「守るもの」ではなく「語るもの」
初心者のうちは、型を「エラーを出して邪魔してくるもの」と感じるかもしれません。しかし、熟練のHackエンジニアにとって、型は「このコードがどう振る舞うべきか」をコード自身に語らせる言語です。
Partial Modeで甘やかされたコードを、一つずつStrictの厳格さで磨き上げていく。その作業は、単なる修正作業ではなく、あなたのアプリケーションの「信頼性」を構築する建築作業そのものです。
ここをクリアすれば、あなたはもうただのPHPエンジニアではありません。Hackの静的解析の恩恵をフルに享受できる、真のエンジニアへの第一歩を踏み出したことになります。
さあ、エディタを開いて、まずは一つのファイルの `// partial` を消すことから始めてみませんか？応援していますよ。