私が働いたほとんどすべての会社で、多くのプロジェクトで一般的に共有されている共通のライブラリがあることに気づきました。多くの場合、これは単一のcompanyx-commonsプロジェクトであり、最終的には次のような一般的なプログラムのゴミ捨て場になります。
これらのいくつかはよく考えられており、Apache commons-lang、commons-ioなどにいくつかの重複する機能があります。
共通ライブラリにはどのようなものがありますか。さらに重要なことは、共通ライブラリをどのように構成して、他のプロジェクト間で簡単に改善および組み込むことができるようにするかです。
私の経験では、一般的なライブラリの成功の最大の要因はユーザーの賛同です。この場合のユーザーは他の開発者です。そしてあなたの職場/チームの文化は大きな要因になります。
アプリケーション層ごとに別々のライブラリ（.Netを使用している場合はプロジェクト/アセンブリ）が不可欠です（たとえば、UIとデータアクセスコードを組み合わせる意味がないことは明らかです）。
物事をできるだけシンプルに保ちます。共通のライブラリに入れないことは、少なくともあなたがすることと同じくらい重要であることがよくあります。ライブラリのユーザーは考える必要がないので、使用法は非常に簡単である必要があります。
私たちが固執した黄金律は、個々の機能を単一のタスクに集中させることでした。1つのことを実行し、それをうまく（または非常にうまく）実行します。あらゆる可能性を考慮に入れようとするものを提供しようとしないでください。再利用可能であると思うほど、使用される可能性は低くなります。Code Complete（本）には、一般的なライブラリに関する優れたコンテンツがいくつかあります。
ライブラリを設定/改善するための良いアプローチは、定期的なコードレビューと回顧を行うことです。すでに思いついた良い候補を見つけて、将来のプロジェクトのためにそれらをライブラリにリファクタリングすることを検討してください。良い候補とは、複数の開発者が複数のプロジェクトでやらなければならなかったことです（たとえば）。
ライブラリのある種の単純で明確なガバナンスを設定します-特定のライブラリを「所有」し、それが全体的な品質であることを保証できる人（上級開発者やチームリーダーなど）。
私はこれまで、私たちがオフィスで使用する一般的なライブラリのほとんどを作成しました。
これらのクラスを使用すると、製品全体でまったく同じインターフェイスを使用するため、お互いのコードでの作業が容易になり、それらがどのように機能するかを正確に知ることができます。
組織に関する限り、すべてのDLLは、ソースコードとともに、私たち全員がアクセスできるオフィスの共有開発ドライブに保存されます。（私たちはかなり小さなお店です）
ライブラリを関数ごとに分割します。
Commmon.Ui.dllには、UI要素の基本クラスがあります。Common.Data.Dllは、エンタープライズライブラリのデータアクセスクラスの一種のラッパーです。Common.Businessは、それらの1つに当てはまらない他の一般的なクラスの捨て場です。
必要に応じて、他の特殊なdllを作成します。