複数のプロジェクトで同じコードフラグメントを維持する方法
私は複数のAndroid=プロジェクトに取り組んでいるインディーデベロッパーです。異なるプロジェクトで同じ機能を維持するのに問題があります。たとえば、3つのアプリが同じ2つのクラスを使用しています。これらは異なるプロジェクトであるためです。 、これらのクラスを変更する必要がある場合、3回変更する必要があります。この種の一般的な問題に対する簡単な解決策はありますか？
GitやMercurialなどのdvcsを使用して、プロジェクトをバージョン管理下に置きます。共有コードをgitのサブモジュールに配置します。それを必要とするプロジェクトでサブモジュールを使用します。サブモジュールを更新すると、単一のコマンドで他のプロジェクトへの変更をプルできます。
他の誰もまだ両刃の剣に言及していないので、2セントを追加します。複数のプロジェクトがあり、それらがすべて再利用可能なコードを共有している場合、適切なプログラミングプラクティス/原則（DRYなど）に従って、コードを1つのグローバルな場所に配置し、すべての人が共有できるようにコードを構造化する必要があります。変更を加えずにプロジェクト。言い換えれば、インターフェースを一般的であり、誰にでも合うように十分に一般的であるように定義します。
これを行うにはいくつかのオプションがあります：1）他のユーザーが依存する基本プロジェクトを作成します。このプロジェクトは、他のプロジェクトが使用するバイナリディストリビューションを作成できます。 2）組織内のオープンソースモデルをプルします。共通コードを独自のコードブランチにして、他のプロジェクトに、OSSからオンラインでソースコードを取得するのと同じ方法でコードを取得させます。
さて、ここに剣が入ってきます...
他のプロジェクトや人々が依存する共通の場所にコードを配置すると、かなりコストがかかる可能性があります。コードの一部があり、それに依存する他の4つのプロジェクトがあるとします。プロジェクトAを使用している顧客の1人がバグを見つけ、修正する必要があります。あなたは修正を急いで行い、その顧客は満足しています。しかし、他の3つのプロジェクトが依存するいくつかのコードを変更しただけです。これらすべてを再テストして、エッジ条件が導入されていないことを確認しましたか？
共通コードもより慎重に作成する必要があり、モジュールインターフェイスは1つではなく4つのクライアントに対応する必要があり、それぞれがこのコードをわずかな違いで使用する可能性があるため、より適切に設計する必要があります。
プロジェクトのリリースサイクルが異なる場合は、共通コードの管理についてさらに注意する必要があります。プロジェクトCの最終的なイメージを切り取ってから3日後であれば、プロジェクトBに新しい機能が必要になるため、共通コードを単純に変更することはできません。
共通ライブラリが適切なソリューションではないと言っているのではありません。私はDRYの強力なサポーターであり、以前に一般的なコードを作成してサポートしたことがあり、それを続けています。単にコードを一般的にすることはそれ自身の費用がかかるということをそこに出したかっただけです。 。
あなたがこのコードを再利用する唯一の人であれば、これはそれほど悪くはありません。エンジニアのチームがいて、彼らが共通のコードを使い始めた場合、費用はさらに増えます。他の人が関わっている場合は、コードを共通ライブラリに配置すると、「完全」だと思うまでに3倍の時間がかかることを期待してください。 a）ライブラリをより堅牢にして、あらゆる種類のエッジ条件と無効な使用から保護します。b）ドキュメントを提供して、他のユーザーがライブラリを使用できるようにします。c）他の人がライブラリを使用するときにデバッグするのを手助けします。予期していなかったし、ドキュメントは彼らの特定のユースケースをカバーしていませんでした。
私が提供できるいくつかの提案：
- 自動化された単体テストの対象となる一般的なコードがあると、長い道のりが変わり、変更を加えたときに、他のプロジェクトを壊すだけではなかったことに少し気がつくでしょう。
- 非常に安定した機能を一般的なコードに配置するだけです。昨年タイマー管理を行うクラスを書いていて、9か月間それを変更しておらず、タイマーを必要とする他の3つのプロジェクトがある場合は、それが良い候補であることを確認してください。しかし、先週何かを書いただけなら、まあ...それほど多くのオプションはありません（そして、おそらく次の人よりもコードのコピー/貼り付けが嫌いです）が、私はそれを一般的にすることを2度考えます。
- コードの一部が取るに足らないものであるにもかかわらず、いくつかの場所で使用したことがある場合は、弾丸をかじるのが良いかもしれません。DRYはそのままにして、複数のコピーを公開します。
- 時々、共通のコードを共通の場所に置いて誰もがそれを参照できるようにするだけでは意味がない場合があります。ただし、バージョン、リリース日、その他すべてについて、一般的なコードをリリース可能な独自のコードとして扱う必要があります。このようにして、プロジェクトCは「共通ライブラリv1.3を使用します」と言うことができ、プロジェクトDに新しい機能が必要な場合は、v1.3をそのままにしておくと、リリースv1.4になり、プロジェクトCは影響を受けません。共通のコードを共通の場所にチェックインするだけでなく、独自の製品として扱う方がはるかに高価であることを覚えておいてください。
これは理想的なソリューションであり、機能するまでには多少の労力が必要です。
DRYの原則では、信頼できる真実の情報源は1つだけである必要があります。これにより、すべてのプログラムロジックに単一のsourceリポジトリを使用し、重複はありません。ファイルドキュメントの共有と再利用を促進するために編成されています。
分散マルチチーム環境でのコミュニケーションの実用的な要件は、プロジェクトまたはコラボレーションごとに1つずつ、複数の独立したリポジトリが必要であることを示唆しています。
私は必然的に提出することによってこの問題に取り組みます。両方のアプローチを同時に行う必要があり、スクリプトと自動化を使用して、アプローチが矛盾しているという事実をスムーズにします。
:-)
1つの統合リポジトリが、信頼できる単一のソースになります。各プロジェクトのビルドプロセスでは、そのプロジェクトで使用されるすべてのファイル（およびそれらのファイルのみ）が中間の場所にコピーされ、その中間の場所からビルドされます。 （Unisonまたは同様のツールを使用して、ファイル全体ではなくデルタを移動できます）。
これらの中間の場所は、セカンダリ、派生、またはダウンストリームリポジトリのセットのローカル作業コピーとして使用できます。権限のあるリポジトリのコミット後のフックスクリプトは、すべての中間の場所を更新し、それぞれについて変更されているかどうかを確認し、変更が検出された場合は対応するセカンダリリポジトリに同じコミットを行います。
このようにして、複数のセカンダリリポジトリが単一の信頼できるソースリポジトリと同期され、ビルドプロセスにより、セカンダリリポジトリに、ビルドの成功に必要なすべての（共有される可能性のある）ドキュメントおよびその他のファイルが確実に含まれます。最後に、そして最も重要なこととして、開発とビルドのプロセスにより、ファイルが1か所と1か所でのみ編集され、すべてのコピーが一貫して最新の状態に保たれます。