エンジニアをしていると、「処理を共通化しなさい」という言葉をよく聞きますよね。
確かに共通化をすると保守性が向上したり、再利用性が高まるなどメリットは多いと思います。
ただ、闇雲に何でもかんでも「共通化」するのはよくないんじゃないのかなと思ったので、ここで考えを軽くまとめてみました。
過度な共通化の問題点
全く同じ処理を共通化するのは特に問題がないとは思います。
問題があるのは似ている処理の共通化です！
似ている処理を共通化する場合、似ていない箇所を共通処理に含めないといけない分、似ていない箇所をif文などでそれぞれ個別対応する必要があるため処理が複雑になり、かえって保守性が下がる可能性があります。
簡単に数式にしてみると共通化して一つに括り出された処理の中の複雑度は
（共通な部分の複雑度）＋（共通でない部分の複雑度）x （共通でない部分のバリエーション）
という感じになるかと思います。
ここでこの数式を見返してみると、全く同じものを共通化した場合は（共通でない部分の複雑度）x （共通でない部分のバリエーションは0なので特に問題はありませんが、共通でない部分がある場合は（共通でない部分の複雑度）x （共通でない部分のバリエーションが大きくなる可能性があり、共通化する前よりもかえって複雑になってしまうという状況になる可能性もあります。
そのため、共通でない部分は原則、共通処理にまとめないようにするのが良いと思います。
具体例
具体例の説明
【処理A】
- バリデーション1
- バリデーション2
- バリデーション3
- 計算1
【処理B】
- バリデーション1
- バリデーション2
- バリデーション4
- 計算2
をしているとします。
ここで以下2パターンを考えてみます。
- 全てのバリデーションを共通処理に括り出す（似ている処理）
- 共通なバリデーションを共通処理に括り出す（共通な処理）
似ている処理を共通処理に括り出す
【処理A】
- バリデーション
- 計算1
【処理B】
- バリデーション
- 計算2
【バリデーション】
- バリデーション1
- バリデーション2
（処理Aならば）
- バリデーション3
（処理Bならば）
- バリデーション4
どうでしょう。確かに処理Aと処理Bはスッキリしましたが、バリデーションの処理内容が複雑になってしまいました。
次に共通な部分だけを共通処理にまとめてみます。
似ている処理を共通処理に括り出す
【処理A】
- 共通バリデーション
- バリデーション3
- 計算1
【処理B】
- 共通バリデーション
- バリデーション4
- 計算2
【共通バリデーション】
- バリデーション1
- バリデーション2
こうすると共通化された箇所も割とスッキリして見通しが良くなったと思います。
今回の例は結構シンプルなものなので、似ている処理を共通化したことで、複雑になり保守しづらくなるみたいなことはないですが、
実際の現場ですとこれよりもかなり複雑ですので、先ほどの式の（共通でない部分の複雑度）x （共通でない部分のバリエーション）の部分の影響が大きくなります。
補足
ただ、100%同じものだけを共通化すべきみたいにやるのはお勧めしません。
そうすると共通化できるものも限られてしまい凝縮度が下がり、保守性が低くなってしまいます。
そのため、
- 全体の数パーセントは処理が異なっていても可読性を損なわないため共通化
- 概念を抽象化し、具体の観点では異なっていたものを共通なものとして扱う
などの判断も必要になってくると思います。
最後に
という話でした！
お読みいただきありがとうございました！
