Whoa, didn't expect to see a blog post I wrote in grad school to get called out here. :) Interesting to see it show up on the radar.
Re-reading it, I think the most interesting thing about the Cohen study that I absorbed was the value of reviewing my own code before requesting review from other people. I've found that when I look at my own code using Splinter or Review Board, my brain switches into critique mode, and I'm able to notice and flag the obvious things. This has the dual benefit of making the code better, and making it easier for my reviewer to not get distracted by minor things that I could have caught on my own. I almost made this a topic for my graduate study research paper[1], but then did this[2] instead. Always happy to talk about code review, -Mike [1]: http://mikeconley.ca/blog/2010/03/04/research-proposal-1-the-effects-of-author-preparation-in-peer-code-review/ [2]: http://mikeconley.ca/blog/2010/12/23/the-wisdom-of-peers-a-motive-for-exploring-peer-code-review-in-the-classroom/ On 11/04/2014 5:32 PM, Chris Peterson wrote: > Code review tool company SmartBear published an interesting study [1] of > the effectiveness of code reviews at Cisco. (They used SmartBear's > tools, of course.) Mozillian Mike Conley reviewed SmartBear's study on > his blog [2]. > > The results are interesting and actionable. Some highlights: > > * Review fewer than 200-400 lines of code at a time. > * Spend no more than 60-90 minutes per review session. > * Authors should pre-review their own code before submitting a review > request and add explanations and questions to guide reviewers. > > > chris > > > [1] > http://smartbear.com/SmartBear/media/pdfs/WP-CC-11-Best-Practices-of-Peer-Code-Review.pdf > > > [2] > http://mikeconley.ca/blog/2009/09/14/smart-bear-cisco-and-the-largest-study-on-code-review-ever/ > > > > > > On 4/11/14, 1:29 PM, Gregory Szorc wrote: >> I came across the following articles on source control and code review: >> >> * >> https://secure.phabricator.com/book/phabflavor/article/recommendations_on_revision_control/ >> >> >> * >> https://secure.phabricator.com/book/phabflavor/article/writing_reviewable_code/ >> >> >> * >> https://secure.phabricator.com/book/phabflavor/article/recommendations_on_branching/ >> >> >> >> I think everyone working on Firefox should take the time to read them as >> they prescribe what I perceive to be a very rational set of best >> practices for working with large and complex code bases. >> >> The articles were written by a (now former) Facebooker and the >> recommendations are significantly influenced by Facebook's experiences. >> They have many of the same problems we do (size and scale of code base, >> hundreds of developers, etc). Some of the pieces on feature development >> don't translate easily, but most of the content is relevant. >> >> I would be thrilled if we started adopting some of the recommendations >> such as more descriptive commit messages and many, smaller commits over >> fewer, complex commits. > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
