How do you organise your code library?

Question

I am interested to know how people organise their code libraries, particularly with respect to reusable components. I am talking in OO terms below but I am interested in how your organise libraries for other types of language also.

For example:

• Are you a stickler for class library projects for everything or do you prefer to keep everything in a single project?
• Do you reuse your prebuilt DLLs or do you include individual classes from previous projects in your current work? If individual classes, do you share them between the projects to ensure all are kept up to date or do you permit branching?
• How large are your reusable elements? How focussed are they? How are they focussed?
• What level of reuse do you attain through your preferred practices?

etc.

EDIT

I am not looking for specific guidance here, I am just interested in people's thoughts and practices. I am particularly interested in the reuse of code between disparate projects, rather than within a single project. (Unfortunately the use of 'project' here is misleading - I mean reuse between real-world projects undertaken for customers, not projects in a Visual Studio sense.)

Eam

Answer 1

It generally can be guide by deployment considerations:

How will you deploy (i.e. what will you copy on your production machine) ?

If what you are deploying are packaged components (i.e. dll, jar, war, ...), it is wise to organize the "code library" as a collection of packaged set of files.
That way, you will develop directly with the -- dll, jar, war, ... -- which will be deployed on the production platform.
The idea being: if it works with those packaged files, it may still work in production.

---

the reuse of code between disparate projects, rather than within a single project.

I maintain that kind of reuse is easier in a "component" approach (like the one discussed in the question "Vendor Branches in GIT")

Over more than 40 current projects, we achieved:

• technical reuse by systematically isolating any pure technical aspect into independent framework (typically, log framework, exception framework, KPI - Key Performance Indicator - framework, and so on).
  Those technical components are reused into every other projects.
• functional reuse by setting a clear applicative architecture in order to divide any functional domain (given the business and functional specifications) into well-defined applications. That would typically involve, for instance, a bus layer which is also a great candidate for exposing services reused by any other projects.

Summary:
For large functional domain, a single project being not manageable, a good applicative architecture will lead to natural code reuse.

Prestigious

Answer 2

We follow these principles:

• The Release-Reuse Equivalency Principle: The granule of reuse is the granule of release.
• The Common Closure Principle: The classes in a package should be closed together against the same kinds of changes.
• The Common Reuse Principle: The classes in a package are reused together.
• The Acyclic Dependencies Principle: Allow no cycles in the package dependency graph.
• The Stable Dependency Principle: Depend in the direction of stability.
• The Stable Abstraction Principle: A package should be as abstract as it is stable.

You can find out more over here and over here.

Norse

Answer 3

It depends on what platform you work. I'm a (proud) Java developer and we have nice tools to organise our dependencies such as Maven or Ivy

Salsify

--knock knock --Who's there? ... ... ... ... ... ... ... ... ... Java – Luffa

Yes man! The question doesn't have any tag meaning .net or any other language – Salsify

It's cool to have faith in your tools, but Java isn't the only stack/toolset that has tools to help manage this stuff - and more importantly, those tools can only help you so much, you still gotta use your own brain and judgement. – Banner

Answer 4

Whatever else you decide good source code control is crucial to this,as it allows you to implement your strategy whatever way you like without ending up with lots of unrelated copies of your libraries.good branching support is essential.

Pyrene