業務システムの開発ってのは、中々面倒くさい。
私が手がける程度の小粒なシステムであっても、既存業務プロセスのヒアリングから始まり、システム導入後のプロセスを書いて、UIなどをある程度ペーパーモックで試したりしながらゴリゴリ書いていく。
ERPをノンカスタムでと言うけれど、ERPの中身がIFによる分岐だらけになったりしてると、それはそれでどうなの?
まぁうまくOOPの仕組みを使えばif自体は減らせるけど、未使用コードがコードベース全体に占める割合が大きくなっていくという意味では根本的には変わらない。
標準プロセスを導入していきたいという気持ちは大抵の企業にある
特に小さい企業ほど、自社が行っているプロセスが効率的だとは思っていない。
本業に直接関わる部分についてはそうでもないが、バックオフィスや業務間の全体設計については洗練されていないことを自覚しているので、ベストプラクティスを導入していきたい、という気持ちだけはある。気持ちだけ。
プラグイン機構を用意してフックポイントを作りまくるよりは、直接書き換えていける方がシンプルな場合もある
wordpressのようなプラグイン機構はユーザにとってはコアアップデートをしやすく、本体保守がしやすいという大きなメリットがある。
ただ他人が保守開発しているプラグインを組み合わせるだけならいいのだが、自分で開発するとなると直接コアに手を入れたほうが楽な場合も多い。
特にいい感じのフックポイントがなければそうせざるを得ません。
また、コアの開発上で言えば、フックポイントをたくさん作るのはそれ自体結構面倒です。
そのフックポイントで何を実行されるかわからない以上、完全な動作保証はできないにしてもパラメータの受け渡しや、プラグイン側での処理後の復帰など考慮すべき事項が増えるからです。
メリットは見通しの良さ
ベアボーンなフレームワークに必要な業務を追記していくのは、実際問題ラクです。
それなりにちゃんとしたアーキテクチャがあるシステムであれば追記していくのは
デメリットはカスタム後の最新バージョンへの追従性の低さ
コアを直カスタムしてしまうとコアアップデートが地獄なるのは当然。
なのでなるべくレイヤーを切ってコアアップデートを行えるように配慮しておきたい。
コンポーネント指向なフレームワークにしておけばある程度行けるのでは
ていうかgemが充実しているrailsが一番理想に近い気がする・・。もっとビジネス的なロジックをまとめたgemがいろいろあればいいのであって・・。
みたいなことをコンビニワインで酔っぱらいながら考えていたのでメモ書き。
コメント