Don’t share your code! |
|
| Written by Mark Bools |
| Wednesday, 23 March 2011 05:15 |
|
Bet that got your attention. And I’m serious. In this post I am going to tell you why sharing code is a bad idea. I am also going to tell you that you should share the functionality of your code. That is an excellent idea. What I mean when I say ‘don’t share your code’ [...]
Bet that got your attention. And I’m serious. In this post I am going to tell you why sharing code is a bad idea. I am also going to tell you that you should share the functionality of your code. That is an excellent idea. What I mean when I say ‘don’t share your code’ is that you should not allow multiple projects to work simultaneously on common code. Don’t map the same source code into two different projects. This is a mistake I have seen made when people discover things like Subversion’s svn:externals property. They immediately start mapping ‘common’ code into each project that uses it and inevitably this causes all manner of problems. What you should do is hive off the common code into a project of its own and then release packages to each project that needs it. These packages may be libraries (JAR files, object libraries, etc.) and where appropriate header files. These should be protected to prevent changes by the consumer projects and should be released as a product. The common code becomes a released entity in its own right and the products of each release (the functional libraries) are consumed by any projects that need them. If any project needs to change the common code a change is raised to have the modifications made. Because the common code’s products are shared, appropriate impact assessments can be made and individual projects can the decide when, if at all, to adopt the new release of the common functions. Filed under: Plain Old Blog
Set as favorite
Bookmark
Email this
Hits: 307 Trackback(0)Comments (0)
|



