PHPの残滓を焼き払え：Hackで「型安全」という名の要塞を築くための実践戦略
PHPからHackへの移行は、単なる構文の変換ではない。それは「実行時までエラーが分からない」という博打から、「コンパイル時に論理的な整合性を証明する」という規律への転換だ。
多くのチームが移行直後に陥る罠がある。それは、「型定義はしているが、中身はPHP時代の動的思考のまま」という状態だ。`mixed`型がコードの至る所に散見され、`any`的な振る舞いに甘えているようでは、Hackを採用した意味がない。
今回は、Hackの真髄である静的解析を強制し、堅牢なプロダクションコードを維持するための「アーキテクトの戒律」を伝授する。
—
1. 型の脱獄を許さない：`.hhconfig`による強制
まず、設定ファイルから妥協を排除せよ。`hh_client`がどれだけ厳格にチェックするかは、`.hhconfig`の `strict_mode` に懸かっている。
.hhconfig
妥協なき静的解析の設定
assume_php = false
strict_mode = true
警告すら許さない。エラーは即座にCIを止めるべき「欠陥」である
disallow_unresolved_types = true
チームの運用において、「警告は放置していい」という文化は即刻廃止せよ。 警告は、将来のバグへの借金である。
—
2. 実践的設計パターン：`mixed`の汚染を防ぐ
PHPから移行したコードで最も忌むべきは、`mixed`型の蔓延だ。外部APIからのレスポンスをそのまま扱う際、安易に `mixed` を受け入れていないか？
NGな設計:
// どこから来たか分からないデータに型を強制していない
function process(mixed $data): void {
// ここで毎回 is_array() や型キャストが必要になり、
// HHVMのオプティマイザが型推論できず最適化が効かない
}
推奨される設計（ShapeとHSLの活用）:
外部境界（APIレスポンス等）では、必ず型定義（Shape）でバリデーションをかける。
namespace App\API;
use type HH\Lib\Dict;
// データの構造を厳格に定義する
type UserResponse = shape(
‘id’ => int,
‘username’ => string,
‘email’ => string,
);
final class UserClient {
public function fetchUser(int $id): UserResponse {
$raw = $this->http->get(“/users/{$id}”);
// 境界で型を確定させる。これが「型の要塞」の入り口だ
if (!is_shape_of_user($raw)) {
throw new \Exception(“Invalid API Response”);
}
return $raw;
}
}
この設計により、関数の内部では `is_` 系チェックを排除できる。HHVMは「この変数は絶対に `int` である」と確信し、最適化されたマシンコードを生成する。これがパフォーマンスへの直結だ。
—
3. 非同期API連携：`Awaitable`の正体を知る
非同期処理を扱う際、`await` をただのおまじないだと思っていないか？ `Awaitable
パフォーマンスを最大化する設計:
複数の非同期処理を並列化する際、安易に `await` を連打するな。
// 非効率：順番に待機している
$user = await $this->fetchUser();
$posts = await $this->fetchPosts();
// 効率的：Awaitableを束ねて一気に解決する
// HHVMの非同期スケジューラがコンテキストスイッチを最適化する
list($user, $posts) = await Awaitable\genv(
$this->fetchUser(),
$this->fetchPosts(),
);
`Awaitable\genv` を使うことで、型安全を維持しつつ、IO待ち時間を最小化できる。型システムが `list($user, $posts)` が期待通りの型であることを静的に検証してくれるため、実行時の型エラーは理論上発生しない。
—
4. コードレビューで「型」を問う
チームのコーディング規約において、以下の観点をレビューの必須項目にすること。
1. `mixed` は存在するか？：存在する場合、なぜ `shape` や `interface` で抽象化できないのかを問い詰めろ。
2. nullableの伝播は適切か？：`?T` を安易に使うと、至る所で `null` チェックが発生する。可能なら「空オブジェクトパターン」や「デフォルト値」で `null` を排除せよ。
3. HSL（Hack Standard Library）を使っているか？：古いPHPの `array_map` などは `mixed` を許容する。`HH\Lib\Vec\map` を使え。型安全性が段違いだ。
—
結論：コードは「ドキュメント」ではなく「定理」であれ
Hackの型チェッカーは、単なるエラー検知器ではない。それは、あなたのコードが論理的に正しいことを証明する数学的証明器だ。
PHP時代のように「動けばいい」という考えは捨てよ。コンパイルが通るということは、そのコードには論理的な矛盾がないという証明だ。この規律を守り抜いた先に、変更に強く、高速で、何よりエンジニアを夜中に叩き起こさない「美しいプロダクションコード」が待っている。
型を妥協するな。それが、Hackを操る者の矜持だ。