What do you think?
Rate this book
Best Kept Secrets of Peer Code Review: Modern Approach. Practical Advice.
Ten practical essays from industry experts giving specific techniques for effective peer code review.
164 pages, Paperback
First published January 1, 2006
8 people are currently reading
93 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 23 of 23 reviews
March 17, 2015
This is a 160+ pages book that could have been perfect as a 10 pages essay. Why do authors believe they need to cross the 100 page mark to give meaning to their work? I don't get it. 50 pages books are still books, guys. I think the long-windedness is particularly harmful to the cause of this immensely valuable practice, because it gives the false idea you need oh-so-much study to start being an effective code reviewer.
There were some good takeaways though:
- code reviews are only good if they are effective at finding defects. So, studies cited here show that each code review session should be: (1) 1 hour max, (2) 400 lines max
- simple strategy to avoid repeating mistakes: log every mistake you make and how many times. By just doing this, you'll soon anticipate the mistake and actually prevent it. They postulate this is true for any mistake, not just coding mistakes. Makes sense to me.
- one of the big problems for code reviewers is finding what's not there. It's easy to spot a nil dereference crash, but can you spot that the developer forgot to call super in an override? Or that they called a method that's unavailable in a latest OS version? To approach this hard problem they suggest to use checklists. A reviewer would write their own list of things to check in every review, until they finally learn what to check. This is very pragmatic (not to mention pretty tedious) and I wonder if it can harmfully become the be-all-end-all of code reviewing.
- look for one defect kind at a time throughout the whole code to be reviewed, then rescan the code looking for another kind of problem. This multiple pass system is kinda interesting, I should try it out.
The last chapter is a shameless plug for SmartBear code review tool.
There were some good takeaways though:
- code reviews are only good if they are effective at finding defects. So, studies cited here show that each code review session should be: (1) 1 hour max, (2) 400 lines max
- simple strategy to avoid repeating mistakes: log every mistake you make and how many times. By just doing this, you'll soon anticipate the mistake and actually prevent it. They postulate this is true for any mistake, not just coding mistakes. Makes sense to me.
- one of the big problems for code reviewers is finding what's not there. It's easy to spot a nil dereference crash, but can you spot that the developer forgot to call super in an override? Or that they called a method that's unavailable in a latest OS version? To approach this hard problem they suggest to use checklists. A reviewer would write their own list of things to check in every review, until they finally learn what to check. This is very pragmatic (not to mention pretty tedious) and I wonder if it can harmfully become the be-all-end-all of code reviewing.
- look for one defect kind at a time throughout the whole code to be reviewed, then rescan the code looking for another kind of problem. This multiple pass system is kinda interesting, I should try it out.
The last chapter is a shameless plug for SmartBear code review tool.
January 6, 2024
It’s ok but fairly outdated at this point.
July 30, 2020
As a software engineer, I spend a significant amount of my professional time reviewing other's code. I am sure the organizations also depend on peer code review as an essential and first-line defense again expensive bugs. This is an old book from 2006 (in computer time, prehistoric perhaps), the only one I could find on peer code review. Although the tool-assisted code review the book touts about probably is commonplace by now, the ideas related to the human part of the code review are still relevant. For example, to catch omission errors, have a checklist of common errors while reviewing other's code and systematically go through each. One could improve one's own coding by recording and regularly revisiting the errors caught by others during his own code review. The reviewer should not review for more than an hour at a time, after that the concentration drops. A reviewer should bring a fresh point of view to uncover bugs, thus he should prevent himself from thinking like the author, he should not jump into line-by-line review at the start. As the book shows, the dollar value of effective code review is huge. To uncover many bugs, a reviewer needs to slow down. Although code review has learning opportunities for both parties, in the absence of explicit rewards, it is hard to keep burning one's time in uncovering bugs in and bettering "other's" code.
November 30, 2019
Handy collection of essays on the history and merits of code review. A bit dated, particularly as it was published before the days of pull requests, but the insights are useful none the less. The impact of checklists and review rates was particularly interesting. A useful resource if you find yourself having to defend the process.
October 12, 2021
Interesting studies about what metrics to use, offers pointers on how to organise things (although some of it is outdated, like "send e-mails with files around", there is the trade-off "do we do everything in a big meeting" vs "more loosely")
August 14, 2017
Most of the content is outdated, shouldnt have picked it up.
April 15, 2008
My first impression was "Surprisingly readable!", and that was carried through almost the entire collection. Jason Cohen wrote the bulk of the chapters, with "Resistance to Code Review" written by Eric Brown and "The SEI Perspective" written by Steven Teleki. Jason Cohen is the founder of Smart Bear Software, the company that provides this book for free.
Actually, let me digress for a moment here. This book has three very clear, very up-front goals: to persuade readers that code review is valuable, to persuade readers that informal code review is as well or better suited to modern coding practices than formal code review, and to persuade readers to purchase and use the code review software written by Smart Bear Software. I think it's to the credit of the book qua book that the first two points can succeed while the third fails! (Although the Smart Bear product does sound very good and I may well recommend it at some point in the future, it doesn't fit with what I need right now. This doesn't detract at all from the usefulness to me of the rest of the book.)
I approached this book from two perspectives: as a developer working for a smallish software company that's trying to move toward agile practices in maintaining existing applications and as an advisor to an all-volunteer software group that's just starting up a flagship application and a handful of smaller projects. Much of this book is addressed to people in management capacities, and unsurprisingly I found much of it more useful for my volunteer role as semi-management advisor than for my professional role as managee.
Sadly, the chapter that should have had the most immediate impact for me as a developer, "The SEI Perspective" by Steven Teleki, was the only one which was truly terribly written! While the rest of the book was written in a chatty and engaging style, even in the rigorous "Code Review at Cisco Systems" chapter that presented data from a large case study, this chapter on how developers can begin integrating personal review segments into their coding cycles was both dry and confusing -- I had to reread it twice just to understand the extremely simple logical equations -- and has not inspired me to shift my coding practices at all.
Although the argument of this book is that both modern coding practices and modern coders are supported well by informal code reviews, it admits from the beginning and throughout that the data to back up this or any other conclusion about code review does not exist. The chapters on "Brand New Information" and "Code Review at Cisco Systems" lay out highly suggestive trends but make it clear that there have been no rigorous studies of code review done to answer the questions raised in this book. "Code Review at Cisco Systems" in particular is quite frustrating in a so-close-but-not-complete way! (The author is quite aware of this and sharing the frustration.)
Although the discussions of the social aspects of code review were often repetitive, I found this useful and not irritating; the chapters are clearly intended to be considered as separate essays and refer back and forth to each other for more details on various points. The "Five Types of Review" chapter was particularly informative and laid a good basis for the later chapters.
Overall, well worth the time!
Actually, let me digress for a moment here. This book has three very clear, very up-front goals: to persuade readers that code review is valuable, to persuade readers that informal code review is as well or better suited to modern coding practices than formal code review, and to persuade readers to purchase and use the code review software written by Smart Bear Software. I think it's to the credit of the book qua book that the first two points can succeed while the third fails! (Although the Smart Bear product does sound very good and I may well recommend it at some point in the future, it doesn't fit with what I need right now. This doesn't detract at all from the usefulness to me of the rest of the book.)
I approached this book from two perspectives: as a developer working for a smallish software company that's trying to move toward agile practices in maintaining existing applications and as an advisor to an all-volunteer software group that's just starting up a flagship application and a handful of smaller projects. Much of this book is addressed to people in management capacities, and unsurprisingly I found much of it more useful for my volunteer role as semi-management advisor than for my professional role as managee.
Sadly, the chapter that should have had the most immediate impact for me as a developer, "The SEI Perspective" by Steven Teleki, was the only one which was truly terribly written! While the rest of the book was written in a chatty and engaging style, even in the rigorous "Code Review at Cisco Systems" chapter that presented data from a large case study, this chapter on how developers can begin integrating personal review segments into their coding cycles was both dry and confusing -- I had to reread it twice just to understand the extremely simple logical equations -- and has not inspired me to shift my coding practices at all.
Although the argument of this book is that both modern coding practices and modern coders are supported well by informal code reviews, it admits from the beginning and throughout that the data to back up this or any other conclusion about code review does not exist. The chapters on "Brand New Information" and "Code Review at Cisco Systems" lay out highly suggestive trends but make it clear that there have been no rigorous studies of code review done to answer the questions raised in this book. "Code Review at Cisco Systems" in particular is quite frustrating in a so-close-but-not-complete way! (The author is quite aware of this and sharing the frustration.)
Although the discussions of the social aspects of code review were often repetitive, I found this useful and not irritating; the chapters are clearly intended to be considered as separate essays and refer back and forth to each other for more details on various points. The "Five Types of Review" chapter was particularly informative and laid a good basis for the later chapters.
Overall, well worth the time!
December 23, 2016
This book has been sitting on my shelf for years. I started working for a new company a few months ago, and code reviews are required for every pull request, so I thought I'd dust this off and see what's inside.
The book starts by discussing the results of various studies that have been performed on code reviews. Through this analysis, the authors make some conclusions about how to conduct an effective review. They also discuss the social impact of reviews, what metrics you should capture and how to use them, and code reviews in the context of formal processes like SEI, PSP, TSP, and CMMI.
The book was written in 2006, and it really felt that the organizations being studied took a waterfall approach to development. The techniques discussed apply equally well to agile processes, but I couldn't shake that feeling that the code review process is heavy and rigid.
The authors own a company called SmartBear, and at the time, they developed a tool called CodeCollaborator that performed...code reviews! The information in the book is solid, but more than once, I couldn't help but have the feeling that I was reading an advertisement.
Because of the above two points, I don't really recommend this book. It feels outdated. Agile practices are more mature than they were ten years ago and many of them, by their nature, will aid in code reviews. Also a number of version control systems do a very good job integrating with story and defect systems and collaboration tools, so it's very easy to have conversations around code.
All that said, I do believe understanding the perspective of the authors will help me be a better reviewer. I now see practices such as small stories, focused commits, and using linters in a new light because they aid reviews. I appreciate that awareness.
The book starts by discussing the results of various studies that have been performed on code reviews. Through this analysis, the authors make some conclusions about how to conduct an effective review. They also discuss the social impact of reviews, what metrics you should capture and how to use them, and code reviews in the context of formal processes like SEI, PSP, TSP, and CMMI.
The book was written in 2006, and it really felt that the organizations being studied took a waterfall approach to development. The techniques discussed apply equally well to agile processes, but I couldn't shake that feeling that the code review process is heavy and rigid.
The authors own a company called SmartBear, and at the time, they developed a tool called CodeCollaborator that performed...code reviews! The information in the book is solid, but more than once, I couldn't help but have the feeling that I was reading an advertisement.
Because of the above two points, I don't really recommend this book. It feels outdated. Agile practices are more mature than they were ten years ago and many of them, by their nature, will aid in code reviews. Also a number of version control systems do a very good job integrating with story and defect systems and collaboration tools, so it's very easy to have conversations around code.
All that said, I do believe understanding the perspective of the authors will help me be a better reviewer. I now see practices such as small stories, focused commits, and using linters in a new light because they aid reviews. I appreciate that awareness.
February 20, 2017
It has some interesting quantification of the hunch that code review saves time and money. But I realized that I didn't want to read a 160 page book about peer code review.
February 7, 2009
Jason Cohen, The Best Kept Secrets of Peer Code Review (Smart Bear Software, 2006)
Despite having been in IT for some fifteen years now, I must admit I'd never heard of peer code review before Smart Bear Software's book landed on my doorstep. I have to say it's a pretty darned good idea, though, from what I've read of it here. I'm not entirely sold on the book itself, but I like the idea it's touting, which is basically this: two (or more) sets of eyes on a given piece of code are better than one.
As for the book, it's pretty obviously another marketing tool for Smart Bear's code review tool, which makes me like it less than I otherwise would, probably. However, if you're a complete novice who's just being introduced to the idea, there's a good bit of valuable information here; it's worth reading as an overview of peer code review. Obviously not a general-audience book, but if you're in IT, check it out. ***
Despite having been in IT for some fifteen years now, I must admit I'd never heard of peer code review before Smart Bear Software's book landed on my doorstep. I have to say it's a pretty darned good idea, though, from what I've read of it here. I'm not entirely sold on the book itself, but I like the idea it's touting, which is basically this: two (or more) sets of eyes on a given piece of code are better than one.
As for the book, it's pretty obviously another marketing tool for Smart Bear's code review tool, which makes me like it less than I otherwise would, probably. However, if you're a complete novice who's just being introduced to the idea, there's a good bit of valuable information here; it's worth reading as an overview of peer code review. Obviously not a general-audience book, but if you're in IT, check it out. ***
February 1, 2016
A good reading to introduce the concept of code review to both managers and developers themselves. The advice are practical enough to improve your current review workflow if you have one, be it through the checklist method, the mesurements or the social managing of egos.
The problem with this book lies more in its size. While it is easy to read, it repeats itself over the different parts - though making them independant. Dilution of such an important subject might be harmful, but hey, 160 pages is still a quick read.
The problem with this book lies more in its size. While it is easy to read, it repeats itself over the different parts - though making them independant. Dilution of such an important subject might be harmful, but hey, 160 pages is still a quick read.
February 22, 2009
This was an interesting look at peer reviews with from my experience most software engineers seem to drudge and avoid. This book made several points that I plan to incorporate in my team's next peer review. I feel that this may help change the dynamics of the review and improve my team's outlook on this important subject.
January 3, 2013
Decently interesting, given the subject matter, but it still felt at times like I was sloshing my way through it. The book focused on small-scale peer code review, with the ultimate aim of getting people to buy Smart Bear's product. The product does look interesting, and I wouldn't mind adopting some of these practices at work.
August 21, 2008
One of the better, smaller books on code reviews. Read this and you will want to ALWAYS use code reviews in your work.
November 4, 2009
Terrible. Barely passable as a collection of anecdotes. Contained almost no useful advice or research.
January 13, 2010
Interesting and useful; very light treatment of pairing and agile development, but great and detailed information about code reviews aimed at PSP/TSP developers.
November 30, 2011
If you want to implement a peer review process in your organization I recommend this book for any stakeholder involved in the process : from manager to developers."
May 31, 2013
Inspiring, I will write a blog post about code review.
May 27, 2015
There are some helpful ideas but it's also a sales pitch for Collaborator.
June 24, 2014
Has few interesting ideas for code reviews but has too much repetition. Also it shows that this is sponsored by one specific company manufacturing code review tool.
June 6, 2015
Repetitive, but worth reading. Some key takeaways even for people already committed to code reviews.
July 8, 2018
This book is a bit dated as code review has become common practice in software engineering. However, as an engineering manager trying to make code review better, the essays provide the concrete evidence and metrics to support the best practices in code review. Since code review has become common practice, the principles and goals behind it aren't often evaluated. There are many digressions and repeated points, but I found it to be a good meditation for me to think hard about code review.
Read
April 17, 2019This is a collection of essays about peer review of software code. While presented in a logical order, this doesn't flow like a book, which is a pity, and about half the authors work for a company that makes a code review tool. They avoid turning the book into an ad for their product, though the final chapter (on how to use a code review tool, using their tool as a handy-dandy example) feels a bit like an infomercial.
However, much of the book is focused on both defending code review as a practice, providing "ammunition" for those seeking to implement it in their own teams, and on practical advice for implementing various types of code reviews. It's legitimately a useful book on its subject.
However, much of the book is focused on both defending code review as a practice, providing "ammunition" for those seeking to implement it in their own teams, and on practical advice for implementing various types of code reviews. It's legitimately a useful book on its subject.
Displaying 1 - 23 of 23 reviews