現行システムのプログラム設計問題点（元記事から転記）
- プログラム間で統一されていない
- モジュール変数が多用されている
- 抽象化や部品化が進んでいない
- 依存が複雑
- コメントが役に立たない
- 構造を示すドキュメントがない
モジュール変数が多用されている
もう少し具体的に
- VB.NETのプログラムだがクラスではなくModuleを使っている。
- プログラム全体で使用される情報は、グローバル変数のように仕様書上に定義されており、Moduleを使って実装されている。（以降グローバル変数と記す）
- Formクラスのメンバ変数も存在している。基本的にメイン画面１画面であるため、メンバ変数とグローバル変数で違いがなく、同じように使われているし、見ている方としても違いを識別しなかった。
- 各変数の役割とライフサイクルが不明瞭であった。
- 仕様書上の説明は１行簡単に用途が記載されているだけである。
それがどう困るのか
モジュール変数だから悪いわけではないが、どこからでも利用できることで、やはり各関数（処理）の結合度が高くなっている。
- どこで更新しているのかわからない。
- ある関数の同じ処理をしていても、モジュール変数が取りうる状態が不明瞭であり、考慮すべきケースがわからなかった。
- どんなルールで管理されているのか／ライフサイクルがわからないため、ある処理から利用していいのかわからない。
- 自分はテストなので不具合修正はしていないが、テストを進めるために暫定対処することがあった。問題がおきた処理・時点でモジュール変数で保持している情報を利用することがあった。しかしこの修正が常に適切なのかは全く判断がつかなかった。
結局は処理（利用する側）次第だが、どうしても使える状態にあれば使ってしまう。そういう意味では「させない」「出来ないようにする」ことも、全体を統制するうえでは大切なことだと感じた。そうしないと何も考えない人はやってしまう。できることが多いほど、バグを作りやすいのかもしれない。割れ窓の理論に近いところがあるかもしれない。悪いお手本が目の前にあると、他の人もやってしまう。だから「できない」ようにして置かなければならない。
どうすればよかったのか
これはなかなか難しい。多分このPGはVB6などの時代から存在しており、少しずつプラットフォームを変えてきたのだと思われる。当時はオブジェクト指向というよりは機能毎にクラスもしくはモジュールを作っていた時代である。また１画面１フォームに主な処理を実装するモノリシックな構造が普通であった。ではどうすればよかったのか。
- 整理と文書化
- 文書化して見えるようにすることが重要と思う。そもそも逸脱しているのか判断出来なければ守ることも出来ない。
変数は使われる側なので、変数自体で解決はできない。やはり処理側の見直しが必要である。各処理はできるだけ直接参照を避け、パラメータとして受け取るようにする。その結果、モジュール変数の利用箇所は、幹になる処理に限定されていく。そうなれば見通しがグッと良くなるはずだ。またパラメータ化した際に、モジュール変数に対するアクセス状況も理解が進み、整理できると思われる。
