第12部演習 — 判断ガイド¶

判断フローを「使う」練習です。結論だけでなく、どの質問で分岐したかを言えることが目標です。

問1. 概念確認¶

次の主張の問題点を、該当する判断ガイドを引いて指摘してください。

「このクラスは500行を超えたので分割すべきだ」
「将来のために全クラスにインターフェースを切っておいた」
「イベント駆動にしたので、ダメージ→死亡→ドロップもバスに流した」
「デバッグビルドで計測したらここが遅かったので最適化した」

解答

1. 分割基準は行数でなく変更理由の数([クラス分割](01_split_class.md)Q1)。2. 実装1つ・差し替え予定なしの抽象はコストのみ([インターフェース](02_create_interface.md)Q1〜3)。3. ルールの帰結(順序が仕様)はイベントにしない([イベントの判断](05_events_di_singleton.md))。4. デバッグビルドの計測は最適化判断の根拠にならない(Shipping相当で再計測 → [最適化の判断](07_optimize_or_refactor.md))。

問2. コード読解(判断の復元)¶

あるコードレビューで「ここはswitchのままでいい」という結論になりました。どんな判断材料が揃っていたと推測できますか。3つ挙げてください。

解答例

(a) 分岐対象の種類が少なく(2〜4)、追加の予定・実績がない([OCP](../02_solid/ocp.md)を開く証拠なし)。(b) 同じ分岐が複数関数に複製されていない(1か所に集約済み)。(c) 種類を横断して一覧できる価値がある(バランス確認など)、またはチームがポリモーフィズム版の追跡コストを払いたくない([抽象化の判断](04_abstraction_and_patterns.md)Q3「簡潔案との比較」)。

問3. 設計判断(ケース適用)¶

「ローグライクのアイテム(消費・装備・呪い、200種予定、週次で追加)」について、(a) 構造体かクラスか、(b) 継承かコンポジションか、(c) データ駆動にするか、の3判断をフローに沿って行い、結論と分岐点を記録してください。

解答の要点

(a) アイテム定義(名前・数値・効果リスト)は不変条件のないデータ → struct+public([構造体かクラスか](06_cpp_choices.md))。所持インベントリ(個数整合)はclass。(b) 消費/装備/呪いは「特徴の組み合わせ」(呪われた装備)→ コンポジション(効果リスト)([継承かコンポジションか](03_inheritance_or_composition.md)Q4)。(c) 200種・週次追加は「追加が繰り返される証拠」が最初からある → データ駆動を初期から([アイテム効果](../11_case_studies/12_item_effects.md)の案A)。

問4. 設計比較(投資の優先順位)¶

チームに1週間の「改善スプリント」が与えられました。候補: (A) 全域Singletonの3つをDI化 (B) ビルド時間を15分→5分に (C) 神クラスGameManagerの分割 (D) 主要ロジックへのユニットテスト追加。あなたのプロジェクト想定(自由に設定してよい)で優先順位を付け、判断ガイドの語彙で正当化してください。

解答例(想定: 中規模・週次リリース・テストなし)

**B → D → C → A**。B: ビルド時間は全員の全作業に掛かる利息で、回収が最速([技術的負債](../01_design_basics/10_tech_debt_and_refactoring.md)の「高利息」)。D: テストは今後の全リファクタの前提条件([リファクタの判断](07_optimize_or_refactor.md)Q3)であり、Cを安全にやるためにも先。C: 触る頻度が高いなら高利息だが、Dなしでは危険。A: Singletonは「テストで差し替えたくなった時」が移行タイミングで、D完了後に痛みが顕在化してからで遅くない([Singletonの判断](05_events_di_singleton.md))。**別解も成立する**(Cが毎日の開発を止めているなら最優先)——順位そのものより「利息と前提条件」で語れているかが評価点。

問5. デバッグ問題(判断ミスの事後分析)¶

「半年前に導入した汎用イベントバスが原因で、不具合調査に毎回半日かかっている」。当時の判断のどこが誤りだった可能性が高いか、イベントの判断と抽象化の判断のフローで事後分析してください。

解答の要点

可能性1: 破綻シグナルが出る前の導入(「疎結合は良いこと」という一般論での採用 — 治療でなく予防接種)。可能性2: 3分類の無視——ルールの帰結までバスに流し、因果が追えなくなった。可能性3: 導入時に「イベントログ(全発行の記録)」という追跡手段をセットで作らなかった(欠点への手当てなしの採用)。教訓: パターンの採用判断には「その欠点をどう緩和するか」まで含める。

問6. 説明問題¶

このWiki全体を貫く「トレードオフで判断する」という姿勢を、後輩への1分間の説明として文章化してください(5文以内)。

解答例

設計の道具(SOLID、パターン、抽象化)は全部「何かを良くする代わりに何かを悪くする」交換であって、無料の正解はない。だから「使うべきか」は道具の知識ではなく、状況の証拠——変更が繰り返されているか、計測で遅いか、後から変えるのが高い決定か——で決める。証拠がないうちは素朴に書き、破綻のシグナルが出たら対応する道具で治す。ただしセーブ形式のような不可逆な決定だけは先に手を打つ。そして選ばなかった案と理由を一行残しておけば、将来の自分たちが再判断できる。

問7. 小規模実装問題(判断の実地演習)¶

自分の現行プロジェクト(なければ第11部演習の問7のWave Survival)から機能追加を1つ選び、実装前に以下を書いてから実装してください。

適用した判断ガイドと、通った分岐(Q1→Q2→…)
採用案と、比較した「より素朴な案」
実装後: 判断は正しかったか、想定と違った点

この「判断ログ」の習慣がこのWikiの最終目標です。

前: 最適化・リファクタリングの判断 | カテゴリ目次 | 全体目次へ

第12部 演習 — 判断ガイド¶