『今あえてDRY原則に向き合い』のスライドを見て考えるところ

『今あえてDRY原則に向き合う』

https://speakerdeck.com/shinpeim/jin-aetedryyuan-ze-nixiang-kihe-u

はてブ見てて、そうだよね！と共感する記事を見つけたので、私の考えている事と共にシェアします。

スライドの概要

DRY原則ってタイトルにはついてますが、DRY原則を実践するためのノウハウなスライドではないです。

DRY、DRYって言われる理由ってなんだっけ？ただ実践すれば幸せになれるんだっけ？本当にそれだけ考えれば良いんだっけ？と、いろいろな気づきを与えてくれる内容になっていますので、ぜひご一読ください。

私の考えたこと

Fuga原則だとかHogeパターンだとか、良いとされている設計原則やデザインパターンはいろいろありますが、これらはコードを鍛え上げた結果として、共通して現れてくることの多い特徴やパターンに名前をつけただけだと思っています。
※実際に世の中でどういう定義付けがされているかは知りません、私がそう理解し、また実感しているという話です。

つまり、アカデミックに理論を組み立てて作られたというわけではなく、何度もコードが変更されていく過程で、変化に対して柔軟に対応できるソフトウェアにするにはどうしたらよいか、その都度真剣に考えて鍛え上げていく、そういう実践の中で自然発生的に生まれたものなのでしょう。
※実際に世の中で(ry

そうして出来た良いコードにFuga原則だとかHogeパターンだとかという名前をつけてカタログ化することで、私のような凡人エンジニアでもそれを参照し真似することをでき、スキルとして身につけていくことができます。

しかしながら、現実問題としてFuga原則とか1つ2つ知ってるだけじゃ良いコードを書けるスキルなんて身につかないんですよね。

Aな傾向ではこのデザパタ、Bな傾向ではこの原則、Cの傾向ではある原則とデザパタを組み合わせる、といったように引き出しを増やして、組み合わせるスキルを磨いておかないと、何でもかんでも1つか2つの原則・デザパタで解決することになってしまうからです。

解法を1つしか持っていなければ、目の前にある問題に対してその解法でしか解決できないわけですから、そりゃ効率的で変更に強い良いコードなんて書けるわけがありません。
※かくいう私もまだまだ修行中です。頑張ります。

1234を55回足した答えは掛け算を知らなくても足し算で解決できますが、掛け算を知っていれば効率的に解けるのと同じです。『金槌しか持っていなければ、すべての問題は釘に見えてくる』ってやつです。

私は『DRYにしなきゃ』しか考えないエンジニアが書いたコードが○○コードと言われてしまう所以はここにあると思っています。

まとめ

『筋の良い分割とはどういう分割なのか？』らへんに触れることがこのスライドの主題だと思います。その主題に沿ってまとめるならば『筋の良い分割を実践の中で導き出すためには、多くの設計原則とデザインパターンを知っておき、それらが何を解決してくれるのかを理解しておくこと』が重要だと私は考えていると主張しておきます。