Code reviews are a big part of writing software, especially when working within a team. It is important to have an agreed-upon etiquette for reviewing code within a team. A code review is a critique and a critique can often feel more personal than the code writing itself. A sloppy, under-researched, or insensitive code critique can cause difficulties between team members, reduce overall team productivity, and diminish code quality over time. This post will briefly define code reviews, describe some common mistakes, and provide some quick tips for improving a code review process.<\/p>\n
<\/p>\n
Code reviews are the process of sharing code so that other engineers can review it. Code reviews can happen verbally during pair programming<\/a> sessions, or through reviewing code on websites like CodePen<\/a> and GitHub<\/a>. Mainly, code reviews happen in tools like GitHub when engineers submit pull requests<\/a>. <\/p>\n Critiques are hugely beneficial. Convening engineers to discussions about code ensure that they’re on the same page, regardless of whether it’s in person or by sharing comments. Also, a review can help catch small mistakes in code or comments\u2014like spelling and it can help newer or more junior coders learn the codebase. When done well, regular code reviews have nothing but benefits for all involved. <\/p>\n A common goal for code reviews is to make code changes as minimal and clear as possible so that the reviewer can easily understand what has changed and what is happening in the code. If code reviews are smaller, they’re more frequent \u2014 potentially several a day \u2014 and more manageable. <\/p>\n Reviewing code should be a part of every developer’s workflow. Senior reviewers are given the opportunity to teach\/mentor, and even learn something new from time to time. Junior reviewers can grow and often help ensure code readability through the questions they ask. In fact, junior engineers are usually the best team members to ensure code readability. <\/p>\n For an engineer who works alone, asking for feedback from outsiders \u2014 at meet-ups, GitHub, Open Source Slack Channels, Reddit, Twitter, etc \u2014 can allow the solo coder the opportunity to participate in a code review process. <\/p>\n If we could all agree on an established process and language for reviewing code, then maintaining a positive environment for creative and productive engineering is easier. A code review etiquette benefits everyone \u2014 whether working alone or within a team.<\/p>\n Seeing bugs and issues continue to roll in and being mentally unable to address them has led to feelings of failure and depression. When looking at the moment project, I could only see the negatives. The bugs and misnomers and mistakes I had made. It led to a cycle of being too depressed to contribute, which led to being depressed because I wasn’t contributing.<\/p>\n – Tim Wood<\/a>, creator of Momentjs<\/p>\n<\/blockquote>\n There are many online comments, posts, and tweets by prolific engineers expressing that their feelings have been hurt by code reviews. This doesn’t directly mean that reviewers are trying to be mean. Feeling defensive is a normal, quite human<\/em> reaction to a critique or feedback. A reviewer should be aware of how the pitch, tone, or sentiment of their comments could be interpreted but the reviewee \u2014 see Occam’s Razor<\/a>. <\/p>\n It's like these commenters don't consider maintainers to be people, we make mistakes. https:\/\/t.co\/tBa8kzymU4<\/a><\/p>\n — Henry Zhu @SF (@left_pad) September 18, 2017<\/a><\/p><\/blockquote>\nHarsh code reviews can hurt feelings<\/h3>\n
\n
\n