複数のプロジェクトで同じコードフラグメントを維持する方法[終了]

私は複数のAndroidプロジェクトに取り組んでいるインディーデベロッパーです。異なるプロジェクトで同じ機能を維持することに問題があります。たとえば、私のアプリのうち3つは同じ2つのクラスを使用しています。これらは異なるプロジェクトであるため、これらのクラスを変更する必要がある場合は、3回変更する必要があります。この種の一般的な問題に対する簡単な解決策はありますか？

共有コードをライブラリに分離し、ライブラリをプロジェクトに含めます。

Android開発者として、おそらくJavaを使用しています。MavenやIvyなどの依存関係管理ツールの使用を検討してください。

副作用として、モジュール化を適用することで、懸念の分離を維持できます。コストは、分離するのにいくらかの作業が必要になる可能性があることです。利点は、将来の保守性が向上することです。また、必要に応じて、アプリケーションとは別に（商用またはオープンソースとして）ライブラリをリリースできます。

バージョン管理。 ギット。 Gitサブモジュール。

gitやmercurialなどのdvcsを使用して、プロジェクトをバージョン管理下に置きます。共有コードをgitのサブモジュールに配置します。それを必要とするプロジェクトでサブモジュールを使用します。サブモジュールを更新すると、単一のコマンドで他のプロジェクトへの変更をプルできます。

他の誰もまだ両刃の剣に言及していないので、2セントを追加します。複数のプロジェクトがあり、それらがすべて再利用可能なコードを共有している場合、適切なプログラミングプラクティス/原則（DRYなど）に従って、コードを1つのグローバルな場所に配置し、すべての人が共有できるようにコードを構造化する必要があります。変更を加えずにプロジェクト。言い換えると、インターフェースを一般的であり、誰にでも合うように十分に共通であるように定義します。

これを行うにはいくつかのオプションがあります：1）他のユーザーが依存する基本プロジェクトを作成します。このプロジェクトは、他のプロジェクトが使用するバイナリディストリビューションを作成できます。2）組織内でオープンソースモデルをプルします。共通コードを独自のコードブランチにして、他のプロジェクトに、OSSからオンラインでソースコードを取得するのと同じ方法でコードを取得させます。

さて、ここに剣が入ってきます...

他のプロジェクトや人々が依存する共通の場所にコードを配置すると、かなりコストがかかる可能性があります。コードの一部があり、それに依存する他の4つのプロジェクトがあるとします。プロジェクトAを使用している顧客の1人がバグを見つけ、修正する必要があります。あなたは修正を急ぎ、その顧客は満足しています。しかし、他の3つのプロジェクトが依存するいくつかのコードを変更しただけです。これらすべてを再テストして、エッジ条件が導入されていないことを確認しましたか？

共通のコードもより慎重に作成する必要があり、モジュールインターフェイスは1つではなく4つのクライアントに対応する必要があり、それぞれがこのコードをわずかな違いで使用する可能性があるため、モジュールインターフェイスはより適切に設計する必要があります。

プロジェクトのリリースサイクルが異なる場合は、共通コードの管理についてさらに注意する必要があります。プロジェクトCの最終的なイメージを切り取ってから3日後であれば、プロジェクトBに新しい機能が必要になるため、共通コードを単に変更することはできません。

共通ライブラリが適切なソリューションではないと言っているのではありません。私はDRYの強力なサポーターであり、以前から一般的なコードを作成してサポートしてきました。単にコードを一般化することはそれ自身の費用がかかるということをそこに出したかっただけです。

あなたがこのコードを再利用する唯一の人であれば、これはそれほど悪くはありません。エンジニアのチームがいて、彼らが共通のコードを使い始めた場合、費用はさらに増えます。他の人が関与している場合は、コードを共通ライブラリに配置すると、「完全」であると考えるポイントに到達するのにかかる時間の3倍の時間がかかることを期待してください。a）ライブラリをより堅牢にして、あらゆる種類のエッジ条件と無効な使用から保護します。b）ドキュメントを提供して、他のユーザーがライブラリを使用できるようにします。c）他の人がライブラリを使用するときにデバッグできるようにします。予期していなかったし、ドキュメントはそれらの特定のユースケースをカバーしていませんでした。

私が提供できるいくつかの提案：

1. 自動化された単体テストの対象となる一般的なコードがあると、長い道のりを歩むことができ、変更を加えたときに、他のプロジェクトを壊しただけではなかったことに少し心がけることができます。
2. 非常に安定した機能のみを一般的なコードに配置します。昨年タイマー管理を行うクラスを書いていて、9か月間それを変更しておらず、タイマーを必要とする他の3つのプロジェクトがある場合は、それが良い候補であることを確認してください。しかし、先週何かを書いた場合は、まあ...あなたはそれほど多くのオプションを持っていません（そして、おそらく次の人よりもコードのコピー/貼り付けが嫌いです）が、私はそれを一般的にすることを2度考えます。
3. コードの一部が些細なものであるにもかかわらず、いくつかの場所で使用したことがある場合は、弾丸をかじり、DRYをそのままにして、複数のコピーを公開することをお勧めします。
4. 時々、共通のコードを共通の場所に置いて誰もがそれを参照できるようにするだけでは意味がない場合があります。ただし、バージョン、リリース日、その他すべてについて、一般的なコードを独自のリリース可能なコードとして扱ってください。このようにして、プロジェクトCは「共通ライブラリv1.3を使用します」と言うことができ、プロジェクトDに新しい機能が必要な場合は、v1.3をそのままにしておき、リリースv1.4を使用すれば、プロジェクトCは影響を受けません。共通のコードを共通の場所にチェックインするだけでなく、独自の製品として扱う方がはるかに高価であることを覚えておいてください。

これは理想的なソリューションであり、機能するまでには多少の労力が必要です。

DRYの原則は、単一の信頼できる真実の根源があるべきであると述べています。これにより、すべてのプログラムロジックに単一のソースリポジトリを使用し、重複することはありません。ドキュメントの共有と再利用を促進するために編成されたファイル。

分散マルチチーム環境でのコミュニケーションの実用的な要件は、プロジェクトまたはコラボレーションごとに1つずつ、複数の独立したリポジトリが必要であることを示唆しています。

私は必然的に提出することでこの問題に取り組みます。両方のアプローチを同時に行う必要があり、スクリプトと自動化を使用して、アプローチが矛盾しているという事実をスムーズにします。

:-)

1つの統合リポジトリが、信頼できる単一のソースになります。各プロジェクトのビルドプロセスでは、そのプロジェクトで使用されるすべてのファイル（およびそれらのファイルのみ）が中間の場所にコピーされ、その中間の場所からビルドされます。（ファイル全体ではなく、Unisonまたは同様のツールを使用してデルタを移動できます）。

これらの中間の場所は、セカンダリ、派生、またはダウンストリームリポジトリのセットのローカル作業コピーとして使用できます。権限のあるリポジトリのコミット後のフックスクリプトは、すべての中間の場所を更新し、それぞれについて変更されているかどうかを確認し、変更が検出された場合は対応するセカンダリリポジトリに同じコミットを行います。

このようにして、複数のセカンダリリポジトリが単一の信頼できるソースリポジトリと同期され、ビルドプロセスにより、ビルドが成功するために必要なすべての（共有される可能性がある）ドキュメントおよびその他のファイルがセカンダリリポジトリに確実に含まれます。最後に、そして最も重要なこととして、開発およびビルドプロセスでは、ファイルが1か所と1か所のみで編集され、すべてのコピーが一貫して最新に保たれます。