thing_14
Code Reviews
https://97-things-every-x-should-know.gitbooks.io/97-things-every-programmer-should-know/content/en/thing_14/
You should do code reviews. Why? Because they increase code quality and reduce defect rate. But not necessarily for the reasons you might think.
Because they may previously have had some bad experiences with reviews, many programmers tend to dislike code reviews. I have seen organizations that require that all code pass a formal review before being deployed to production. Often it is the architect or a lead developer doing this review, a practice that can be described as architect reviews everything. This is stated in their software development process manual, so therefore the programmers must comply. There may be some organizations that need such a rigid and formal process, but most do not. In most organizations such an approach is counterproductive. Reviewees can feel like they are being judged by a parole board. Reviewers need both the time to read the code and the time to keep up to date with all the details of the system. The reviewers can rapidly become the bottleneck in this process, and the process soon degenerates.
Instead of simply correcting mistakes in code, the purpose of code reviews should be to share knowledge and establish common coding guidelines. Sharing your code with other programmers enables collective code ownership. Let a random team member walk through the code with the rest of the team. Instead of looking for errors you should review the code by trying to learn it and understand it.
Be gentle during code reviews. Ensure that comments are constructive, not caustic. Introduce different review roles for the review meeting, to avoid having organizational seniority among team members affect the code review. Examples of roles could include having one reviewer focus on documentation, another on exceptions, and a third to look at the functionality. This approach helps to spread the review burden across the team members.
Have a regular code review day each week. Spend a couple of hours in a review meeting. Rotate the reviewee every meeting in a simple round-robin pattern. Remember to switch roles among team members every review meeting too. Involve newbies in code reviews. They may be inexperienced, but their fresh university knowledge can provide a different perspective. Involve experts for their experience and knowledge. They will identify error-prone code faster and with more accuracy. Code reviews will flow more easily if the team has coding conventions that are checked by tools. That way, code formatting will never be discussed during the code review meeting.
Making code reviews fun is perhaps the most important contributor to success. Reviews are about the people reviewing. If the review meeting is painful or dull it will be hard to motivate anyone. Make it an informal code review whose prime purpose is sharing knowledge between team members. Leave sarcastic comments outside and bring a cake or brown bag lunch instead.
您应该进行代码评审。为什么？因为它们提高了代码质量并降低了缺陷率。但不一定是因为你可能认为的原因。
因为他们以前可能有过一些不好的评论经历，所以许多程序员往往不喜欢代码评论。我见过一些组织要求所有代码在部署到生产环境之前通过正式审查。通常是架构师或主要开发人员进行审查，这种做法可以被描述为架构师审查一切。这在他们的软件开发过程手册中有规定，因此程序员必须遵守。可能有些组织需要这样一个严格而正式的流程，但大多数组织并不需要。在大多数组织中，这种做法适得其反。被审查者可能会觉得自己受到了假释委员会的审判。审查人员既需要时间阅读代码，也需要时间了解系统的所有细节。评审人员可能会迅速成为这个过程中的瓶颈，而且这个过程很快就会退化。代码评审的目的不应该只是简单地纠正代码中的错误，而应该是共享知识并建立通用的编码准则。与其他程序员共享您的代码可以实现集体代码所有权。让一个随机的团队成员与团队其他成员一起遍历代码。与其寻找错误，不如通过尝试学习和理解代码来检查代码。在代码审查过程中要温和。确保评论是建设性的，而不是刻薄的。在评审会议中引入不同的评审角色，以避免团队成员中的组织资历影响代码评审。角色的例子可能包括让一个评审员专注于文档，另一个关注异常，第三个关注功能。这种方法有助于将审查负担分散到团队成员中。每周有一个定期的代码审查日。花几个小时参加评审会议。每次会议以简单的循环模式轮换被评审人。记住，每次评审会议都要在团队成员之间切换角色。让新手参与代码评审。他们可能缺乏经验，但他们新鲜的大学知识可以提供不同的视角。让专家参与他们的经验和知识。他们将更快、更准确地识别容易出错的代码。如果团队有通过工具检查的编码约定，那么代码评审将更容易进行。这样，在代码评审会议期间就永远不会讨论代码格式了。让代码评审变得有趣也许是成功的最重要因素。评论是关于评论的人。如果评审会议很痛苦或沉闷，那么很难激励任何人。让它成为一个非正式的代码评审，其主要目的是在团队成员之间共享知识。在外面留下讽刺的评论，带上蛋糕或棕色袋子的午餐。作者：Mattias Karlsson