Redundancy is evel

Don't Repeat Yourself という原則がある。
DRY Principle というやつだ。

冗長性を取り除く方法がない言語ならまだしも、高い抽象化が可能な言語ならば、 DRY Principle は絶対の原則だ。なぜコードの冗長性が悪いのか。その理由は コードコンプリートと Orthogonality and the DRY Principle ( AndrewHunt と Dave Thomas が受けたインタビュー) に書かれている。

ここではコードコンプリート第二版第二十四章 から一節を引用しよう。

■コードが重複している
　重複したコードがあることは、ほぼ必ずと言ってよいほど、最初の段階で設計が完全に分解されていないことを意味する。コードが重複している場合は、修正を並行作業で行わなければならない。つまり、ある場所を変更したら、必ずもう1つの場所も並行して変更しなければならない。このことは、AndrewHuntとDave Thomasが定めた「DRY（Don't Repeat Yourself）原則」にも違反している（Hunt and Thomas 2000）。これを最も的確に表現しているのはDavid Parnasの「コピーアンドペーストは設計ミスである」だろう（McConnell1998b）。

2箇所重複している ( 同じことが書かれている ) ところがあれば、 将来必ず2箇所修正することになる。100箇所重複していたら、将来必ず 100箇所修正することになるのだ。

え？なんで「必ず」って断言できるかって？
Fred Brooks とコードコンプリートを思い出そう。

現実：コードは最初の開発時に大きく進化する。最初のコーディングで行われる変更の多くは、少なくとも保守段階で行われる変更と同じくらい大がかりなものだ。プロジェクトの規模にもよるが、コーディング、デバッグ、単体テストは、一般的なプロジェクトの作業の30～65%を占める。仮に、コーディングと単体テストが一直線につながっていたとしたら（つまり変更がまったくないとしたら）、プロジェクト全体の20～30%以上を占めることはないはずだ。だが、よく管理されたプロジェクトでさえ、要求の変更は1か月に約1～4%の割合で発生する（Jones 2000）。要求を変更すれば、それに伴ってコードが変更される。そのためにコードが大幅に変更されることもある。

そう、作ったコードは間違いなく変更が加えられるんだ。
1～2箇所の変更ならまだやろうという気にもなるけど、
100箇所も変更するなんて1度たりともやりたくない。
( やったとしてもどっかにミスが残るものです。)

わたしがなるべく冗長性がないようにコードを書く理由はここにある。 作ったコードに後から手を加えることは たいていの場合とてもとても大変な作業だ。その「変更よろしく！」 といわれたときの苦労を少しでも減らしたいからなんだ。
( 焼け石に水の状況も多々あるけど )

可読性が大切(*)なのはいうまでもないことだけど、そのために将来 10倍100倍の苦労をするというトレードオフは、わたしはしたくない。

もし、「DRY Principle なんて知ったことか」とか 「そんなことをしたら可読性が低くなってしまう」と考えている方は もう一度コードコンプリートと Pragmatic Programmer を読んでほしい。 きっと冗長性をなくすことが大切だと気づくはずだ。

それから、わたしに DRY Principle の大切さを理解させてくれたのは havana だ。
わからず屋のわたしに繰り返し DRY Principle の重要性を教えてくれた 親友の havana に心から感謝します。本当にありがとう。

(*):可読性をそれほど損なわない書き方だってあるし、場合によっては 冗長な書き方よりもより簡潔になることだってある。わたしの経験では 可読性論者は特定のキーワード ( goto とか ) に過剰に反応しているだけ の場合が多い。