DRY原則について――『達人プログラマー 第2版』を読みながら
お疲れ様です、上凪 羊です。
今回は、読書中の『達人プログラマー 第2版』(David Thomas・Andrew Hunt)からDRY原則について、読んでみての学びをまとめようと思います。
スクールでの学習中、コードのリファクタリングの文脈で教わった言葉なのですが、元ネタである『達人プログラマー』を読んでみるとそれは1つの具体例であり、もっと抽象的に様々な場所で役立てられるという考え方でした。
正直、まだまだその分野について知らない場合、適用されているDRY原則の考え方が理解できないことも多々あるのですが、いつか読み返したときにこの頃はこれくらいの認識だったと差分のチェックもできるかと思いますので分からない部分は分からないものとして、メモのつもりで残しておこうと思います。
DRY原則
DRY原則とは
DRY――Don't Repeat Yourself(繰り返しを避けること)
こちらの『達人プログラマー』においてDRY原則とともに見出しに記されているのは「二重化の過ち」というワードです。そして引用部分の直前では、「開発中の仕様書やプロセス、プログラムの中で知識を二重化してしまいやすいという点」を問題として挙げており、その二重化によって「アプリケーションの完成前から悪夢のようなメンテナンスが始まってしまう」ともあります。
このDRY原則を破るということは、同じ"知識"(これは抽象化された表現であり、それぞれのレイヤーで具体的に指しているものはそれぞれです。そしてレイヤーによってはまだ自分の理解が及んでいないので具体の例を学んで原則をより落とし込めるように理解しないと……)を2箇所以上に記述してしまうということです。
そしてそれは片方を変更する場合にもう片方も変更しなければならないという問題につながります。すなわち、多くの場合、もう片方の変更を忘れて情報に齟齬が生まれてしまうということですね。
原則に違反する二重化の例
コードの二重化
ドキュメントの二重化
表現上の二重化
開発者間の二重化
「コードの二重化」はあくまでDRY原則に反する例の一部であり、「異なった場所に同じことを表現する」という問題を避けるためにはその他の例についても目を向けられなければなりません。
その検査の方策として1つ、
とあります。
「コードの二重化」、「ドキュメントの二重化」は比較的イメージしやすいものですが、まだまだ実践出来るかと言われると自信はないのでこれはコードを書きながら適宜、DRY原則の観点でチェックしていくことを習慣化して行ければと思います。ドキュメントの二重化の直下にあった「データにおけるDRY原則の違反」部分の実例はまだ良くわからないので改めてどこかで読み返してみる必要がありそうです。
「表現上の二重化」はまだ理解が追いついていないですね。
自分が書くコードと、外の世界のものごと(=APIを経由した他のライブラリー、他のサービス、外部ソースのデータなど)という2つの物事の間で、一方が変更されれば他方との整合性がなくなるという二重化について書かれています。
APIやデータソースそのものへの認識を深めて再度挑戦……というのが今のところの所感です。
「開発者間の二重化」はチームで開発していくという中で二重化をいかに防ぐかという話ですので、まだ実感として理解まで達していないのですがこちらは実務に入って経験を積んでから改めて当たると、より理解が深めやすそうに感じました。
上記それぞれの二重化に対して、本書では「既にあるものを簡単に見つけ出して再利用できるようにして、同じものを何度も作成しないような環境を構築する」という対処を最後に教えています。
それぞれのレイヤーでの二重化について、この鉄則を踏まえて意識的にチェックをできれば、DRY原則を開発に落とし込むスピードが上がるのではないかと思います。これは自分でその都度、こういうことなのかなと実感を強めつつやっていければと思います。
終わりに
今回は、『達人プログラマー』のDRY原則について振り返りました。
文中でも書いたように、まだまだ理解できていない部分は多いのですがこうやって1つの記事にまとめようとしたら、読んでいたときよりは整理されてきたようにも思います。
一度読んで終わり、ではもちろん無く、これから長い時間をかけて自分の中で理解と実践のサイクルを何度も回すことが大事ですね。
それでは、お読みくださりありがとうございます。