7

Are there any processes, guidelines or best practices that can be followed for the successful implementation of a common code libraries. Currently we are discussing the implementation of common code libraries within our dev team. In our instance, our common code libraries would compliment mainstream .net software packages we develop against.

In particular, im interested in details and opinions on:

  • Organic vs design first approach
  • Version management
  • Success stories (when the do work)
  • Horror stories (when they dont work)

Many Thanks

Adam Jenkin
  • 179
  • 3

5 Answers5

3

I believe one should try to strike a fine balance between up-front design and organic development. The more a common library is being used by external parties, the more difficult it is to change its API once it is published. So it should be well thought out and consistent from the beginning. However, it is meant to be used by other people, so it should follow and adapt to the client's needs rather than purely fulfilling some academic design principle.

In practice, communication between the library developers and their (prospective) clients is key. The designers must test every idea about the API against real life before committing to it. Josh Bloch talks about this in Coders at Work: he always writes lots of code to actually use his APIs under development, even when these are only a half-formed skeleton without any real functionality. This gives him valuable feedback to improve the interfaces and make them easy to use and unambiguous for the common use cases.

Péter Török
  • 46,427
  • 16
  • 160
  • 185
2

An instructive horror story is Patterns of Failure. Basically over-generalization of code is regarded as an anti-pattern. If you build common code libraries, make sure they stay loosly coupled as much as possible. Try to tend toward a toolbox architecture, where you pick what you need depending on the project you`re working on, instead of a Big-Core-Monolitic Library that can do everything, except evolving.

Matthieu
  • 4,559
  • 2
  • 35
  • 37
  • +1: Best Practice. Don't. Go Very Slowly here. If you can't find 3 existing repetitions of the same code, you don't have a "common" situation. – S.Lott Feb 10 '11 at 21:33
0

Naming convention should be in place. Make the name of classes, functions, events, etc. self explainatory. This will help finding function and avoiding duplication/confusion.

Gabriel Mongeon
  • 179
  • 5
  • 8
0

At least for C++, I think one of the most interesting approaches is the Loki library by Andrei Alexandrescu, explained in Modern C++ Design.
Specifically the Policy-based class design, it gives the user of the library a way to configure exactly how they want the modules to behave and work.

Santiago V.
  • 121
  • 3
0

I favour the organic approach, aimed at building a library of small, independent, utilities, rather than big frameworks.

Here's how we do it (in Java), at my current workplace. We have put our general purpose common code in a single project. Developers add to it as they see fit. Usually common code starts off as project-specific code, and is contributed as it becomes more generally useful. If chunks of functionality get too big, they are spun off into a separate project. Each of these projects builds to a jar. We refactor cautiously, and use unit tests to help keep the library stable.

The source code is all in CVS, but any popular version control system would do the job. Business applications that use the common library work in one of two ways. Most just build against the latest committed code. Some require more certainty, and use CVS tags to control the version of the source code that they are using. A third way, which we do not use, would be to build the common code jars as external libraries: pre-built artefacts, maintained separately.

sandfly
  • 1