凝集度（cohesion）ファースト － 1つのプロシージャーが担当すべきこと
プロシージャー主導型RPGで最もよくある間違いの1つは、小さなプロシージャーは、適切に設計されているプロシージャーだと安易に思い込むことです。実際は、そうではありません。サイズと凝集度（cohesion）とは関連がありますが、それらは同じものではありません。凝集度の高いプロシージャーは、1つの明確な責務を持っています。プロシージャーは、1つのビジネス上の質問に回答するか、または1つのビジネス アクションを実行するために存在しています。プロシージャーがそれより多くのことを行おうとすると、それは再利用可能なビルディング ブロックではなくなり、マイナスに作用し始めます。
プロシージャー型RPGでは、こうした規律を強制するものはありません。プロシージャーに2つ目の責務が密かに追加されたときに、コンパイラーの警告はありません。たまたまその時点で利便性があるという理由で、開発者がもう1つだけステップを追加しようとしたときに、それを阻止する言語機能もありません。長年にわたるメンテナンスで、そうした利便性が蓄積し、凝集度は、ほとんど気付かないうちに損なわれます。
明確に命名できないのは、行うことが多過ぎるから
命名は、RPG開発者が利用可能な最も信頼できる凝集度のテストの1つです。プロシージャー名に曖昧な表現が求められたり、プロシージャー名が大まかで不明瞭に感じ始めたりしたときは、それは、複数の責務がひとまとめにされていることの現れであることが多いようです。ProcessMushroomOrder（キノコ注文処理）またはHandleMushroomInventory（キノコ在庫処理）という名前は、最初は妥当なように聞こえますが、それらはプロシージャーの挙動を説明するのではなく、むしろ覆い隠しているのです。
プロシージャー名が明確だと、目的も明確になります。ValidateMushroomBatch（キノコ バッチ検証）という名前のプロシージャーは、期待値を設定します。CalculateMushroomYield（キノコ収量計算）という名前のプロシージャーは、どのような問題を解決するのか正確に呼び出し元に伝えます。命名が難しくなった場合、それは言葉探しの問題ではありません。それは設計の問題です。
経験豊かなRPG開発者は、命名に関する軋轢を、そのまま押し通したり無視したりするべきものではなく、改善に役立つフィードバックとして扱うことを学んでいます。
ビジネス アクションと技術的ステップ
よくあるもうひとつの凝集度に関する不具合は、ビジネス ロジックと技術的実装の詳細を混合することから生じます。
キノコの出荷が品質基準を満たすどうかを判定するプロシージャーは、ファイルをオープンしたり、コミットメント制御を管理したり、監査レコードを記述したりするべきではありません。それらのタスクは、同じワークフローの一部として生じる場合もありますが、それらは同じ責務ではありません。
実際のところ、凝集度の高いプロシージャーは、2つの大きなカテゴリーに分類される傾向があります。キノコが販売できるかどうかの判定や、腐敗しきい値の計算など、ビジネス目的およびビジネス ルールを表すものもあれば、在庫記録または継続的な検査結果の読み取りなど、技術的問題を処理するものあります。それらの責務が別々に分けられているときは、プロシージャー型RPGコードは柔軟で理解しやすいままです。それらが混ざり合うと、すべての変更が、必要以上に難しくなります。
ユーティリティ プロシージャーの罠
ユーティリティ プロシージャーは、多くの場合、それぞれ適切な意図を持って導入されます。たとえば、一般的な日付フォーマッター、再利用可能なストリング クリーンアップ ルーチン、キノコ種別コードを正規化するヘルパーなどがあります。注意して使用すれば、これらのプロシージャーは、重複を減らし、一貫性を高めることができます。
すべてがユーティリティのように見え始めると問題が生じます。長い年月の間に、多くのRPGシステムには、ある時に複数のプログラムが必要としたというだけの理由で存在している、関連性が薄いプロシージャーでいっぱいのサービス プログラムが溜まっています。これらのサービス プログラムには、1つにまとめるための統一的な概念がないため、たとえ個々のプロシージャーが小さいままであるとしても、凝集度はモジュール レベルで失われています。
また、目的が明確化されていないサービス プログラムは、循環依存の温床にもなります。サービス プログラムが、明確に定義された機能ではなく、様々な有用なプロシージャーを集めたものとして存在しているときは、それは、必然的に、同じように明確に定義されていない他のサービス プログラムに依存し始めます。時間が経つにつれて、それらの依存関係は、双方向に向かい始めます。最初は再利用できて便利だと思っているものが、別々にコンパイル、テスト、または判断すると問題が起こるサービス プログラムに変わってしまいます。循環依存は、偶然ではありません。それらは、以前に凝集度が失われ、改善されなかったことを構造的に示しています。
凝集度の高いサービス プログラムは、キノコ在庫管理または品質検査ルールなど、担当分野または機能を表しているはずです。サービス プログラムがどのようなことを担当しているかを1つの文で説明するのが難しくなったら、それはすでに便利に使える限界を超えるほど大きくなっているということです。
凝集度は再利用を安全にさせるもの
凝集度が低いと、単にコードが読みづらくなるだけではありません。再利用が危険になります。プロシージャーが、その名前またはインターフェースが示唆するよりも多くのことを行っている場合、そのプロシージャーを新たなコンテキストで呼び出すことは、確信のないままリスクを冒すことになります。開発者は、十分に理解していない副作用を頼りにし始めます。あるいは、再利用をすべて避けて、代わりにロジックを複製します。結果的にどちらもシステムを徐々に劣化させます。
凝集度が非常に高いプロシージャーは、予測通りに挙動します。キノコの品質保持期間を計算するプロシージャーなら、きちんとその処理を行うはずであり、それ以上のことは何も行うはずがありません。そうした予測可能性こそが、プロシージャー主導型RPGシステムを、脆弱にさせることなく、時間とともに拡張可能にするものです。
凝集度は毎日の判断
凝集度は、一度プロジェクト開始時に設計したら、後は忘れてよいものではありません。それは、プロシージャーが修正されるたびに行われる判断です。
私はすでにキノコのデータをロードしているので、ついでにこれをここに追加しようと考えた瞬間、設計判断がなされたことになります。時には、その判断が理にかなうこともありますが、多くの場合、それは今後何年間も明らかにならない、ゆっくりと進む設計欠陥の第一歩となります。
プロシージャー主導型RPGは、その時に立ち止まって、単純だが耳の痛い質問を自らに尋ねる開発者にご褒美を与えます。これはまだ同じ責務なのですか。質問の答えがノーである場合、適切な対応はたいてい楽ではありません。それでも、そちらを選ぶことが結局は正解なのです。
