「Debugging」タグの記事が2件件あります

QAテスターがバグを報告する：「鍵を拾ってもドアが開かない。」

シンプルだろう？ おそらく参照漏れか条件の間違い。プロジェクトを開き、鍵を拾うと...ドアは問題なく開く。自分の環境では再現する。テスターに再現手順を聞くと「30%くらいの確率で発生する。大抵セーブ/ロードサイクルの後」とのこと。

デバッグ地獄に突入だ。鍵ピックアップイベントからインベントリ更新、クエスト進行チェック、ドアのアンロック条件に至るチェインのどこかで、何かが間欠的に失敗している。しかしどのリンクだ？ イベントが発火されなかった？ 発火されたがリスナーがサブスクライブされていなかった？ サブスクライブされていたが条件がfalseに評価された？ 条件は正しかったがロード後にドアの状態が古かった？

プレイヤーが死ぬ。死亡サウンドが鳴る。ラグドールが起動する。UIポップアップに「You Died」が表示される。ゲームがオートセーブする。アナリティクスイベントが発火する。リスポーンタイマーがカウントダウンを開始する。6つの異なるシステムが、1つのイベントOnPlayerDeathに応答している。でも質問がある——それはどこに文書化されている？

コードの中ではない。プロジェクト管理ツールの中でもない。どんなダイアグラムの中でもない。それが存在するのは1つの場所だけ：元々それをセットアップした人の頭の中。そしてその人が6ヶ月前にチームを離れていたら、どこにも存在しない。

これがイベント駆動アーキテクチャのダーティシークレットだ。システムを疎結合にするからこそ採用する。AudioManagerがUIManagerへの参照を持つ必要がないことを喜ぶ。でも決して語られないコストがある：実行フローが見えなくなる。そして見えないものは、定義上、視覚的にデバッグすることが不可能だ。