In a typical code review process, the author makes some code changes/additions/deletions, and request one or more reviewers to review and approve the code (by giving it a LGTM) before it is committed into the team's repository.
A well-designed code review process can have the following benefits:
Check code correctness: The earlier bugs are caught, the less resources wasted in debugging, testing and performing regressions.
Ensure comprehension of code: An unbiased review of the code ensures that future developers can understand the code changes.
Enforces consistency across the codebase: In a large organization, someone else from a different team may have to depend on the new code eventually. It is therefore important to maintain consistency and readability across the organization.
Brings psychological and cultural benefits: Code review reminds the author that the code is not theirs, but it belongs to the collective team. A code review is a professional way of giving feedback and criticism, as the reviewer critiques the code, not the author. It also gives developers with impostor syndrome some validation and recognition when their code is approved.
Enables knowledge sharing: Both the author and the reviewer can learn something from the code review session. It is one of the few opportunities for 2 or more developers to exchange ideas and feedback.
Provides a historical record of the code review itself: A code review will be a good form of artefact for future readers of the code to understand why certain code changing decisions were made.
Best practices of code review:
Be polite and professional: As long as the author's implementation is correct and understandable, the reviewer should not insist on alternatives. Avoid jumping to conclusions that the code is wrong without asking the author about his decision process. Give prompt reviews and avoid piecemeal reviews (giving reviews on the same code change over a long time). Authors should be professional and address each comment made (even if it does not result in code change).
Write small changes: Keeps the code review process fast and easy to digest. Typically only one reviewer is needed if the change is small.
Write Good Change Descriptions: Indicate a summary of the change in the title, and a short and detailed bullet list of changes. Implementation details can be documented in the code itself.
Keep reviewers to a minimum: The most important LGTM is the first one. Beyond that, there are diminishing returns. Even if there are multiple reviewers, each of them should review a different aspect of the change.
Automate Where Possible: If it is possible to automate, do so to reduce burden on developers. For example, an automated static code analyzer can analyze code for mistakes before it is sent to review.
Types of code review:
Greenfield/new features: Most important to review. Ensure code is really needed to solve a problem and not an alternative to a good library built by others. Do not debate the design decisions done in the past, but make sure code matches the agreed design and specifications. Also, it is possible to introduce Continuous Integration here.
Behavioral Changes, Improvements, and Optimizations: Same guidelines as greenfield review. Any behavioral changes should be followed by changes to tests to match the new API behavior. CI tests should be run to ensure nothing else breaks. Optimizations could necessitate some performance and benchmark tests.
Bug Fixes and Rollbacks: Only address the bugs in the issue/ticket. Often, new tests have to be added or existing tests updated. Rollbacks should also be reviewed, since other services may already depend on the new buggy code. That is why small changes are preferred.
Refactorings and Large-Scale Changes: In Google, large scale changes are usually done by machines. If the changes bring a high risk, many individual engineers may be asked to review their individual sections.
Summary of summary:
Check for correctness, readability and comprehension of code in code review
Make small changes and keep the code review simple and fast
Book: SE@Google Chapter: Code Review
Summary: