前回は「そもそも設計していない」という症状を書いてみましたが、今回は、設計技法の適用がうまくいっていない例を紹介します。

まずは、アセンブラ時代の名残を持つソースコードです。典型的な例として、global.cやcommon_data.cというファイル名が、その症状です。アセンブラ時代は、データは一箇所にまとめて、グローバルに持つ、ことが定石でした。グローバルデータにしないとICE（インサーキットエミュレータ）で追いかけられない、そもそもセクションを切るのでDATAエリアにまとめて置く、という設計をしていました。その名残で、Ｃ言語になっても、データを一箇所に持たせている例を、たまに見かけます。データを集めたファイルが、global.cやcommon_data.cという名称なのです。

アセンブラ時代は、全体を見渡すことができて、どこでデータは使われているのかを把握できたので、グローバルでも問題はあまりありませんでした。しかし、複数人で開発するようになると、どこで使うのかを、自分ひとりで管理することができません。その状況で、データをグローバルスコープにすると、どこで使われているのか把握できなくなります。これが、共有データの問題で、結合度が密になります。疎結合でなくなることになり、思わぬ副作用が発生してしまいます。Ｃ言語で、複数人で開発する場合は、データはファイル内スコープとした方が良いでしょう。ファイル内で、データをstatic宣言することになります。

もっと凄い例が、神様データ、です。このデータ構造を辿れば、すべてのデータが取り出せます。そのデータを使って、各関数は動いてください、というような設計です。お分かりですよね、データが少し変わっただけで、すべての関数が従わなければなりません。データにすべての関数が支配されている状況なので、神様データと呼んでいます。組込みシステムが充分に小さかった時代、そもそも「組込み」なんて言葉もなく「ファームウエア」などと呼ばれていた時代には、ハードウェアのレジスタ値を集めて、すべてがそれに従って動作させていたこともありました。（もちろん、そんなことをしていないエンジニアも多くいました）ハードウェアを動かしながら、徐々に積み上げていくと、結果として、神様データが残ることもあります。しかし、神様データは、プログラム全体を密結合にしてしまうので、硬直したソフトウェアになってしまいます。