プログラミングをしていると、「汎用性」について考えさせられる。 なにかモジュールを書いているとき。インターフェースや変数を定義しているとき。 汎用性が高くて使いまわせるほうが良いように思える。

しかし、高すぎる汎用性は、将来的に強度を弱めてバグを生み出す危険がある。

最近、「将来のユースケースのコントロール」について気にしている。

コードを書いたときは「これ便利じゃん」と思って変数やインターフェースをモジュールから公開する。しかし、それが将来にわたり正しく使われる保証は無いことに注意が必要だ。コードを保守するのは他人だ。「将来の自分」もほとんど他人だ。コードに対しての留意事項なんて忘れるに決まっている。 一見して便利に見えるものや汎用的に見えるものは、意図しない使われ方をされてしまう恐れがある。また、依存を集中させる危険もある。多くの被依存があると、変更が難しくなる。「えいや」で変更することで、依存元モジュールが意図せず壊れることもある。

そこで、例えば、モジュールやインターフェースの名前付けを工夫することになる。コーディングにおいて名前はドキュメントのようなものである。意図を伝え、役割をせばめるような名前にすることで、予防になるというものだ。

ことはコード内のモジュールだけの話ではなく、NPMのようなパッケージングシステムでも発生する。 たしかに短い名前は覚えやすく、利用されやすいので、クールかもしれないが、それは今現在のことしか見えていない開発者の自己満足になっていないだろうか。