Common Libraries at a Company

Question

I've noticed in pretty much every company I've worked that they have a common library that is generally shared across a number of projects. More often than not this has been a single companyx-commons project that ends up as a dumping ground for common programs including:

• Command Line Parsers
• File Utilities
• Framework Helpers
• etc...

Some of these are well thought out and some duplicate functionality found in Apache commons-lang, commons-io etc..

What are the things you have in your common library and more importantly how do you structure the common libraries to make them easy to improve and incorporate across other projects?

Answer 1

I have so far written most of the common libraries we use at our office.

• We have certain button classes that are just slightly more useful to us than the standard buttons
• A database management class that does some internal caching and can connect to ODBC, OLEDB, SQL, and Access databases without even the flip of a parameter
• Some grid and list controls that are multi threaded so we can add large amounts of data to them without the program slowing and without having to write all the multithreading code every time there is a performance issue with a list box/combo box.

These classes make it easier for all of us to work on each other's code and know how exactly they work since we all use the exact same interfaces throughout our products.

As far as organization goes, all of the DLL's are stored along with their source code on a shared development drive in the office that we all have access to. (We're a pretty small shop)

Answer 2

We split our libraries by function.

Commmon.Ui.dll has base classes for ui elements. Common.Data.Dll is sort of a wrapper around Enterprise library Data access classes. Common.Business is a dumping ground for other common classes that don't fit into one of those.

We create other specialized dlls as needs arise.

Answer 3

In my experience, the single biggest factor in the success of a common library is user buy-in; users in this case being other developers; and culture of your workplace/team(s) will be a big factor.

Separate libraries (projects/assemblies if you're in .Net) for different application tiers is essential (e.g: there's obviously no point putting UI and data access code together).

Keep things as simple as possible; what you don't put in a common library is often at least as important as what you do. Users of the library won't want to have to think, so usage needs to be super easy.

The golden rule we stuck to was keeping individual functions focused on a single task - do one thing and do it well (or very very well); don't try and provide something that tries to take every possibility into account, the more reusable you think you're making it - the less likely it is to be used. Code Complete (the book) has some excellent content on common libraries.

A good approach to setting/improving a library up is to do regular code reviews and retrospectives; find good candidates that you've already come up with and consider re-factoring them into a library for future projects; a good candidate will be something that more than one developer has had to do on more that one project (for example).

Set-up some sort of simple and clear governance of the libraries - someone who can 'own' a specific library and ensure it's overal quality (such as a senior dev or team lead).