Slashdot Mirror

REXX is what you want. I could make arguments why but this article does a decent job. I'll get lambasted for recommending such a dinosaur for recommendations to a modern language but if the tool works who cares how old it is? In fact the latest version of the Regina interpreter for REXX was released just last week. If nothing else read up on some of the ways REXX has been used to "GLUE" other systems/ programming languages together. It should be just what you need to tackle those tricky situations that nobody around you will care about but make your day a living nightmare.

We have recently started doing code reviews using an online tools that ties very nicely into our SCM tool. All code changes have an associated defect or enhancement ID, are developed on a private branch, and prior to being integrated into the trunk have to be review by a member of a pool of subject matter experts. Since the team is world wide, having a web system to communicate between the various sites allows for faster response time, and helps ensure consistency in standards throughout the regions.

The product is by a company named Smartbear, called CodeCollaborator. Very pleased so far, http://smartbear.com/.

I've actually been going through the process of getting code reviews as a standard process on my own team. We've done them now and again in the past - often on other team's code that was being integrated into our platform - and it was typically a pain.

Enter A Good Tool(TM). We've been demoing some code review software lately and after settling on a particular tool that we find to work well with our workflow, the team has unanimously agreed that they find reviews beneficial. We don't have strict policies on how/when reviews are done, so it's encouraging when you see people are creating new reviews for their code of their own volition.

While we haven't found a lot of critical bugs, we have found lots of minor things, problems/shortcomings in unit tests, documentation problems (especially important because we provide libraries to other teams, we're not the sole users of the code), and even pre-existing bugs while doing maintenance. I think the biggest benefits, though, have been getting more eyes on the code to increase familiarity with it so it's easier for other people to do maintenance and bug fixes on when the original author is unable to as well as just generally opening up broader communication about various elements of style, consistency, improving code readability, etc.

The software says we've logged about 16 hours in the past month, across 7 developers. That's a pretty minimal investment. There was mention of good functional testing being all you really need, but if you're working on libraries and such it's easy to have bugs that don't show themselves in all usage scenarios. If well after a release another team manages to find a previously unnoticed bug in a library, the cost for them to track it down to our code, for us to fix it, put through QA, do a new release, pass off to the other team who then has to put their component through QA and deploy.... we've just burnt through a lot of time and money.

Will code reviews lead to perfect code? No. But I would undoubtedly say that there are plenty of benefits that make them well worth it if they're done in an effective fashion.

By the way, the software we settled on is Smart Bear's Code Collaborator, having also tried Crucible and Review Board as well as talking to other divisions about their experiences with code review software. It may not be the right tool for you, but we found it lets us bust through both initial reviews of the code as well as follow-up reviews to ensure any issues are being resolved appropriately. It's not the cheapest, but if it's the difference between a tool people will willingly use or a tool/process that people will bemoan, it's worth it.

What we've found is that code reviews take forever ...

In one place where I worked in the past, we had a very simple rule: if you are doing a code review, and it takes longer than 10 minutes, then you stop it right there and return the whole thing marked as "overcomplicated" - if it really takes that long, then either the code is written in non-obvious ways and/or poorly commented (which will result in poor maintainability anyway), or the change is too big for one source control commit. By and large, it worked, even if you have to make exceptions occasionally (but at that point you know it's not a typical review, and pay more attention).

In addition to that, you might want to consider better tooling. If you're doing reviews by sending .diff files over email, you're doing it wrong - there are many specialized tools out there that will do automatic and smart diffing (including between rounds in a multi-round CR), notify people responsible for affected files, allow to set up the workflow according to your needs, enable attaching review comments and conversations to particular files and lines of code, and so on. The shop I was working for used Code Collaborator , and I found it to be pretty good, but there are plenty other similar tools out there, and you might even be able to find some good free ones.