Timeline for What do you do when code review is just too hard?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 6, 2016 at 12:30 | comment | added | Jonathan Hartley | Agreed absolutely with both guillaume31 & gnasher729 above. | |
| Jul 5, 2016 at 23:04 | comment | added | gnasher729 | @JonathanHartley: In that case, the (minus first) reason for a code review is to make developers write code that they are not ashamed to show to someone else in a code review :-) | |
| Jul 1, 2016 at 17:05 | comment | added | guillaume31 | It can certainly play that role too, but I've found pair programming to be more efficient than CRs for onboarding and early to mid term education of new team members. Think about a coach that sits besides you all along an exercise vs a teacher that only does post facto evaluation. Having your "finished" work corrected by someone is more frustrating and less educative than work done collaboratively with someone, in my experience. | |
| Jul 1, 2016 at 16:03 | comment | added | Jonathan Hartley | Agreed, but: Code reviews actually have a 0th purpose, which is even more important than code readability, maintainability, etc. They are for educating the team on what the team's standards are. Even if no edits were performed as a result of code review, they would still have fulfilled 75% of their purpose, because the review would educate the code author to avoid making those same type of mistakes again, repeatedly, throughout the lengthy future lifetime of this project, and the next... | |
| Jun 29, 2016 at 8:45 | history | answered | guillaume31 | CC BY-SA 3.0 |