エンジニアのソフトウェア的愛情

または私は如何にして心配するのを止めてプログラムを・愛する・ようになったか

ダメな設計は…

ダメな設計は、その設計を変更できない頃になって、ようやくダメとわかる
再び引用風ですが、引用ではなくて、わたしの今日の心象です。

以前から、作りがよくないと思われていた、社内のライブラリ。そのライブラリが、さまざまな状況で利用されるようになるにつれ、デザインのまずさが表面化してきました。かなりの問題を内在させているようですが、そのライブラリの開発者がとった対策は「運用でカバー」。利用者に無理を強いることで、ほころびを繕うという手でした。あまりにも、広く使われてしまい、影響が大きすぎるために変更できない状況に陥っているのか。あるいは、あまり考えたくありませんが、開発者がいまだにデザインのまずさに気がついていないのか。

なぜそれほどに、よくないデザインが、正されることもなく生き残ってしまうのか、以前のわたしには不思議でなりませんでした。以前のわたしは、大抵のダメなデザインは、設計の段階でそのダメさに気づかれ、取り除かれるものなのだろうと、漠然と想像していました。

よくないデザインが、よくないとわかるためには、比べる対象が必要です。絶対的によくないもの、というものはありません。比べる対象がない限り、よくないデザインと認識されることも有りません。認識されないまま、広まってしまい、やがて不満が噴出するようになっても、デザインがよくないとは、開発した本人には、なかなか気づかれないようです。比べるものがないからです。適さない場合があることは。認識できます。でもそれがデザインからくるもの、という考え方はしないようです。ですから、そのような特別な場合では運用で対処すればよい、そういった考えに流れてしまうのでしょう。やがて、特別な場合だらけになったとき、それが特別でなく通常の場合だと気づき、問題がデザインにあるとわかったときには、すでにデザインを変更できるような状況では、なくなってしまう…。

ダメなデザインをしないようにするためには、ダメなデザインを知ることが一番ですが、ダメなデザインを知るための代償は、小さくなさそうです。