Code Reuse

Code reuse has been a buzzword for quite some time now, but it has never really been used as extensively as it should be.  At my work, I've been trying to get some level of code reuse for the past 15 years, but was often stymied by "if it ain't broke don't fix it" attitudes of copy and pasters.  They saw code reuse as introducing a dangerous level of complexity by exposing them to code that someone else has written, which could possibly be changed on a whim, or not changed to meet the needs of the reuser.  And they're right.  There was no clear path to the 'land of milk and honey' that code reuse promised.  Our CM systems and administrators went cross-eyed when I try to set up  some jar files that might be used by more than one project in a single place.  Eventually I turned my back and the jar files were duplicated for each project, and the administrators gave a sigh of relief, that such an abomination was corrected.  There was no simple way of saying, "here's some code that's used in two separate project, but should be maintained in one place", so the dream of code reuse was unfulfilled.

Then, around five years ago, the maven project was started.  As far as I can tell, it started as an attempt to formalize a development process that used to be done by ant.  It took the strategy of convention over configuration, that is, if you accept the convention, you don't need to configure.  But what happened that made maven an indispensable tool for me now, is that it froze in place their development processes that encouraged reuse.  Now there was a standard way of sharing compiled code, and tracking it with versions. There was a standard way of documenting a project.  And there is a standard way to develop, test, and release code.  The best part is that you don't need to jump through hoops to use the standard, you have to jump through hoops not to.  

I won't say that all is easy now, and that there aren't still issues that make code development real work.  But it takes code development to a new level, with new fresh challenges.  I suppose the biggest challenge facing developers now, isn't how to reuse code as maven solves that, it's how to write code that's reusable.  And really, not that many developers face that issue, as most development is done close to the end-product, that is it solves specific problems for specific users, and therefore can't be re-used.  But as the amount of reusable code piles up, that developer has to spend less and less of their time re-inventing the wheel, and more time solving specific problems.

So now that we have a path to real reuse, I thought it would be good to start writing some code that might be reused.  I could have a library of useful bits of code that I could put together for my bigger projects.  In order to do that, some initial footwork was involved setting up a few pieces.  

First and foremost behind every real development effort is version control.  I need a repository that will hold all my source code and keep track of it.  My repository of choice for this was Subversion (SVN) because it had a cute name, and it was well tied in with all of the rest of the tools in use.  I won't say that it's the best version control out there, I know that many people prefer git or cvs or others.  But I had to decide on one, and SVN was well supported by tools, and very stable.  Considering it's really the core of this system, stability is very important.

Now that I had a repository for code, I need a repository for compiled code (jar files in java-lingo).  One of the things that maven formalizes is a file-system based repository for compiled code.  You tell maven where it is, and it knows how to get compiled code needed for builds, and put the compiled output of your builds there.  But in order to have more than one development computer, and a single compiled code repository, you need a repository manager that will allow access to the repository through HTTP.  I had been using archiva, but I just switched to nexus as I moved the repository from one server to another.  They both seem to function very well, but nexus has a better UI, and functions well out of the box.  The only issue that I have with it is that it seems to have some trouble with my apache reverse proxy which I haven't been able to solve yet.  If I can't solve it, and it starts to get in the way, I may revert back to archiva.  Since the actual repository file-system is dictated by maven, it should be simple to switch back should I need to.

One final piece that needs setting up is continuous integration.  With code re-use, CI becomes very important, making sure that all the pieces of re-usable code work with all the places the code is re-used.  It works by compiling and testing code on a central server as soon as it's checked in.  If it is set up to compile all of your projects at least nightly, it will catch any places where a change in one project affects some other project down the re-use chain.  For CI I use hudson, and have it installed along side nexus.  When hudson compiles the latest code, it sticks it into nexus where any other project that's using it can see it.

So now that I have this whole setup, I need to start writing some re-usable code.  Now my biggest problem is every time I think of something that I can write as a re-usable component, it seems that someone else has already written it.  So it shifts my problem away from writing code to figuring out how to best re-use other's code.  That is the next big challenge to all developers, how best to find and reuse code that's already written, and how to survive the inevitable two steps forward, one step backwards refinement (which version should I use) of such code.