A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Hi. I'm starting a new .NET project and would think it would make sense to reuse some of the classes of an existing project. I'm curious how others here have done this. Right now the classes I want to use are in a separate SVN repository. What is the "right" way of bringing them into the new one, and ensuring that future changes to them don't break my code. The old project will see some minor development, and there is always the potential that class will change.
For any given class file, I see my options as being:
- Copy the entire class file, and have two separate copies in two separate projects. This eliminates the chance of breaking code, but also causes headaches with maintaining minute differences that pop up between the two classes. Also, all bugs that are found down the line must be fixed twice.
- Do some type of cross repository linking. The benefit of this is that we're working with a single instance of the class. The potential problem is breaking the class for one of the two projects.
I'm curious about your experience with code reuse across projects. Thank you!
Can you work from the same repository? That would make it simpler.
What is your degree of dependency? Do you always need the latest greatest? If they break your code will your world end?
How do you know if your code has broken by their code? Do you have tests that verify their changes?
The answer is in there somewhere.
If it's critical they don't break you then bring there code in at defined integration points.
If you need to be in sync with them then copy every night or on every change and have tests to verify your code still works with their code. You can even have a separate integration branch for this so nothing breaks.
son of parnas
Saturday, July 07, 2007
What I do is use externals (check out the SVN documentation on that). I have a common library of code that is shared between projects and that library in it's own repository. I use the externals property to "include" them into every other project's local workspace. When I commit, the project code is committed to one repository and the library code is committed to another. That way all the projects share the library and there's only one copy of it.
You can use branches to ensure that you won't break one project with changes to another just as you normally would with subversion.
Almost H. Anonymous
Sunday, July 08, 2007
For a bunch of related classes, it's sometimes best to refactor the classes into a library with its own versioning. One big benefit is that its clear to everyone that there may be more than one product that relies on the included code. Otherwise, it's easy for the team that "owns" the included code to break the contract with your software when they upgrade theirs.
Creating a formal interface specification for a library is also a great idea.
Personally, I'd break them out into their own project and start fleshing out Unit Tests for anything that will be changed. The nice thing is that you can either have those Unit Tests exist within this new project *or* have them exist in the projects that are using these libraries and treat them as Enemy Unit Tests: http://caseysoftware.com/blog/enemy-unit-testing
I would tend to put them in the other projects as the developers on those are likely to have a better understanding on what they behavior should be for their purposes. Even if it's one person doing all of it, knowing that Project A needs X while Project B needs Y is more helpful than just testing for X and Y.
Sunday, July 08, 2007
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz