行動すれば次の現実

ほどよくモダンなシステム開発を目指しています。メインテーマは生産性、Ruby、Javascriptです。

パッケージシステムのカスタマイズ対応をどう管理するか

弊社ではクラウド型のWebアプリケーションパッケージシステムを開発している。 基本的にはパッケージ機能のみを顧客に使用してもらいたいのだが、当然のようにカスタマイズ要望が生まれる。

カスタマイズ要望は、往々にして現場よりの要件で顧客と密結合である。 そのため、パッケージとして素直に取り入れることのできないケースが多々ある。

そのような場合にどのようなアプローチがあるのか以下に記す。

顧客ごとにブランチを分ける

パッケージとしての本ブランチ(master)と顧客ごとにブランチを作成する方法。

メリット:他顧客に影響なくカスタマイズしほうだい。
デメリット: ブランチの管理が大変。masterへのマージ、各ブランチへのマージやらでどんどん脆い作りになっていく傾向。

マイクロサービス化する

カスタマイズ機能をマイクロサービス化する。パッケージとはコードベースが別になり、サーバーなども別に用意する。

メリット:パッケージのコードベースが肥大化せずにすむ。影響範囲が絞られるのでメンテナンス性が高い。
デメリット:マイクロサービスとして切り出す上で、インフラまで影響が出る。セッション管理をどうするかなど、アーキテクチャをしっかり構築しておく必要あり。

フラグで頑張る

機能を使用するかどうかのフラグで処理を分岐させる。

メリット:一番手っ取り早い、コードベースが小規模段階ではスピード開発可能。
デメリット:コードベースが肥大化し、分岐処理によって複雑化する。がんじがらめになるのでデグレしやすい。

我々の結論

「フラグで頑張る」

自PJの場合、PMF前のプロダクトなので、スピード重視したいため。
メンテナンス性やデグレ懸念については単体テストである程度担保できると判断。
理想は「マイクロサービス化する」だが、環境を整える上でのリソース確保が課題であるため見送り。