複数の小さなプライベートリポジトリ上に単一のWebアプリケーションを配置することは、どの程度実行可能ですか？

私たちはウェブアプリに取り組んでいる低予算のチームです。いくつかの複雑さのため、1月以降はリモートで作業する必要があります。いくつかのコンサルティングとグーグルの後、いくつかの小さなリポジトリがより安価なオプションであると結論付けました。私たちは考えています：

• バックエンドとサービス

• ミドルウェア

• フロントエンド

このようにして、関連するチームに分離し、それぞれがリポジトリでリモートで作業できます。私たちのアプリをいくつかの小さなプライベートリポジトリに置くことは、どの程度実行可能ですか？

さらに、この方法で作業する場合、どのような考慮事項を考慮する必要がありますか？

注：複数の小さなリポジトリに分割された単一の大きなプロジェクトについて質問しています。これは、1つまたは複数のリポジトリで複数のプロジェクトを要求しているため、このサイトで尋ねられた関連質問とは異なります。さらに、私たちはプロジェクトを分割することを選択しました。これは主に、私たちがそれに固執しない限り、単一の大きなプライベートリポジトリに投資するつもりがないためです。

「...私たちは、いくつかの小さなリポジトリがより安価なオプションであると結論付けました。」

それは素晴らしいことです。分割統治。努力を論理的な部分に分割し、各部分を異なるハードコアチームに与え、数か月間狂ったように作業し、すべてをまとめて、そして...

そして...

まあ、それはいまいましい悪夢になるでしょう。それは間違いなく安くはありません。なぜでしょうか？

ソフトウェアプロジェクトにおける最大の「コスト」はコミュニケーションです。コードを速く書くことでお金を節約することはできません。それはプログラマーが認めない秘密です。（Psst。誰にも言わないでください。コードを書く速さは本当に問題ではありません。）コードの記述に費やされる時間は、計画と話し合い、交渉、戦い、話し合い、会議と話し合いに費やされた時間に比べると、はるかに小さいです。妥協して実現することは、より良いことを叫んだり、望んだり、解決したりすることを妥協して約束したり（言葉ではありません）、ループバックしたり、pingしたり、話したり、眠ることができなかったりするべきではありません。

したがって、作業を個別のチャンクに分割し、各チャンクを別々のチームに渡します。何をしたの？コミュニケーションの負担を追加しました。運がよけれ場合とチームは完璧です。1つの大きなリポジトリといくつかの小さなリポジトリの間にコストの違いはまったくありません。運が悪い場合（少数の場合）、別のチームに分割すると実際にはさらにコストがかかります。全員が同じコードベースにいるときに、互いにつま先を踏んで同期を保つのは十分に困難です。ここで、3つの異なるチームが要件がわずかに異なる何かを意味すると（他のチームの要素を壊していないので迅速に修正する方法はありません）、文化がわずかに異なり、最終的には物事がうまくいかなくても責任を負わないように非常に動機付けられているので、彼らは他のチームをバスの下に投げ入れようとする以上のものです。

私は知っています、あなたのチームはそれよりも優れています。しかし、彼らは本当にですか？あなたはそれにお金を賭けるのに十分自信がありますか？

どちらのアプローチ（大きなリポジトリ/多くの小さなリポジトリ）でも、最初はがらくたの束をモックアウトする必要があります。あなたは盲目で働き始めます。できるだけ早く、利用可能になり次第、他のレイヤーからの具体的な実装の使用を開始する必要があります。これにより、問題と誤解を早期に特定できます。もちろん、少しでこぼこになりますが、不安定な仕様とハンドシェイクを使用して独自に開発し、後で物事を一緒に折りたたむよりは、かなりでこぼこです。

私のポイントは、大きなレポ/小さなレポは問題ではないということです。重要なのは、チームをどのように構築するかです。理想的には、チームはより大きなまとまりのあるアイデンティティの中に小さな独立したアイデンティティを持っています。生物の臓器や粘液粘菌のようなもの。コードをどのように構成するかに関係なく、全員がお互いにぶつかる機会を与えてください。コミュニケーションを容易にします。一緒に間違いを犯し、それらを早期かつ頻繁に修正します。

私の目には、リポジトリの分割は、目標と使用しているツールに大きく依存しています。

たとえば、フロントエンドが（たとえばAJAXによって）消費するパブリック（またはプライベート）APIなしでRuby on Rails Webアプリを作成している場合、実際にリポジトリを分割する方法がわかりませんあなたのチームに大きな頭痛の種を引き起こしています。その場合、Railsフレームワークはモノリシックタイプのアーキテクチャで最もよく機能します。

ただし、RailsまたはNode.jsでAPIを記述する予定で、フロントエンドをEmber.jsなどで記述したい場合は、リポジトリを分割するのが妥当です。Webアプリのデータが他のクライアント（Android / iOSアプリなど）によって将来共有される場合も同様です。複数のクライアントで使用されるAPIを作成する場合は、リポジトリを分割してください。一部では、分割が別のアプリケーションへのAPIが完全に悪い考え、私は心をこめて同意することを1（であり、それがためにそう思えると主張良い理由！

すでに説明したようにWebアプリの分解を計画している場合は、リポジトリを分割することが唯一の論理的なオプションです。ただし、他の人のコードを閲覧するのは難しくなるため、優れたコミュニケーションを確保する必要がありますが、さらに重要なのはドキュメントです。たとえば、APIを文書化しないと、APIチームがアーキテクチャを文書化しなかったため、他の2つのチームはすぐに腹を立てることになり、誰もが質問を続けるため、APIチームは腹を立てることになります。これは、リモートチームにはさらに当てはまります。

したがって、それはすべて、そもそもアプリをどのように構築したいかにかかっています。モノリシックWebアプリを構築している（そして、それがWebアプリのままであることがわかっている、または確信している）場合は、リポジトリを1つ作成します。マイクロサービスや、複数のクライアントによって使用されるREST APIなどの作成を計画している場合（または将来的にこれを計画している場合）、リポジトリを分割します。