c - Cでの一般的なコード再利用戦略は何ですか

Question

コンテキスト: C 言語、8 ビット マイクロプロセッサ

プロジェクト (製品) 間で再利用できるコンポーネントを特定しました。しかし、再利用可能なコンポーネントを処理するのに最適なインフラストラクチャを見つけることができません。

私が今まで見つけた2つの可能性：

• 静的ライブラリ
• Subversion の共有ファイル

Answer 1

共有ライブラリと共有ソースの両方を使用すると、プロジェクト間で共通のコードを共有できます。ライブラリは 2 つの選択肢のうち優れたものを提供するため、プラットフォームで利用可能な場合はそれらを使用する必要があります。これにより、ソース管理のコードがローカルで変更された場合に発生する可能性のある不注意な変更からライブラリのソースを保護できます。

ライブラリを介してコードを共有する場合の唯一の問題は、組み込みツール チェーンの一部のツール (インサーキット エミュレータに接続されたデバッガなど) によるライブラリ コードのソース レベルのデバッグがサポートされていないことです。この場合、ソースを介してコードを再利用することが許容される場合があります。可能であれば、ファイル システムのアクセス制御によってソースが変更されないように保護する必要があります。

Answer 2

再利用可能なコンポーネントがある場合は、ライブラリが最適です。

1. 保守が容易で、明確なインターフェースがあります。また、新しいプロジェクトに組み込むのも簡単です。
2. ライブラリコードに対して個々の単体テストを簡単に実行できます
3. コードをコピーして貼り付けるリスクが軽減されます。
4. プログラマは、ライブラリから使用する必要がある場合に、このコードが共有されることをより認識しています。

Answer 3

私の会社では、両方のアプローチを同時に使用しました。

• 2 つのチェックアウトを行います。1 つはプロジェクト用、もう 1 つはライブラリ用です。
• プロジェクトを ( 経由で) コンパイルする必要がある場合は、Makefile最初にライブラリをコンパイルします。
• ライブラリは、バイナリのみのライブラリであるかのようにリンクされます。
• プロジェクトをリリースするとき、他のプロジェクトがまだ新しいライブラリに対してコンパイルできるかどうかを確認します。
• プロジェクトをリリースするとき、プロジェクトとともにライブラリにタグを付けます。

このようにして、両方の長所を活用できます。

• 共通のコードが共有される: すべてのプロジェクトがバグ修正と改善の恩恵を受ける
• ソースコードは、理解とデバッグのために常に完全に利用可能です
• ソース コードの可用性により、ライブラリのメンテナンス (修正、改善、および実験) が促進されます。
• ライブラリの境界により、より API に似たアプローチが課せられます: より明確なインターフェイスとプロジェクトの埋め込み
• コンパイル時のフラグをライブラリに渡して、異なるフレーバーを構築できます
• ライブラリとプロジェクトの不一致の問題が発生することなく、必要に応じていつでも時間を遡ることができます
• お急ぎの場合は、ライブラリ チェックを延期できます。

このアプローチの唯一の欠点は、開発者が何をしているのかわからないことです。ライブラリを変更する場合、その変更がすべてのプロジェクトに影響することを知っておく必要があります。しかし、すでにバージョン管理システムを使用しており、ブランチを使用していてチーム内のコミュニケーションが良好であれば、まったく問題はないはずです。