Why Code Hoarding is bad
I have been adding some code this week and the week before and whilst I was there I refactored a fair bit of it as well. So I ended up with some code that looked very different from when I started working with it. When refactoring I find its essential that you write some unit tests so you can be confident that your changes haven't broken anything.
I had played by the rules and had written my tests and in the end the old code was working just like it use to and the new code was what it should. Whilst testing the code from the front end (a flash app) I was bemused/annoyed and very scared when it wasn't working. Unfortunately I had made the bad mistake of not checking any code in for ages, I had been code hoarding!!!
This left me with the problem of not really being able to go back to a working release and then add in the new code carefully and in a more analytical way. So I thought I would look at the problem a different way, I thought I would investigate the problem from the front end and try and work out why it wasn't working. I thought I would use this system because I was quite confident that code was okay because my unit tests were passing and the green bar was there for all to see.
In the end it turned out that the problem was due to some logic in the flash app but what this little episode has shown me is that firstly unit testing is very good. Although unit testing is good, it's not enough you need to test from the users point of view as well. I don't think there is any manual tests I could have written because the error was in the front end and in flash which I am a bit dodgy on. Although I was unfortunate to find the problem my code hording had put me in a bad position.
Code hoarding is bad bad bad. What I should have done or will be doing is checking my code in and out again every few days, at least if something does go wrong I can fall back on the code but at the position I am in at the moment it's either the old code or all the new code there is no in-between.
hopefully I have learnt my lesson but like someone with a hang over saying he won't drink again, I will be probably blogging about this again in a month or two :-)
5 Comments:
"My name is Hosky, and I'm a code hoarder"
"Hi Hosky!"
- Obligatory Code-Hoarders Anonymous joke.
Good habit to get into is to tag, tag, tag in your version control. That makes falling back to working code a breeze.
Does your version control system not have good merging? Or were the changes too massive to make merging an option?
By Anonymous, at Fri May 05, 01:49:00 pm 2006
I can just check the code in over the top as I checked out and have control of the latest version of the software.
The main slight problem was that I hadn't checked the code in for ages so there isn't really a place to fall back on. It turned out that the problems weren't to do with my code, so I have checked it in, especially since it passed the unit tests and returns what you expect.
how do you tag the code, we currently only tag the code on a release
By The Hosk, at Fri May 05, 02:21:00 pm 2006
Depends on which version control/revision control software you use. Some give you a lock that prevents others from changing the code, some let you and others change the code then flag any conflicts but force you to merge the changes by hand, some have fancy IDEs that will show you the diffs, etc. etc. etc.
Same thing with tags. In CVS it would be 'cvs tag -R "preHosky-05-2006-changes"' (or something like that) to put a tag on all the files in that directory and its subdirectories.
I suppose some companies might have rules preventing tagging for any reason other than version releases, which is a pity. They're pretty handy.
By Anonymous, at Fri May 05, 05:33:00 pm 2006
Hey what a great site keep up the work its excellent.
»
By Anonymous, at Fri May 19, 08:17:00 am 2006
I really enjoyed looking at your site, I found it very helpful indeed, keep up the good work.
»
By Anonymous, at Fri May 19, 07:05:00 pm 2006
Post a Comment
<< Home