67: Justin Collier: Best Kept Secrets of Code Review

Podcast Published on:

Best Kept Secrets of Code Reviews


In my experience, one of the most significant improvements to my team’s automation code has been due to the inclusion of all our test artifacts in our code reviews. Also — if you’re a developer doing code reviews, you should be involving your QA resources to help gain fresh perspective for things that you may not have thought of. Everyone on your development team benefits from code reviews, because the sooner bugs are caught the better it is for everyone. 

Today we’ll be Test Talking with Justin Collier, the product owner of the SmartBear peer code review tool Collaborator. Justin shares his experience in helping teams succeed with productive code reviews. In this episode you’ll discover the secrets to conducting awesome code reviews for all your coding efforts (including automation code).

–> GET FULL TRANSCRIPT <–

downloadMP3
About Justin

JustinHeadshot

As the Product Owner of Collaborator by SmartBear, Justin Collier facilitates conversations to help development teams better understand how to implement peer review processes to improve software quality. He is responsible for product direction and market related activity.

He was previously Senior Sales Engineer at SmartBear, the choice of more than two million software professionals for building and delivering the world’s best applications. Justin served as Director of Services and Support, Sr. Sales Engineer and Product Manager at TriActive. He also served NetPlanner Systems, Inc. as an RF Engineer & Technician for more than seven years.

Quotes & Insights from this Test Talk

  •  You’re finding things earlier in the process, and you’re having discussions and conversations upfront to ensure that you get it right to begin with whether that’s around requirements, or around code review, or test cases as an example.
  • You can have metrics and reporting to help you improve your processes and verify compliance. Also, you can accelerate team member onboarding, and I think that’s one of the things that a lot of people don’t necessarily think about, but I continue to hear over, and over, and over again, which is, “We love it because we can hire somebody new. Maybe it’s a junior developer, and as we’re bringing them up to speed, we’ll invite them into code reviews, and they’re able to see how we do things, what does the process look like. They’re able to start to pick up on the different aspects of the code, the different projects, or elements, or functions that we have within the tool, and then they’re able to go in and start to understand how the actual product works much more quickly because they start to have a global picture as to what’s going on within that code base.”
  • Static analysis tools, as an example, are a great way to ensure code quality, and it should augment the peer reviewed process, so you’re not looking for those types of things. 
  • Collaborator is a peer review tool. It’s designed to support a number of different SCMs. In fact, it’s 11 different SCMs that we support, so Git, and Subversion, and the Rational Team Concert, and Microsoft TFS, so a bunch of these different SCMs, and the idea is to be able to get files into a code review quickly and easily, and so we have a client that’s designed to do that. 
  • I would say that when people are looking at metrics, often times, they’re trying to get some sense of a defect density to understand how they’re doing. You have to be careful with those kind of metrics because..
  • There’s definitely situations where a tool doesn’t make sense, right? If there’s three of us, and we’re all sitting right next to one another, a tool may not make sense in that scenario. What do we really gain from introducing a tool when I can have you just take a quick look and provide me with feedback?
  • Much, much more!

Resources

Connect with Justin

May I Ask You For a Favor?

Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page.

Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.

SauceLabsSponser

Special offer for TestTalks listeners, get 20 hours of automated testing for free when you sign-up with promo code testtalks14 (more info).

3 responses to “67: Justin Collier: Best Kept Secrets of Code Review”

  1. Great show!

    Why not silo user story implementations so that anomalies are isolated, user stories are self-contained, and implementations can be swapped out without affecting the rest of the system.

    I do see value in code reviews. However, why not pair program instead? I rather collaborate early and often then later and at the end.

    In addition, if your code needs comments to explain what it’s doing then your code just isn’t clear and may require refactoring.

    In conclusion, although I have a different perspective on today’s practices, I ask what we can do before we perform these rituals so that we can decide why we need these rituals in the first place.

    What do you think?

    • I think the earlier you can do anything in the software development life cycle the better. So pair programming is great if you can do it. I work for a large enterprise company and many of our resources are offshore so pair-programming not always an option for me. Ultimately we need to do code review to better able document our process for FDA audits. So I guess each companies practices will differ based on their needs and RISK levels.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.