hitode909の日記

趣味はマリンスポーツですの日記です

分けるかくっつけるか

ふだん,主に1つのアプリケーションをずっと触っていて,常に手を入れているので,リリースフローがどんどん便利になったりしている.
モノリシックな大きなアプリケーションは嫌われがちで,役割ごとに,たとえば管理画面と表側の画面,とか,いくつかのサブシステムに分割することも考えられるけど,分割すると,分割した全てをこの便利な水準にするのは大変だな〜と思った.
2つに分けると,すくなくとも2つ用意する必要がある.もしくは,抽象化した何かを作って共通で使うことも考えられるけど,最初から抽象的な物を考えて作るのは難しい.

くっつける

  • コードベースが大きくなる
  • テストの実行や起動などがだんだん遅くなりがち
  • デプロイは一度にまとめてやることになる
  • 障害時に全部まとめて落ちる
  • ライブラリやサーバーのアップデートは1回だけ
  • 重厚なリリースフローや開発時の便利グッズを作りやすい
  • おかしくなっても捨てて作り直すことはなく,修理する
  • 自作のライブラリはアプリケーションに入れてしまってもよい

分ける

  • それぞれのコードベースは小さくなる
  • テストや起動などは小さいので速いはず
  • 部分ごとにデプロイできる
  • 障害時に特定の画面だけ落ちる
  • 部品ごとにライブラリやサーバーをアップデートして回ることになる
  • リリースフローや開発時の便利グッズはそれぞれ作っていくことになる
  • おかしくなったら捨てて作り直せる
  • 自作のライブラリはコピペして入れるか,インストールして使えるようにする必要がある


つまり,意図的に,普段なら分けるところをくっつけてしまう,という作戦も考えられるのではないか.極論を言うと,アプリケーションはチームに1個だけで,機能的にはまったく関係ないものもそこに含める,ということも考えられそう.
別のチームがメンテナンスすることになったら,その部分は別のチームのアプリケーションに実装しなおす.たぶんDBへのアクセス方法とか,使っているフレームワークなども違うので,そのまま持って行っても動きはしない.前者で同じフレームワークを使っていたとしても,その中で使っているライブラリには差があるかもしれない.
戦略的に統一すると,社内便利ライブラリが充実したり,同じ手法で管理できたりして便利かもしれない.たとえば,Railsと組み合わせて使える,ABテストを実施するためのフレームワークがあるとして,社内のプロダクトは基本的にRailsを使っているので,どのアプリケーションでもABテストを簡単に実施できる,とか.