DRY原則ってありますよね。Don't Repeat Yourself。
こいつ結構くせ者な原則だと思っていて。
言うは易く行うは難し。いや行うのも簡単なんだけど。
こいつの厄介なところはその「行うは簡単」だけど「戻すのは難しい」というところだと思う。
「共通化しよう！」「同じ処理を何回も書くのやめよう！」って言葉、プログラミング入門書とかでもよく書いてあるイメージ。
そのままfor文の紹介が始まったりして。
そうやって教えられると「同じ処理っぽい！共通化しよ！」みたいな思考になってしまって、短絡的な共通化が行われてしまったりする。
見た目は同じような処理でも実は違う業務だったりして、共通化すべきものとそうでないものを見極めるというのはそこそこ難しいのではと思っている。
これは深い業務理解とそのシステムの将来を予想できないといけない。
その時は判断出来たとしても正答率100％にはならないと思う。
ミノ駆動さんのUserクラスみたいなことになるわけです（この動画大好き）。
クソコード動画「Userクラス」 #DXD2021 pic.twitter.com/JOIIl8IuwS
— ミノ駆動 (@MinoDriven) 2021年4月10日
Userクラスでも触れられているように、共通化を解除するのは非常に大変。
慎重に依存を調査したり、場合によっては全部テストしなおすとか。もはや作り直した方が早いのでは？みたいなこともある。
私は、DRY原則が適用できそう！と思ったときは、自問自答をする。
ほんとに共通化しても大丈夫か？
もし共通化を解かないといけなくなったときに困らないか？
自分だけで判断できないなって思ったら詳しい人に相談したりして。
それでもわからない場合は、判断を「保留」する。つまり共通化はしない。
判断を保留すると、学びは得られないが間違えることもない。
今、重複の多い微妙なコードだと人から思われたとしても、未来に保守する人が苦しまないように、DRY原則は使いどころをしっかり見極めたいなと思う今日この頃。
