共通コンポーネントは、1 つのグループによって作成および維持され、多くのグループによって使用されるライブラリまたはその他のコードです。
私たちが抱えているいくつかの問題は次のとおりです。
あなたの組織は共通のコンポーネントをどのように扱っていますか?
私が持っているアイデア：
ここにあるのは、技術的な問題ではなく、人的要因の問題である可能性があります。実際、それは主に学習の問題である可能性があります（ここで発明されていない典型的な症候群と相まって）。
大企業で働いてきた私は、新しい人が利用できるすべてのリソース（つまり、共有コードライブラリ）を理解するのは難しいこと、ましてやそれらを適切に使用する方法と時期を理解するのは難しいことを認識しています。
あなたが新入社員を雇うとき、彼/彼女はあなたの共通コンポーネントライブラリで正式なトレーニングを受けていますか？
次に、人々が何に対して報われるかという問題があります。レビュー時に、マネージャーは、共通のコンポーネントを使用し、それらを改善し、改善をライブラリに提出したことに対して人々に報酬を与えますか？または、マネージャーは単に自分のプロジェクトを気にしますか。
共通の図書館を維持しているあなたのグループに関して、彼らは改善を提案したり提出したりするのに時間をかける人々にどのような形や再認識を与えますか？彼らは会社のニュースレターに書かれていますか？現金ボーナスを取得しますか？弾丸ボードに彼らの写真を載せますか？
人々が認識や報酬を受け取らない会社のために何かをする可能性は非常に低いことを忘れないでください。
あるプロジェクトに特定の機能を作成した場合、それを別のプロジェクトからWebサービスを介して使用できるように、よりサービスベースのシステムに移行しようとしています。このように、コードのインスタンスは1つだけです。
当然、これは一部のタイプのコンポーネント（例：最近PDF作成サービスを作成した）では他のタイプ（おそらく文字列操作ユーティリティではやり過ぎ）よりもうまく機能します。
サードパーティのライブラリと同じように扱います。私は他のチームに情報源を見せることさえしませんでした-そうすることは多くの時間を浪費する批判と裏切りにつながる可能性があります。
組織の規模はどれくらいですか？私は、このようなものが小さな組織（合計で数十人のプログラマー）で非常にうまく処理されるのを見てきました。そこでは、1人または2人の個人が各コンポーネントの所有権を持ち、機能の要求に応答します。
誰かのオフィスに行進して（または郵送して）、必要なものを説明して、次のいずれかを入手する方が簡単です。
回避策の作成、フォークの開始、または同等の新しいコンポーネントの作成を開始するだけではありません。あなたのプログラマーが賢いなら、彼らは彼らが最も簡単だと思うことをするでしょう。秘訣は、これが正しいことを確認することです。
リンクリストのような本当に単純なものを除けば、車輪の再発明はあまり行われていませんでした。ごくまれに、特定の製品用のプライベートフォークがあり、最も一般的には、物事を切り刻んでコードサイズを縮小するためのものでした。しかし、それを行う通常の方法は、元のコンポーネントを変更して、より多くのビルドオプションを持たせることでした。
私が見た唯一の成功したコンポーネントは、コンパイルされたバージョン (*.dll) で再配布されています。ユーザーはバグを報告し、所有しているチームに直接機能を要求し、それらを自分で実装します。変更される可能性が最も高いものに対して独自のプラグインを作成するための API があるため、多くの場合、機能を拡張できます。
常にトレードオフがあります
あなたのケースで何をするのが最善かはわかりませんが、一般的にはコアロジックを自分で実装し、コンポーネントを構成可能/拡張可能にして、人々が常にコアを変更する必要がないようにして、適切なサポートを提供してください。なんらかの理由で、開発者の中には、愚かであっても車輪を再発明する傾向がある人もいるので、あまり心配する必要はありません。
良い方法は、定期的なコード レビューを開始することです。これらの間に車輪の再発明が見つかった場合は、開発者を教育して共通コンポーネントを使用するようにするか、開発者がそれを再発明する必要性を感じた理由を説明し、彼らの推論を元のコードに結び付けることができます。このようにして、全員の要件が作成され、コンポーネントが全員のために改善されます。