http://blog.salsitasoft.com/practical-lessons-in-peer-code-review/
Consequences of bad reviews
- Not having time to deal with your review backlog.
- Delaying a release because your reviews aren't done yet.
- Posting reviews that are no longer relevant since the code has changed so much in the meantime.
- Doing poor reviews since you have to rush through them at the last minute.
Ideas
>> something around 25% of the original development time should be spent on code reviews.
>>understand how the code fits into the larger context of the application, component or library it is part of. If you don't grasp all the implications of every line of code, then your reviews are not going to be very valuable.
>> empty their review backlog every day.
Fix One Area At A Time
>> If my colleague spends a week adding code willy-nilly across a large project then the patch they post is going to be really hard to review.
>> creating reviewable code is to annotate your code reviews.
>> Commit third-party code separately
When doing large refactorings,
>> refactor code incrementally. Figure out a partial change of reasonable scope that results in a working code base and brings you in the direction you want to go.
Comments