Comments on: Coding: Shared libraries http://www.markhneedham.com/blog/2010/02/26/coding-shared-libraries/ Thoughts on Software Development Wed, 08 Sep 2010 21:07:07 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Ultimate configurability at Mark Needham http://www.markhneedham.com/blog/2010/02/26/coding-shared-libraries/comment-page-1/#comment-45516 Ultimate configurability at Mark Needham Sat, 21 Aug 2010 11:05:47 +0000 http://www.markhneedham.com/blog/?p=2198#comment-45516 [...] then we need to be careful about what we share between applications because often it might be best to just accept a bit of duplication to avoid the implicit dependency [...] [...] then we need to be careful about what we share between applications because often it might be best to just accept a bit of duplication to avoid the implicit dependency [...]

]]> By: Mark Needham http://www.markhneedham.com/blog/2010/02/26/coding-shared-libraries/comment-page-1/#comment-32604 Mark Needham Fri, 26 Feb 2010 16:50:57 +0000 http://www.markhneedham.com/blog/?p=2198#comment-32604 No it was fine, I'm not entirely sure about my opinion about sharing code so it's interesting to hear other ideas as well. We're trying out the strategy you suggest so it will be good to see if it helps reduce some of the problems we experienced with other approaches. No it was fine, I'm not entirely sure about my opinion about sharing code so it's interesting to hear other ideas as well.

We're trying out the strategy you suggest so it will be good to see if it helps reduce some of the problems we experienced with other approaches.

]]> By: INTPnerd http://www.markhneedham.com/blog/2010/02/26/coding-shared-libraries/comment-page-1/#comment-32603 INTPnerd Fri, 26 Feb 2010 16:47:52 +0000 http://www.markhneedham.com/blog/?p=2198#comment-32603 Hope I did not sound too critical. Overall a good post with some good points and good food for thought. Mainly I agree that if done incorrectly sharing code is often more trouble than it is worth. I also agree that the code needs to generic enough to be useful and generally don't recommend sharing domain code. I was just trying to point out an alternative sharing strategy that alleviates some of the problems with sharing. I think if you are using this strategy then I disagree with what you said about only sharing code that is unlikely to change. Hope I did not sound too critical. Overall a good post with some good points and good food for thought. Mainly I agree that if done incorrectly sharing code is often more trouble than it is worth. I also agree that the code needs to generic enough to be useful and generally don't recommend sharing domain code. I was just trying to point out an alternative sharing strategy that alleviates some of the problems with sharing. I think if you are using this strategy then I disagree with what you said about only sharing code that is unlikely to change.

]]> By: The Morning Brew - Chris Alcock » The Morning Brew #548 http://www.markhneedham.com/blog/2010/02/26/coding-shared-libraries/comment-page-1/#comment-32577 The Morning Brew - Chris Alcock » The Morning Brew #548 Fri, 26 Feb 2010 08:01:24 +0000 http://www.markhneedham.com/blog/?p=2198#comment-32577 [...] Coding: Shared libraries - Mark Needham discusses code re-use across projects via a shared library, looking at the types of code you might want to share, some situations where it may seem like a good idea to share when in practice it is not, and some things to be careful about when sharing code [...] [...] Coding: Shared libraries – Mark Needham discusses code re-use across projects via a shared library, looking at the types of code you might want to share, some situations where it may seem like a good idea to share when in practice it is not, and some things to be careful about when sharing code [...]

]]> By: Mark Needham http://www.markhneedham.com/blog/2010/02/26/coding-shared-libraries/comment-page-1/#comment-32576 Mark Needham Fri, 26 Feb 2010 07:40:39 +0000 http://www.markhneedham.com/blog/?p=2198#comment-32576 yeh you're right I guess some of the problems would stretch across lots of different sharing scenarios. Actually I think the solution that you propose is quite similar to what we've eventually ended up with. Another problem that we ran ourselves into was having individual shared libraries when the common one started differing which was even more of a mess but thankfully we've got rid of those ones now. Also absolutely right about it not being black and white - I was just trying to see if there was any situations where it makes more or less sense to share code. yeh you're right I guess some of the problems would stretch across lots of different sharing scenarios.

Actually I think the solution that you propose is quite similar to what we've eventually ended up with. Another problem that we ran ourselves into was having individual shared libraries when the common one started differing which was even more of a mess but thankfully we've got rid of those ones now.

Also absolutely right about it not being black and white – I was just trying to see if there was any situations where it makes more or less sense to share code.

]]> By: INTPnerd http://www.markhneedham.com/blog/2010/02/26/coding-shared-libraries/comment-page-1/#comment-32564 INTPnerd Fri, 26 Feb 2010 04:23:31 +0000 http://www.markhneedham.com/blog/?p=2198#comment-32564 The problem you mentioned you had in the "Test Code" section seems like a problem that is likely to come up any time you share code. There is always a chance that it will need to be changed in some way to be more flexible and accommodate more features or bug fixes. One solution to this problem that I thought of is kind of a middle ground where you are getting some of the benefits of sharing libraries (but not all of them) without the drawbacks. Here is how you do this. Lets say you are starting a new project and there are not yet any shared libraries from other projects and you want to start creating one. What you do is go ahead and create a separate library with the common reusable code, but keep it in the same source code repository in your version control system as the project you are currently working on. After you have released the first version of this project, create a new repository for the library you want to share. However this should only be a copy of the library and should not be connected to your project. Now when you start a new project and you want to reference this library, you actually want to create another copy of it in the repository for your new project. Keep it separate from the repository with only the library in it. Now you have two projects using a version of that library, but they are not obligated to keep up with or update the the library that has its' own repository. If these two projects remain very active, you might choose to merge any changes in this library between that project and the library repository, but you don't need to. If merging the changes becomes more trouble than it is worth you can stop at any time and let the projects start to have their own customized version of that library. I would expect that every project would have a point at which you will want to stop merging these changes when it starts to become less actively supported and you don't have time to keep all your projects merged. With this model even if you never merge changes you still get the benefit of new projects benefiting from SOME of the work old projects have done. Like most things in software development it is not a totally black and white decision of either sharing or not sharing. The problem you mentioned you had in the "Test Code" section seems like a problem that is likely to come up any time you share code. There is always a chance that it will need to be changed in some way to be more flexible and accommodate more features or bug fixes.

One solution to this problem that I thought of is kind of a middle ground where you are getting some of the benefits of sharing libraries (but not all of them) without the drawbacks.

Here is how you do this. Lets say you are starting a new project and there are not yet any shared libraries from other projects and you want to start creating one. What you do is go ahead and create a separate library with the common reusable code, but keep it in the same source code repository in your version control system as the project you are currently working on. After you have released the first version of this project, create a new repository for the library you want to share. However this should only be a copy of the library and should not be connected to your project.

Now when you start a new project and you want to reference this library, you actually want to create another copy of it in the repository for your new project. Keep it separate from the repository with only the library in it.

Now you have two projects using a version of that library, but they are not obligated to keep up with or update the the library that has its' own repository. If these two projects remain very active, you might choose to merge any changes in this library between that project and the library repository, but you don't need to. If merging the changes becomes more trouble than it is worth you can stop at any time and let the projects start to have their own customized version of that library.

I would expect that every project would have a point at which you will want to stop merging these changes when it starts to become less actively supported and you don't have time to keep all your projects merged.

With this model even if you never merge changes you still get the benefit of new projects benefiting from SOME of the work old projects have done.

Like most things in software development it is not a totally black and white decision of either sharing or not sharing.

]]>