This post originated from an RSS feed registered with Java Buzz
by Mathias Bogaert.
Original Post: 5 tips for great code reviews
Feed Title: Scuttlebutt
Feed URL: http://feeds.feedburner.com/AtlassianDeveloperBlog
Feed Description: tech gossip by mathias
In almost every organization, team members collaborate to get work done. Software teams typically transition issues between people for different functions like code development, code review, and testing (even if they are all on the same team). When transitioning an issue from one team member to another it’s important to minimize the amount of ramp up required for the receiver to fully understand the issue. Transferring issues can be extremely expensive as it requires time from not only one, but two team members. Reviewing code, however, is a best practice among software teams. Code review helps distribute knowledge of the code base making the team more flexible, fault-tolerant, and more nimble. Since knowledge of the code base is distributed across the team, no one person is the bottleneck for the team to make progress across the code base. Code reviews turn individual knowledge into its more powerful cousin: distributed knowledge. Tweet So how can team members easily introduce new issues to other members efficiently? The trick is good issue tracking practices. Well informed issues keep all of the history in one place and enable all team members to view an issue as a dashboard for that item of work. Let’s take a look at five key practices to create this dashboard and minimize transition time between team members. 1. Ensure you have a clear definition of done A consistent definition of done creates a clear boundary between code authors and code reviewers. Developers will often collaborate during development. This is a good thing and should be encouraged as the team is problem solving. Having clear metrics around what it means to be code complete ensures reviewers have a consistent baseline and quality bar when doing reviews. That way, when someone gets a notification from JIRA requesting a review, they know that the code has been checked in, built, and passes some level of automated testing. This gives the reviewer confidence that their time is being well spent. No one likes reviewing code that breaks the build in heinous ways. 2. Make action obvious: status and assignee Writing code and reviewing code are two separate operations. Having separate statuses inside of JIRA for these two states makes it easy for the rest of the team to see the progression of work. Code awaiting review is known to be checked in, built, and validated by automated testing. That is important to advertise to the rest of the team and business. Some teams will transition the assignee of the original issue to the code reviewer during review. Other teams prefer creating a custom field called reviewer where they track this information. In the latter method, JIRA administrators can add a screen to prompt for a code reviewer when a developer transitions an issue from in progress to in review. ProTip: Edit the default quick filter “Only My issues” in JIRA Agile to assignee=currentuser() or reviewer = currentuser if your team is tracking reviewer in a custom field. JIRA 6.3 makes issue tracking a natural extension of development. JIRA’s new workflow triggers make it easy to automate […]
Previous Topic
