CODEWITHSUNDEEP
c#.net
bufferz
bufferz

Reputation: 3476

Creating/Maintaining a large project-agnostic code library

In order to reduce repetition and streamline testing/debugging, I'm trying to find the best way to develop a group of libraries that many projects can utilize. I'd like to keep individual executable relatively small, and have shared libraries for math, database, collections, graphics, etc. that were previously scattered among several projects and in many cases duplicated (bad!). This library is to be in an SVN repo and several programmers will be working on it. This library will be in constant development along with the executables that utilize it.

For example, I want a code file in ProjectA to look something like the following:

using MyCompany.Math.2D; //static 2D math methods
using MyCompany.Math.3D; //static #D math methods
using MyCompany.Comms.SQL; //static methods for doing simple SQLDB I/O
using MyCompany.Graphics.BitmapOperations; //static methods that play with bitmaps

So in my ProjectA solution file in VisualStudio, in order to develop/debug the MyCompany library I have to add several projects (Math, Comms, Graphics). Things get pretty cluttered and Solution files get out of date quickly between programmer SVN commits.

I'm just looking for a high level approach to maintaining a large, shared code base in an SCN repository. I am fully willing to radically redesign my approach. I'm looking for that warm fuzzy feeling you get when you're design approach is spot on and development is fluid and natural.

And ideas? Thanks!!

Upvotes: 1

Views: 255

Answers (2)

D'Arcy Rittich
D'Arcy Rittich

Reputation: 171411

I would normally make use of SVN externals for this.

ProjectA
ProjectA\Libs
ProjectA\Libs\Maths     <-- svn:external pointing to your Maths repo
ProjectA\Libs\Comms     <-- svn:external pointing to your Comms repo
ProjectA\Libs\Graphics  <-- svn:external pointing to your Graphics repo

You may want to put all your libs in one repo - it depends on how big the code base is, how many different people are working on them, etc.

Then your build script is set up to build each of the libs projects before building ProjectA. This way you get the latest committed version of each library. If you wish to lock down the libraries to a specific revision, e.g., because you are tagging a release and you want to always get the same revision of libraries when you check out an older revision of ProjectA, you can specify a revision number in the svn:external URL.

Of course when using a lot of dependencies like this, you should have solid unit tests for all of your libs, and make sure they are run whenever you build.

Upvotes: 2

Dean J
Dean J

Reputation: 40298

Keep the size of the libraries relatively small.

Do not rewrite publicly available libraries that are actively maintained. For Java, that'd be Apache Commons; for C#, CommonLibraryNET comes to mind. I can't believe that for collections, the code hasn't already been written; for something specific, like a company-specific database install, having a library that's already set up for you could be pretty darn good, though.

If it's "under constant development", you might want to have version numbers. Keep the interfaces consistent; don't remove functionality often if ever. To make that a sane policy, don't add functionality that's not actually going to be used, as it'll crowd out the functionality that folks will be looking for.

Get buy in from the groups you want to be using this; after seeding a small set of base functionality, get the other groups to help you to add to it. Make it a more open process, and it's more likely to catch.f

Upvotes: 0

Related Questions