関連するAnsi-Cコード ベースを使用して、プロジェクトに取り組んでいます。(これを「メイン」コードベースと呼びましょう)。
私は今、典型的な問題 (後述) に直面しています。オブジェクト指向言語が手元にあれば、非常に簡単に解決できると思います。
問題は次のとおりです。複数のコードベースを開始する必要があります。つまり、並列コードベースのサポートを開始する必要があります (将来的にはさらに増える可能性があります)。すべての新しい (つまり、並列の) コードベースの初期コードベースは、最初は古い (つまり「メイン」) コードベースと同じになります。
「C」言語について話しているので、コードに「#ifdef」ステートメントを追加し、それらの「ifdef」ブロック内にブランチ固有のコードを記述することをこれまで考えてきました。
問題が明確になったことを願って (十分に!)、この問題を Ansi C でエレガントに処理するのに役立つ巧妙なパターンについての考えを聞きたいと思います。
乾杯
異なるコード ベース間で何が変わるのでしょうか?
プラットフォームが異なるだけの場合は、プラットフォームの依存関係を慎重に分離し、コア コードの多くをすべてのプラットフォームで可能な限り同じに保ち、プラットフォーム固有のものを別のファイルに入れます。
プログラムの機能を根本的に変更する場合は、変更されていないコードの共通のコアを保持しながら、プログラム間の違いを許容する方法を検討する必要があります。
どちらの場合も、何よりもまず、何が変更されるかを理解し、できるだけ変更が少なくなるようにコードを設定することが重要であることに注意してください。多くの場合、バリエーションを処理する最善の方法 (必然的にバリエーションが存在します。そうでなければ、2 つ以上のバージョンを使用しても意味がありません) は、さまざまなバリエーションを別々のファイルに入れ、正しいファイルをコンパイルしてリンクすることです。ただし、バリエーション (またはバリエーションの一部) を 1 つのファイルにまとめて、#ifdefスタイル条件付きコンパイルを使用する方がよい場合もあります。
もう 1 つの重要なポイントは、すべてを同じバージョン管理システムの下に維持することです。これは、可能な限り長く、またはそれより 10 年または 2 年長くなります。
私が見た中で最大の災害は、異なるバージョンが共通のコード ベースを使用しなくなったときに発生しました。今、私たちは 2 つのコード ベースを再統合する必要があります。10 年間の別々の開発が大きな障害になっています。過去 15 年間の統合開発には浮き沈みがありましたが、現在直面している問題に比べれば何もありません。うーん！
ベースのソリューションの代替または補完として#ifdef、SCM でさまざまなブランチを維持できます。
違いを抽象化できます (または、少なくとも試すことができます)。コードベース固有のコードはすべて、プログラム ロジックとは別のファイルに配置します。その後、条件付きコンパイル (ifdef-include) を使用でき、新しいコードベースごとにコードベース固有のファイルを置き換えるだけでよく、アプリケーション ロジック全体は変更されません。