🤩

ロジックの共通化はコンテキストごとに

2022/03/17に公開

ロジックの共通化について考えたので記載。

まえがき的な

この記事で出てくるロジックはプログラミングのコードのまとまり全てのことをいいます。
HTMLも、phpのメソッドも全てロジックと記載します。

結論

  • 同じロジックだからといって安易に共通化を行ってはいけない。
  • 共通化はコンテキスト、存在、意味が同じ場合のみ実施する。
  • 綺麗に共通化できると嬉しい。

結論までの思考過程

いいところ

  • 共通化したロジックを呼び出すだけでどこでも同じ振る舞いをしてくれる。
  • 共通化したロジックを1箇所修正するだけで利用箇所全てに反映される。
  • ロジックを書く量を減らせる。

共通化の課題

  • 修正した内容が反映されていいページとダメなページが出てくる。
    • 結局別々の修正が発生することがある。
  • 共通ではないロジックが入ってきて複雑になる。(無理矢理書いた大量のif文。。。)

課題が発生する原因

  • 存在が違うものを、ロジックが一致しているからと共通化してしまう。
  • 共通化するルールに観点が足りない。これらだけはダメ。
    • ロジックが同じだから共通化しよう。
    • このページとこのページのデザイン一緒だからこのHTMLタグは共通化しよう。

原因に対する対策

  • コンテキスト、存在、意味が一緒かどうかを共通化の観点に追加する。

例え話

以下のようにデザイン、表示コンテンツが類似している店舗一覧ページと商品一覧ページがあったとします。

初期開発時は項目が一緒なので以下のように共通のDTOを作成してデータを渡すことにしました。

class ListDto {
  private $name;
  private $description;
  private $thumbnail;
}

数ヶ月後店舗一覧側には住所を追加する改修が起案され、ListDtoを修正しないといけません。
店舗一覧ページに対する改修なのに、商品一覧にも修正影響が出てしまいました。。。

店舗と商品というコンテキストが別の物を共通化してしまったため、不要な影響が発生したといえます。

今回の話だとDTOなので影響がかなり少ないといえますが、HTMLなどが共通化されてた場合、
店舗一覧の時は住所を表示するif文が追加されることになるでしょう。
そうした場合には、商品一覧がこれまで通りのデザインで表示されているかテストする必要が出てきます。
最初は良かれと思って共通化したものが技術負債へと変わってしまいましたね。。。

あとがき的な

初めての記事。
例え話を書くのは難しいですね。
今後もよろしくお願いします。

Discussion