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