Friday, July 17, 2009

On one project that I worked on had a cumbersome check-in process. Due to this or that problem, it was instituted that a brief write-up of what changes would be made had to be created, reviewed, and approved before any work could be done on the code. Furthermore, after the work was done, every change had to be reviewed before it could be checked in.

At first, getting the changes reviewed was horrible. The person making the changes would have to find someone to review the code, then they both had to go over to the computer with the changes, and go over the changes. Most of the time, the reviewer wouldn't really be able find any errors other than really glaring superficial ones anyhow.

Eventually, a coworker came up with some shell scripts that package up the diffs of the change into zip file and attach it to the jira issue, and also to scrape the jira page for the zip file, and unpack and apply the changes to a source tree. That made finding someone to review the changes asynchronous and less painful. For the reviewer, it was now easier to examine the changes more in depth, including doing some testing of the changes if warranted. So, the review process became almost bearable.

All this heavy-handed process would be fine in a locked-down release branch, but this was for everything.

It got so that if I happened to notice a bug in some code that I wasn't reviewing, I'd just let it be. Before then and these days, I'd just fix it if it was trivial. But, at that time, if someone else didn't come across it, it probably wasn't important enough to fix. And if someone else did come across it, I'd know just how to fix it pretty much immediately. It just wasn't worth the hassle to have to make a write-up, have it reviewed and approved, just for what was often some one-line fix, and then have to get that reviewed before checking it in.

No comments:

Post a Comment