How to Maintain a Common Library Used by Different Clients

librariesteam

I am part of a software deveopment team. Originally there were just 2 of us, and two applications. To ease our job we create a set of libraries, handling stuff like GUI, database access, calculation, business rules etc, so that we can reuse them in our applications without implementing them twice.

Now the team grew, 6 people and ~5 applications (and growing). The applications use the same library, which are great because we don't have to develop and maintain the same thing more than once. I and the other initial guy developed and are mostly responsible for the library, but other people have access to the code and occasionally update it to fix bugs and add improvements.

But soon we notice that the more we grow and the more people can modify the code, there is a risk that "improvements"/"bug fixes" that someone does can unintentionally break someone else's application which depends on the old behavior. On the other hand, assigning one guy to maintain the libraries and make sure modifications won't break anything is not practical because there are many applications, and possibly many improvement requests to be done, and he can't be sure of everything either.

How do teams normally manage situation like this? Perhaps by implementing rules on allowed modification? Defining behaviours that shouldn't be changed? There are a lot of libraries in the internet used by a lot of people, for example open-source/free to use libraries like Apache, Castle, etc. How do they make sure that changes won't break existing client codes?

Best Answer

You create a public API and version it. The consumers ( the other projects ) get to follow the API and you get to unit test it thoroughly.

Also it is a good practice to do code reviews. They should be done by you and the other core developer whenever something is about to change in your common library code.

Before any changes are to be included either you or the other core developer must sign off the code. Then and only then should the change be merged into the trunk.

Be careful of changes that break unit tests on the public side of the api, in that case you should change the api's version. A good idea is to follow semantic versioning like it is suggested in the comments.

Be strict about this.

Related Topic