「現場で役立つDRYの基礎知識」を読んで

Tech

WEB+DB Press Vol.49の特集で「現場で役立つDRYの基礎知識」というのがあって結構お勧めだったらしいので読んでみた。以下読書感想文のようなもの。
DRYというのは、Don't Repeat Yourselfの略で、「知識(情報)を分散させず、明確に保ち、無意味な複製を保持しない」というような意味で使われる。RDBMSでいう正規形のようなものと思えばよいのか。DRYはこれをシステム全体に対して適用する思想である。通常「DRYの原則」「DRYである」という形で使う。
顕著な例として、DAOの構築。既にDBがあるのであれば、そこにテーブル構造は保持されているのだから、わざわざテーブル構造をDAOに記述する必要がないといった考え方。双方で個別に持つことで食い違いが発生する可能性がある。
しかし、DRYはより多くのリソースを必要とすることが多いと思う。動的に余計な処理をするのでCPUパワーを消費するし、DBとの通信が発生する。ところが、この欠点が気にならないほどにCPU性能は向上しているし、それよりもシステムの複雑さが進み、テストで拾えなかったうっかりミスが増えてしまっている事の方が重大である。
DRYの考え方は遡るとアセンブラやCの時代にもあった。同じような処理をcopy&pasteせず、サブルーチン化するとか、システム全体のグローバル変数はEXTERNマクロを使って定義と宣言を共通化するとか。いくらドキュメントを書いて整備しても一人の人間が記憶しておける量の限界がある限り、うっかりやら間違いやらは発生する。いかに楽をしながら品質を向上させるかという問いへの一つの答えであり、昔からその思想はあった。DBの正規形もその一つである。
DRYの考え方で目新しかったのは

  • ソースコードに中のコメントはDRY原則から見ると冗長である。しかしながらソースコードは「なにをするか」であるので、「なぜそうするか」という情報を含んでいないため、そのようなコメントはDRYであるといえる。コメントの書き方に注意が必要である。
  • 使おうとしている既存のソースが古臭いやり方をしているからと言って別メソッドで同じ処理をさせるのはDRYではない。DRYでやりたいなら、既存ソースをリファクタリングすべき。
  • テストコードをDRYにするべきかどうかという議論がある。不要な重複を排除するにはリファクタリングが必要で、原則リファクタリングにはユニットテストが必要である。テストコードのリファクタリングのために、テストコードのテストコードが必要となってしまう。(ちなみに私はテストコードはソースコードとは区別するべきで、DRY原則の対象外と考えている。あえて言えばテストコードはDRIP : Don't Repeat If Possibleとしたい。)

こんなとこだろうか。
あとはこういう指針が広まると熱狂的な信者が沸いて出てくる。「DRY原則は不可侵」みたいな輩ね。自分はDRYではなくてDRIPでいきたい。DRYにすると速度が低下する可能性は指摘したとおり。DBの正規形を「必要悪として破る」度胸も必要。出来る限りDRYにしておくことで開発者は注意しなければならない点が減るから、DRYから外れた部分について、コメントばっちり、ドキュメントばっちり書いておくことで、補完できると思う。ただこれができるのは、アーキテクチャとして説明つく部分だけだろうな。
今はCPUリソースも豊富だけど、記憶リソースも豊富。重複した中間データがあっても何も問題ない(リソース的には)。そのライフサイクルさえきちんと管理できていれば、それはDRIPだと思うわけで。