私は現在、多くの共通点を持ちながら明確に異なる 2 つのソーシャル ネットワーキング サイトに取り組んでいます。両方 (UI を含む) に同じコードをたくさん書いていることに気づき、コードの重複を制限するベスト プラクティスがあるかどうか疑問に思っていました。
主な問題の 1 つは、これらのプロジェクトが互いに非常に独立しており、近いうちに類似点よりも相違点の方が多くなる可能性が高いことです。また、最初の作業が完了すると、他のプログラマーに引き継がれる可能性があるため、コード ライブラリを共有することが大きな問題になる可能性があります。
同様の状況に対処しなければならなかった可能性のある人々からの提案はありますか?
PS: 両方のプロジェクトの開発者は私だけで、しばらくはそのままの状態が続くようです。
これを処理する一般的な方法は、定義されたインターフェイスとデフォルトの実装を使用して、共有機能をフレームワークまたはライブラリに抽象化することです。たとえば、プラグイン アーキテクチャをサポートすることを選択した場合、そのプラグイン アーキテクチャはおそらくすべてのプロジェクトで共有できるものです。ほとんどの場合、共有したいものはかなり基本的な機能か、簡単にカスタマイズできる比較的抽象的な機能です。前者は認識しやすく、一般的なライブラリに分解できます。後者は、小さな変更を加えて単純にコードを再実装する (コードではなくパターンを共有する) よりも手間がかかる場合があります。
注意したいことの 1 つは、事前に共有アーキテクチャーを考え出すのではなく、実際の再利用によって共通ライブラリーの設計を推進することです。フレームワークの設計に夢中になり、それを共有して使用するために抽象化するのは非常に魅力的です。残念なことに、共有使用が予想とはまったく異なる方向に発展したり、発展したりすることはなく、最終的にフレームワークの大部分を書き直したり破棄したり、さらに悪いことに、未使用のコードを保持して維持したりすることに気付くことがよくあります。YAGNI (あなたはそれを必要としません) をガイドにして、実際に必要になるまで共通ライブラリへのリファクタリングを遅らせてください。
ここには (少なくとも) いくつかの異なるアプローチがあり、確かに両方を使用できます。まず、いくつかの一般的なコードを別のプロジェクトに削除し、そのコードを静的に呼び出すことができます。これは非常に簡単で、メイン プロジェクトのクラスにおそらく属さない単純なヘルパー関数を使用してこのアプローチを取ることがあります。良い例は、数学ライブラリなどです。もう 1 つのアプローチは、共通の機能をクラスまたはインターフェイスに抽出してから継承および拡張することです。再利用するコードに応じて、これらのアプローチのいずれか (または両方) を使用できます。
思ったより簡単だと思います。簡単なコードで試して、同じソリューションで新しいプロジェクトをセットアップし、既存のコードからライブラリを参照して、それがどのようになるかを確認してください。複数のソリューションで共有プロジェクトを参照しない理由もありません。
開発が引き継がれれば、コード ライブラリを共有しても問題はありません。現時点では、2 つのサイトで管理している同じライブラリ (または複数のライブラリ) を参照できますが、プロジェクトを他のチームに分割する場合は、共有コードのコピーを各チームに渡すことができます。