Archive for December, 2007

SVN

Sunday, December 16th, 2007

I’m on a multi-year long-term project, I came on in just in the last year, and I and a colleague have done some serious improvement from what was a less-than auspicious starting point, starting (this is where my involvement came in) firstly with getting the whole mess into SVN. This has been helpful in numerous ways, some of which I really didn’t understand at the time. My initial thughts: there is no reasonable way to have multiple people working on the same codebase without some file checking mechanism of some sort. I’d used SourceSafe at a previous job, and back in school, RCS, and while file locking was problematic when someone went on vacation with things checked out, at least solved the basic problem of people stomping on each others’ work. I’d heard SVN was better because of the merging vs. exclusive locking I’d used in the past. I was admittedly, really, really skeptical about this, but decided to give it a go. I’d also been hearing rumors about Git and a few other things, but decided just picking one was a best path as any of these choices would be 1000 times better than no source control, and it sounded like migration things were in abundance anyway if we changed our minds. Besides, we wanted HTML coders to use the thing, so something that had a gui available to avoid arcane command-line stuff (Tortoise SVN in this case) seemed the best choice.

As it turns out, SVN has been beneficial in many, many more ways than the simple collision avoidance I’d wanted it for. A few are listed here…

1) Branching. We spent several months in development for a new version of our product. During that time, we had to do numerous bugfixes on the maintenance code. Having a separate branch for the current live codebase allowed us to have a clean copy of what was live, make fixes, and then merge over as need to the live branch. It really saved us work, and allowed us to deal with the live and development codebases together in a way that saved a bit of our sanity.

2) blame. A command I didn’t even discover for a while, it really allowed me to find the answer to “why is this here?” A question I’ve had many times of mystery bits of code in my career. Now, I can see who did a change, what checkin, and when. I can see notes telling me what that checkin was for, and if the person is still around, I know who to question on reasons if needed. The value of this cannot be overestimated.

3) Tracking what a particular person does. This may sounds spy-like, but if you have a particularly good developer on your team whose code you want to learn from, a person who you know is working on critical things you want to follow, or a more junior developer whose code you want to keep tabs on, it’s invaluable to be able to simply look at that person’s checkins. It’s easy to look at every single line of code that person entered.

The Pragmatic Programmer

Sunday, December 16th, 2007

I’m about 3/4 of the way through this. I’d heard a lot of it from other people so there’s not a lot that’s stunningly new, but it’s a good introduction to a lot of better principles. In particular, I’d heard about the DRY principle, but it was good to actually read about it. Some of the stuff about coding defensively seems good, but I feel like it could be going a bit overboard. The discussion of the constraints in Eiffel sounded interesting, and I hear RSpec has something interesting. Something to look into…

Introduction

Sunday, December 16th, 2007

I am currently a somewhat beginner-level developer, primarily doing .net. My definition of beginner is perhaps not what most would consider a beginner-level: I have been in the web business for a good 10 years or so cutting my teeth on perl and server-side javascript, a bit of ancient pre-5 ColdFusion, and some Solaris administration, among other things. I’ve done quite a bit of SQL Server work. classic ASP, Java, and a year or two of .net.

However, I consider myself a beginner in that I am inexperienced in better ways to do development. I’ve always striven to write clean code, but felt the typical pain points at times. With my experience, I think I’ve felt about every pain point there is, from poor language choice to poor requirements, team issues, to poor design choices and project monetary concerns. I’ve recently become aware that it doesn’t have to be this way, and am interested in finding a new path. This is my journey to becoming a better developer.