DRYが避けよと言っているのは、「見た目」ではなく「知識」の重複

「似てる処理があったので、共通の関数にまとめておきました」——レビューでよく見る一言ですが、数ヶ月後にその関数を直したら、無関係な画面まで壊れた経験はないでしょうか。

『達人プログラマー』の定義は「知識」

DRY（Don't Repeat Yourself）は「同じコードを書くな」と覚えられがちですが、原典である『達人プログラマー』の定義は「同じ知識が、複数の場所に重複して存在してはならない」というものです。コードの見た目ではなく、知識の重複を指しています。

たまたま同じ形は、重複ではない

見積もりの端数処理と、請求書の端数処理が、たまたま同じ計算式だったとします。ここで「同じだから」とひとつの関数にまとめると、あとで会計方針が片方だけ変わったときに事故が起きます。共通化した関数は、どちらの都合で直せばいいか分からなくなるからです。

判断基準は「一緒に変わるか」

消すべき重複かどうかは、「この二つは、同じ理由で一緒に変わるか」で判断します。一緒に変わるなら重複を消す価値があり、別の理由で変わるなら、見た目が同じでも別物として扱うほうが安全です。

引き継いだコードで見かけたら

引き継いだコードに「共通化された謎の関数」が残っていたら、それが本当にひとつの知識を表しているのか、たまたま形が似ていただけなのかを、まず疑ってみてください。無理な共通化を剥がすのも、立派なリファクタリングです。

現場を渡り歩く人ほど、持ち込みに注意する

SES常駐では、前の現場で覚えた「共通化のパターン」を、次の現場にもそのまま持ち込みたくなることがあります。ですが、業務のルールは現場ごとに別物です。前の現場で同じ知識だったものが、次の現場でも同じ知識とは限りません。 見た目が似ているというだけで手癖のように共通化すると、その現場の担当者しか気づけない事故を持ち込むことになります。共通化する前に、「この現場の、誰の知識か」を一度確かめる癖をつけておくと安全です。

似たように「知っていると判断が変わる」原則は、エンジニアの型にまとめてあります。自分の仕事の流儀を知りたい人は、3分の自己診断もどうぞ。