既存のソースコードの構造と目指すべきアーキテクチャ設計の構造が分かれば、両者のギャップも明確になります。ギャップを狭める、そして、ギャップが広がらないよう技術的なマネジメントが大切です。

ギャップを狭めるためには、既存ソースコードの修正にタイミングで徐々にギャップを小さくしていく、あるいは、一気にアーキテクチャ設計に近づける、などの開発の戦略をきることが大切です。 ギャップが広がらないための施策として、静的構造としては、コンポーネントの依存性マトリクス、動的構造としては、タスクのグレイボックステストが有効です。

・依存性マトリクス
・グレイボックステスト

依存性マトリクスでは、ソースコードのヘッダファイルのインクルード関係、あるいは、関数とデータの呼び出し関係、という依存性の規則を表として可視化することができます。その依存性が、アーキテクチャ設計の規則通りにできているのか、そして規則違反の依存性が増えていないのか、を定期的に観測して、是正措置を施すことができます。

グレイボックステストは、システム全体としてはホワイトボックス、タスク単体ではブラックボックス、でのテストです。プログラムの重要な通り道となる制御スレッドをテストすることになります。小刻みに、何回もテストすることで、パフォーマンスの作り込みも可能となります。

複数人開発のプロジェクトでは、コンポーネント間のつなぎ部分やタスク間のつなぎ部分にバグが潜むことが多いです。担当者同士の連携ミスや暗黙の了解の誤認識により、隙間にバグが生息します。アーキテクチャ設計、及び、アーキテクトは、その隙間のバグを予め検出することも重要な責務です。