Call Girls Manjri Call Me 7737669865 Budget Friendly No Advance Booking
Editor's Notes
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
I’ve been a Crucible developer for a few years now, and I’ve grown more interested in the idea of code review best practices. I want to help to improve the industry itself - rather than just Crucible.\n
And really its because over these years I’ve seen some pretty crap reviews. It shatters me how often I see people get it wrong, and even more when they turn around and blame the tools or the code review process. \n\nIm going to show you what people are doing wrong, how much impact they can have, and Ill suggest some ways to help mitigate these problems.\n
But first - why should you be doing code review? Why are people considering it? Well, there are a bunch of proven benefits of code review, and Im sure you’ve heard it all before: finding defects sooner, mentoring younger developers and sharing knowledge across the team. And its a must have for distributed teams.\n\nAnd it sounds appealing. Some of you might even be thinking about trying code review. But when you do try it, you’ll probably hit some bumps, and you wont be alone.\n
As a Crucible dev I see heaps of teams struggling with code review.\n\nSomeone has been working on a branch for a week or a month, and finally they think its ready for someone to look at. So they shove it all into one big review.\n\nMaybe there’s a complicated change. So just to be sure, you’ll add an extra reviewer. Or two, or three.\n\nThese keep coming up, all the time, because people don’t realise the negative impact these behaviours can have. I’m going to show you just how big that impact can be.\n
Why is it a bad thing to have lots of files in a review? Well, as you’d expect, most files in a review aren’t isolated. They interact with multiple other files. To review one, you have to figure out what other files it touches, find them, read and understand them, before finally coming back to the original file. These overheads grow exponentially with the number of files. And as the number increases to 10, 20, 100 files, their costs become huge.\n\nNow lets look at some data from Atlassian’s internal Crucible instance - this instance has thousands of reviews from JIRA, Confluence and other teams within Atlassian.\n
This is lines of code per file against the number of files. Each file in a review is roughly the same size, regardless of file count. So you’d expect that each file would take about the same amount of time to review.\n\nSo if we were to look at time spent reviewing per file, you’d expect it to look something like this.\n
A straight, flat line. That is, the same amount of time per file. But this is what we see in practice.\n
Its not flat. It’s not even close to flat. It plummets in just the first 10 files, and continues to drop after that. People are spending less time per file - they are less thorough - when there are more files in a review.\n\nThis is massive. This code isn’t even being reviewed. And thats with just 90 files, I see customers with literally hundreds of files in review.\n\nOf course, file count isn’t the only problem with large reviews.\n
This is time spent against lines of code, and again, you can see that people are spending less time as the review grows. Where up here, people are spending seconds per line, down here they’re spending... pretty much nothing. They’re looking at hundreds of lines per second.\n
When you look closer, you find that most files in these larger reviews aren’t actually directly related. Reviewers are left to figure out the mess on their own, and its basically because the author was lazy.\n\nThis pain is unnecessary. Don’t be lazy. Spend some time removing the cruft, stripping the review down to its bare essentials. If its all absolutely essential, break it up into smaller focused reviews.\n\nFor any non-trivial review, you should also just tell the reviewers what to do. In comments or objectives, the author can point to the more important stuff, so reviewers will know where to focus their efforts.\n
A problem I find more interesting, and is perhaps less intuitive is the number of reviewers. Sometimes, for certain changes, people tend to think its a good idea to add more reviewers. You might think there are some valid cases, e.g notifying people of a change, but each extra reviewer adds more complications.\n\nWhen there are more reviewers, they can grow complacent. They’re only human after all, and intentionally or not, they can and will assume that others will do the work.\n
This is a review from the Atlassian Crucible instance. It has 9 reviewers. And it looks like they’ve all completed it, which is great. But looking at the details, theres a bit more to it. 3 people have spent less than 3 minutes each. It took others half an hour to an hour to review. \n\nThey’ve marked it as "complete" anyway, and even added what seems to be a single legitimate comment. This superficial level of reviewing, not only creates a false sense of security, but its just a waste of everybody’s time.\n
You can see how this complacency grows as there are more reviewers. Each additional reviewer adds a little bit less value.\n\nWhats really interesting here though is this drop between 3 and 6 reviewers. When there are 6 reviewers, they are spending the same amount of total time as when there are 3.\n\nEach additional reviewer has reduced the amount of effort given by the other reviewers. In our case, by 50 percent!\n
And its not just time thats affected here. According to this graph, as there are more reviewers, there are actually less defects raised - less defects in total! \n\nSo again, each addition reviewer has reduced, this time the quality of effort given by other reviewers.\n\nIn the review I showed you, thats over 4 hours of reviewing, between 9 people, to find less bugs and generate less discussion about the code.\n
In hindsight, there are at least a couple of those people that didn’t need to be there. They just didn’t add value. \n\nTheres a feature in Crucible that suggests reviewers for you. It bases this on how much they’ve had to do with the files in the review, as well as their work load. \n\nBeing one of my successful FedEx projects, I totally recommend using at least a similar approach. Choose a focused group (or pair, or person even) to review your code. \n\nFor each reviewer, consider what value they’re actually adding. Then consider how much they’re going to cost.\n\nIf you really have to add more people, tell them individually what to do, what they’re there for.\n\nYou can also let people opt out of reviews. It will save everybody’s time and it will give you more accurate confidence in whats actually been reviewed.\n
But what does all of this mean? It means that you generally have to consider your reviewers. Creating reviews in certain ways can have a huge impact on their efficiency and effectiveness, the dramatic trends in the graphs show this.\n\nThink generally about the size of your changes. If you try to pack too much in, chances are, no one will even look at it. If you apply this practice before you even commit, you’ll make it easier on yourself when creating reviews, and you’ll also see benefits in your SCM history and continuous integration.\n\nChoose your reviewers carefully. You can have too many reviewers, and its probably far fewer than you’d think.\n\nUse objectives or comments to describe the overall architecture of a change - give some guidance as to how people should approach the review.\n
What I’ve shown you is how these problems affect Atlassian. They may affect you differently. However, all the graphs were generated in a crucible plugin. Download “Review Statistics” now at plugins.atlassian.com and install it on your own Crucible instance. You can understand how your reviewers think and optimise code review for your team.\n
Some more things I’d be interested in are the effects of reviewing speed, author guidance or even just the day of the week. And proper statistical analysis would make the results a lot more meaningful.\n\nThe more we know about your code review practices, the better, because we can find ways to ease some of your pain points. \n\nCrucible could help you break large reviews into smaller logical pieces. \n\nWe could allow reviewers mark files as "trivial" or "important", which could organically guide other reviewers. \n\nOr maybe different reviewer types, like "FYI Reviewers" would help to reduce some of the negative effects of having too many. \n\nBut this all depends on you. We obviously can’t (and shouldn’t) implement everything, so if you have any opinions or thoughts about any of this, please tell us - online, or come talk to Anton or myself after this - we are more than happy to hear what you have to say.\n
If I could reiterate one thing, it would be to keep your reviews concise. This will give them more focus, you’ll get more out of your reviewers, and you’ll start to see the good parts of code review.\n
