汎用性のない実装はするな

掲題のとおりですが汎用性のない実装、いわゆるオレオレ実装は本当やめてほしいし、やめたほうがいいということを布教活動もこめて書き留めておきたいと思います。

とある事例

ちょうどフロントエンドの実装をしていて FileList と呼ばれるプロトタイプに関して調べていました。自分の目的としてはできるならこの FileList を Array のように集合関数を用いてクロージャ内で処理を行いたいなと思っていました。

ところがこの FileList は配列のような振る舞いをしており length という自分が内包する要素数を返却するプロパティを持っているのにもかかかわらず Array とは似て非なるものです。Array のような集合関数が実装されていないだけでなくイテレートすらできません。

すると当然 FileList.map(file => something()) みたいな記述はできないわけです。でどうしようかなとネット上を検索していたのですが、for ループで回すシンプルな方法がいいと記事もありました。いろいろ調べ、そして FileList.prototype を拡張しちゃえばいいじゃないか。素敵。みたいな記事に出会います。

そういうのはヤメロ

勘弁してほしいです。変な実装するなと。自分が共同作業するような位置にいるわけでもないですが、それでもそういう記事を見るだけでゾッとします。

このゾッとするのは直感です。直感はものすごく大事です、でも言語化しないと記事としては伝わらないのでいくつか言語化してみると

  • 一般的ではない。他人が初めて読んだ際に混乱しか呼ばない。
  • 実装が洗礼されていない。ごくごく普通のエンジニアが表面だけをなめて実装したものなのでたかが知れいている。
  • 公式の言語仕様による影響を受ける可能性が高い。その瞬間バグへと変貌する。
  • 将来の自分でさえ忘れていると思う

といったところです。

保守性というのは記述が短くなることだけではないです。

例えば上記の FileList の例ですと prototype を拡張するなんてバカげたことをするくらいなら、多少冗長でも大人しく for ループを記述するほうが圧倒的にシンプルで長期的に見て保守性が高いです。

まとめ

できるだけシンプルに、混乱のない、美しい世界を心がけたい。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください