釣りキチプログラマー翔平の備忘録 
はじめに
この記事では
- 業務ロジックが重複すると何が悪いか？？
- 業務ロジックが重複しやすくなる原因
- 業務ロジックを重複させないための考え方とやり方
これらについて、
現場で役立つシステム設計の原則第3章 業務ロジックするをわかりやすく整理するを参考に、
10年間現場で設計やリファクタリングをしてきた自分の経験を交えながら
まとめました。
業務ロジックが重複すると何が悪いか？？
業務ロジックが重複していくと、
とある業務ロジックを変更したい場合、
重複させてしまっている全ての箇所を漏れなく修正して、
テストしなければなりません。
重複が2、3個で
最初に業務ロジックを作った人が保守開発を続けている状況なら、
なんとかそれでも耐えられるかもしれませんが、
僕の経験上、
業務ロジックをコピペして重複させるのが放置されている現場では、
重複は数十くらい平気で行っていることが多いです。
さらに、最悪なのは
そのような状況で保守開発をするモチベーションは下がり、
最初に業務ロジックを作った人だけでなく、
優秀なプログラマーはどんどん流出してしまい、
状況はますます悪化していきます。
自分自身10年近くプログラマーとしていろんな現場を経験してきましたが、
保守開発の中で何気なくコピペで至る所に業務ロジック量産するということは、
こういう大惨事に繋がっていった現場やそれに近い状況になっている
現場をいくつも体験してきました。
(いつも僕は残される側だったので本当に辛かった・・・)
業務ロジックが重複しやすくする原因
ここからは自分が現場で見てきた
業務ロジックが重複しやすくする原因をいくつか紹介していきます。
開発のゴールがリリース
まずは開発のゴールをリリースに置いているか、
それともその先の保守開発に置いているか。
という点が分岐点になると僕は考えます。
リリースして終わりのスタンスで開発した場合、
業務ロジックを重複させたとしても、
とりあえず動いてリリースできたらいい。
という意識になってしまい、
業務ロジックの重複含む保守性は一切考えなくなります。
僕も、そうやって外部で作られたプロダクトを
内製化するという現場にいたことがあり、
非常に苦労しました。
その場しのぎの保守開発
長年の保守開発をその場しのぎで行ってきており、
既存の動いているコードは基本的に触らない。
同じ業務ロジックだったとしても、
完全に流用できる場合以外は少しでも異なれば、
ロジックを複製してとにかく既存に影響を出さない。
といったスタンスでの保守開発の現場でも
業務ロジックは重複していきます。
(実際に僕もそのような現場で仕様変更時に
重複したロジックを漏れなく修正するのに苦労しました)
フラグや分岐で既存に影響を与えないように
サクッと仕様変更をしていった結果、
業務ロジックが複雑になりすぎて変更が危険になり、
テストコードもなく、
既存を触らない方針なのでそのまま使えない場合は、
既存の業務ロジックを修正使うことを恐れ、
結局同じような別の業務ロジックが量産されます。
業務ロジックを重複させないための考え方とやり方
ここまで、
業務ロジックを重複させてしまうとどのような悪影響があるのか？？
業務ロジックを重複させてしまう原因は何か？？
を見てきました。
ここからは、
業務ロジックを重複させずどのように整理して1箇所にまとめるか
について基本となる考え方をみていきます。
まず、
「クラスをデータの入れ物ではなく業務ロジックの置き場として捉える」
という考え方が基本になってきます。
クラスをただのデータの入れ物だと考え、
使う側が外からセットアップしてクラスの値を直接みて判断、加工、計算などなど
やり始めるとロジックが至る所に散らばり、
結果同じロジックが至る所にできがちです。
一方で
クラスを関連の強いデータとロジックの置き場所と考ると、
ロジックが散らばりにくく１箇所に集まり仕様変更が楽で安全になります。
この辺りの内容を具体的なサンプルコードを作りながらまとめた記事があるので、
そちらもご覧ください。
現場で役立つシステム設計の原則第４章を読んで｜気付きや今後参考にしたいことなどをまとめてみました
リライト中・・・
