前回に続き、シンプルで、美しい設計について考える。開発工期の短期化が期待される時代とはいえ、特に当初の設計時には美しい設計の再追求が望まれる。修正に伴う事故の防止や保守費の抑制を図るうえで欠かせない取り組みだ。
 |
特にオンライン処理では、異常処理、例外処理が中心である。そのためSEや設計者は、設計、テストなどの各プロセスで、考えられる限りの例外ケースに入念に対応しなければならない。
ただし、例外ケースを全部洗い出しても、それを個別に処理していたのでは、プログラムは複雑で汚いものになってしまう。表の形にまとめ、ケース分析をしたあとに、表の各マスの隣同士が同じ処理に合わせられないかを考えてみることだ。マスのほとんどは例外ケースや異常ケース、さらには基本的にあり得ないケースであることが多いだけに、やるべき機能や処理は同一にまとめられることが多いはずである。
表の中で同じ処理をする面積が増えれば増えるほど、全体の処理は簡明になるはずだ。仕様の詳細を決める段階から処理の共通化を図り、よりシンプルなシステムの実現を目指したい。
 |
ソフトは、ソフト自体の名前から始まって、アドレス、テーブル、レコード、データなど、あらゆるところで名前が必要になる。決めるのは設計者の自由であり権限でもあるが、ソフトは長い期間使われ、修正され続ける特徴も持っているし、後からソースを見たり修正したりするのは別の人が担当することが多い。分かりにくい名前や他と混乱しやすい名前では、修正ミスを出しやすく、事故の原因になりやすい。
できるだけ短く、かつイメージがぴったりしている名前を付けることが長命を支えるために大事である。「とりあえず仮の名前をつけて後から正式に」というやり方では混乱を起こしやすい。“あだ名”が定着してしまう前に、適切な名前を付けることが肝心である。
 |
システムの安定稼働のためには、操作ミスを減らすことも大事である。そのためには、すべての操作を極力統一すべきだ。例えば、操作者を確認するために、名前や社員番号、生年月日、暗証番号などを入力することもあるが、この入力順や、全角/半角などの入力字体などが、操作ごとに異なるようでは「統一性」という美しい設計の条件を満たさなくなる。
特に異常時の操作と正常時の操作を統一することが大事である。本番運用中に事故が起こり、対策のために普段と異質な操作を要求されると、オペータが戸惑って誤操作を犯すという二重の悲劇に直面することになりかねない。
 |
美しい設計は保守性の良いシステムの実現に極めて重要である。逆に保守性の悪いソフトとは、基本的に美しくないソフトだといえる。保守性の悪いソフトの特性として、データの重複/散在、無秩序な名前、複雑なインタフェース、データと論理の過依存などがよく指摘される。
同じデータを設計者ごとに勝手な場所に勝手に定義して使っていると、そのデータを修正する時、修正漏れが発生しやすくなる。同じデータはシステムのなかで1カ所に定義されなければならない。また名前の付け方に一定のルールがないと、システムの理解が難しくなる。そして簡明なインタフェースはまさに美しさの基本である。
さらにデータと論理の依存関係も1対1の関係が継続されることが大事であるし、論理とデータは独立であるほうがさらに混乱は少なくなる。
