Hackの深淵へ：Attributeを用いた型システムの「拡張」とコード規約の強制
Hack言語における`strict`モードは、単なる「型チェック」ではない。それは、HHVMのJITコンパイラがバイナリを生成する前段階における、「論理的な正しさの数学的証明」である。
多くのエンジニアは、Hackの型システムを「型エラーを防ぐためのガードレール」程度に考えている。だが、真のアーキテクトにとって、型システムとは「ビジネスドメインの制約をコードへ強制的に記述するためのメタ言語」だ。
今回は、標準の型システムでは表現しきれない「プロジェクト固有の制約」を、`Attribute`（属性）を用いて静的解析フェーズにねじ込み、バグが生まれる余地を物理的に排除する高度なテクニックを伝授する。
—
なぜ標準の型チェックだけでは不十分なのか
例えば、社内のAPI設計指針で「`SensitiveData`を扱うクラスは、必ず特定のロギング除外フラグを立てなければならない」というルールがあるとしよう。
// ダメな例：ドキュメントに書くだけ。誰も読まないし、誰も守らない。
/ @SensitiveData /
class UserCreditCard { … }
これでは人間がレビューするまでバグは潜伏する。我々が求めるのは、「ルールに違反したコードは、HHVMのビルドすら通らない」という強制力だ。これを実現するのが`__EntryPoint`や`__Override`のような組み込み属性を拡張する、カスタム・アトリビュート設計である。
—
実践：カスタムAttributeによる「強制力」の実装
Hackにおいて、Attributeはコンパイル時にHHVMの静的解析エンジン（`hh_client` / `hhvm`）によって評価される。これを利用して、ルール違反を「型エラー」として報告させる。
1. 属性定義の作成
まず、メタデータとして機能する属性を定義する。
namespace App\Attributes;
// TARGET_CLASSにより、クラス定義以外への付与を禁止する
<<__Attribute(AttributeTargets::CLASS)>>
final class MustHaveSecurityAudit {}
2. 静的解析へのフック（戦略的ポイント）
Hackの型チェッカー（`hh_client`）は、プラグインのような形で解析フェーズを拡張可能です。ただし、もっとも現実的でパワフルな手段は、「コード生成器」あるいは「カスタムルールのLinter」をCIに組み込むことである。
ここでは、実務で最も効果的な「特定の属性を持つクラスに対する一貫性の強制」を例示する。
<
class PaymentGateway {
// もしこのクラスにこの属性をつけたら、
// 特定のメソッド（例: auditLog()）が必ず存在することを
// CI側の静的解析スクリプトで検知し、失敗させる。
public function auditLog(): void { / … / }
}
—
パフォーマンスと保守性の最適化：アーキテクトの視点
ここで重要なのは、「型チェッカーの解析負荷を上げすぎないこと」だ。
- 属性は「静的」に扱う: 実行時（Runtime）の`Reflection`を多用してはいけない。それはHHVMのJIT最適化を阻害し、メモリ消費を増大させる。あくまで型チェッカー（`hh_client`）が解析する「ソースコードの静的状態」のみに依存させること。
- Fail Fast, Fail Loud: 静的解析で違反を見つけた場合、単に警告を出すのではなく、終了コードを`1`にしてビルドを落とせ。警告は無視されるのがオチだ。
推奨されるCIパイプラインの構成
1. `hh_client –check`（標準の型安全性を担保）
2. `custom_analyzer.hack`（自作のアトリビュート検証スクリプト：ASTを走査して違反を抽出）
// AST走査のロジック（概念コード）
use Facebook\HHAST;
// 属性を走査し、MustHaveSecurityAuditが付与されているのに
// auditLogが存在しないクラスを抽出してエラーを吐く
function validateSecurityPolicy(HHAST\EditableSyntax $root): void {
foreach ($root->getDescendantsOfType(HHAST\ClassDeclaration::class) as $class) {
if (hasAttribute($class, ‘MustHaveSecurityAudit’) && !hasMethod($class, ‘auditLog’)) {
throw new Exception(“Security Violation: ” . $class->getName() . ” needs auditLog()”);
}
}
}
—
結論：コードは「書く」ものではなく「設計する」もの
Hackの厳格な型システムとAttributeを組み合わせることで、私たちは「人間がミスをする余地」をコンパイル時間という時間軸の中で殺すことができる。
「このメソッドは呼ぶ前に必ずこのチェックを通してください」というドキュメントを書く時間は、もう終わりだ。型と属性を使って、「そう書くことしかできないコード」を強制せよ。
それが、数百万のリクエストを捌くHHVM環境における、真に堅牢なシステム設計の第一歩だ。次回のコードレビューでは、「なぜこの制約を型システムに落とし込まなかったのか？」と問うてみてほしい。その瞬間から、君のチームのコードの品質は一段階上の次元へと進化するはずだ。