関連

DRY原則

mizchi DRYより単一責任原則のが遥かに優先されると思ってるので多少冗長でもコードまとめるの避けてるしDRYって名目でリファクタする人のレビューはかなり緊張感がある

mizchi なんならDRYって概念そのものがよくないとすら思う。単一責任原則を破壊して異なる責務のコードを混ぜる大義名分に使われるのなら、DRY概念そのものが有害であるとすら言えると思う

mizchi 初心者にリファクタリングを教える時にDRYを教えるのは簡単なんだよね。見た目が似てればそれはDRY、みたいに言えるから。だけど異なる責務のコードが合成されていって特定ユースケースを解くだけの分離不可能な塊になったときにマジで身動き取れなくなる

mizchi 絶対に異なるコードを混ぜてはいけないわけではなくて、末端のヘルパーならそういうコードは認められると思う。例えばテスト用のヘルパーの関数なら混ざっててもよい。逆に言うとヘルパーが肥大化してはいけないし、ヘルパー未満のものは混ざってはいけない

mizchi 具体的にどういうコードがアンチパターンかというと、ウェブフレームワークで View State に渡す中間データを横から引っこ抜いて逆に Model に書き戻すコードなどです