読者です 読者をやめる 読者になる 読者になる

山下寛人オフィシャルブログ

オイシックス株式会社 執行役員 システム本部長 山下寛人の公式ブログです。

DRYは本当にいいのか?

プログラム開発においてDRYの原則というものがあります。Don't Repeat Yourselfの略で、同じ処理をするコードを何回も書かないよう、メソッドを作ってまとめたりしなさいよ、ということです。

同じ処理をするコードを何回も書くということは当然ながら非効率です。しかしそれ以上に仕様変更する際に漏れが発生しやすくなるリスクがあります。オブジェクト指向で設計すると自然にDRYになっていくという面もあります。コードがまとまると変更が局所化でき、変更コストも少ないしテストも少なく済みます。こういう観点からコードレビューでは同じような処理をまとめるよう指摘してきました。

しかし本当にそれがいいのか最近では疑問に思えてきました。変更が局所化できる反面影響範囲が広くなるので予想外のところで不具合が起こったりします。昔作ったメソッドができが悪く使い回したら予想外のトラブルを起こしたりします。例えば消費税が上がるというようなとき税率の変数を1箇所5%から8%に変えれば済むようにできれば理想的ですが現実はそんなに甘くありません。結局プログラム全体を洗い出して少なからず開発はしなければなりません。変更箇所が少なくできてもシステムテストは影響する画面全般テストしないといけません。共通処理になっているところを変更する場合、全部変わったら困ることがあり、条件分岐を作らないといけなくなる場合もあります。

影響範囲の問題の解決策の1つにはCIがあります。しかしこれも万能ではありません。

以前、処理の共通化はしない方針でやっているという会社がありました。消費税対応のようなことをやるときにはまとめて置換すると言っていてDRYと正反対の考え方にカルチャーショックを受けました。

データベースには正規化という考え方があります。一事実一箇所という原則で更新異常をなくそうという考え方です。しかしこれも理想であって現実はある程度非正規化したほうがよいです。過去時点の情報が必要な場合がよくあって、そういう場合正規化が行きすぎていると対応できないことが多いです。

ということで、局所化にはデメリットもあり、重複していることにもメリットがあり、テストは結局影響するところ全体的にやらないといけないということで、どちらかというと重複していたほうがいいのかもしれないと思うようになってきました。