コードを書いてると「これ、同じようなコードあるから共通化した方がいいな」ということがよくある。
共通化する？
（僕はJava好きなのでJavaを思い浮かべながら書くけど）親クラスにくくりだしたり、ユーティリティクラスをつくったり。
そうすることで、ロジックをひとつの場所にまとめることができて、仕様が変わったときにはそこだけ修正すれば大丈夫。平和。
コードレビューで気づくのも伝えるのもそんなに難しくないし、伝えられた側も「確かに」って対応しやすい。
どう共通化する？
ちょっと難しいなと思うのは「同じような処理だけど意味が違う」場合。
例えば、消費税計算で価格の8％を計算して返す処理と、8％の割引をするときに計算して返す処理とは、同じ「8％を計算する」という処理だけど、どう共通化するかはちょっと考えたい。
消費税が10％になったときに、割引も10％にはなって欲しくない（あ、いや、買う方としてはそうなってくれたら嬉しいけど！）。
その場合は「8％を計算する」という処理は共通化することができるけど、「消費税を計算する」と「割引を計算する」は共通化しないってことなんだろう（実際は、僕は「8％を計算する」という処理自体、共通化しないだろうな）。
これをコードレビューで見つけるためには、処理自体だけじゃなくて、意味を考える必要があるし、伝えるときにも意味のディスカッションをすることになる。
共通化しない？
んで、難しいなと思うのは、処理だけじゃなくて意味も同じようなものなんだけど、レイヤーやコンテキストが違う場合。
例えば、DBのデータモデルと、ドメインモデルと、ビューモデルで、同じようなモデルを持ってるんだけど、それを全部共通化して1つのモデルで表現しようとすると、どっかのレイヤーの変更が別のレイヤーにまで影響してしまう。
コンテキストって点だと、複数のアプリで「このロジックは意味が同じだから共通化しよう！」って安易に共通化すると、そのロジックが変更されるときに両方のアプリをリリースしなきゃいけなくなってしまったり。
別のチームに分かれてる場合は分かり易いけど、同じチームで両方見てる場合には、レビューでも伝えるのむずいかなぁ。
ここでちからつきた。おはよー。(*´∀`*)ノ
共通化の方法には
とかあるね。今日もがんばるー！
