WEB+DB PRESS vol.49 にて、DRY 特集(第一特集)の企画およびコラムを書かせていただきました

book

WEB+DB PRESS Vol.49

WEB+DB PRESS Vol.49

arton さん、 id:kwatch さんと第一特集「[現場で役立つ] DRY の基礎知識」を書かせていただきました。といっても誌上に私が書いたのは2ページのコラムのみ。

今回の私の主な仕事は、第一特集の企画者として arton さんに執筆の依頼と打ち合わせをしたこと。そして、書き上がってきた arton さんの原稿を真っ先に目を通すという光栄な仕事をさせて頂きました。


件の arton さんの特集記事は非常に面白いです。何故かというと、WEB+DB PRESS にしては珍しい議論を珍しい切り口で語っているからです。


企画会議を行い、arton さんに執筆のオファーをし、打ち合わせで文章の大体の方向性を議論して、その後自分はコラムの執筆に入り、そしていざ arton さんの初稿が来たときの驚きは、思わずうなるほどでした。打ち合わせの時に話した内容の斜め上を行く記事だったからです。arton さんの狙いについては、arton さん本人がエントリに書かれています。


なお、私が書いたコラムに関しては、テストコードの重複に関する終わらない議論を、終わらない感じそのままにコラムにしました。テストと DRY について考えるヒントにしていただければと思います。


今回 DRY 特集を執筆した著者の多分全員が感じたであろうことが、「DRY にはまだ確固たる答えが無い」ことです。

DRY 原則は、村上さんによって『すべての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない。』と訳されています。執筆している期間中に、何度もこの訳に戻ってきます。


今回私は以下の URL を執筆の参考にしました。

これらの URL の議論を読むと、「DRY って要するにコードに重複が無い状態だろ」などと考えていたら、全然違うということにきっと驚くでしょう。かつ「みんな DRY について色々違うことを言っているな」ということにも気付くのではないでしょうか。
(kwatch さんも同様の感想を書いていますね)


DRY を積極的に第一の価値として取り込んだ(つまり設計判断において他の価値/原則よりも高い位置に置いた) Rails 、そして Rails 以後のフレームワークは、 DRY に関するひとつの思考実験であると考えられます。DRY を追い求めることがどういう結果を生むのかは今後それらのフレームワークが教えてくれるでしょう。


DRY とは何で、何が正しいのか、または何が望ましいのか。答えを求める読者の方には足が宙に浮いたままのような読後感を残すかもしれません。伝えたいのは、自分の頭で考えるということです。


DRY は "Principle" つまり「原則」です。Value でも Practice でも Pattern でも Idiom でも無い、ということの意味を、お読みくださった方ひとりひとりに考えていただくことが出来れば、狙いは成就されたのかなと思います。