# Code Review

* Software is written by human beings. So it is often riddled with mistakes.
* But what isn’t so obvious is **why software developers often rely on manual or automated testing** to vet their code.
* Code review gives a **fresh set of eyes to identify bugs** and simple coding errors before your code goes to the next phase.

## How code review works?
* A code review involves **one or more developers examining source code they didn't write** and providing feedback to the authors, both negative and positive.
* Ideally the reviewers are completely disengaged from the project they are reviewing as this maximizes objectivity and ensures the code is readable and maintainable even by those not already well-versed in that project.

## When should code review happen?
* When a feature is completed, its author creates a Pull Request, which is a situation when some changes are requested to be merged to the main branch.
* The Pull Request will be assigned to a reviewer and the process starts.

## Benefits
1. Defect-free, well-documented software.
1. Software that complies with coding standards.
1. Teaching and sharing knowledge between developers.

## Best practices
* All code had to be reviewed before it was checked into the version control software.
* Verify that the defects are actually fixed.
* Use **checklists**
* A checklist will remind authors and reviewers to confirm that all errors are handled

## Resolving Conflicts
* In any conflict on a code review, the first step should always be for the developer and reviewer to **try to come to consensus**.
* When coming to consensus becomes especially difficult, it can help to have a **face-to-face meeting** or a video conference between the reviewer and the author, instead of just trying to resolve the conflict through code review comments.
* If that doesn’t resolve the situation, the most common way to resolve it would be to **escalate it to a technical lead**.

## What to look for in a code review?
In doing a code review, reviewer should make sure that:

* The code is well-designed.
* The functionality is good for the users of the code.
* Any UI changes are sensible and look good.
* Any parallel programming is done safely.
* The code isn’t more complex than it needs to be.
* The developer isn’t implementing things they might need in the future but don’t know they need now.
* Code has appropriate unit tests.
* Tests are well-designed.
* The developer used clear names for everything.
* Comments are clear and useful, and mostly explain why instead of what.
* Code is appropriately documented.
* The code conforms to our style guides.

## Rules For the Author
For the author, it’s important to have an open and humble mindset about the feedback they will receive.

* The **first reviewer of your code is you**.
* Before you perform that first push of your new branch, read through the entire diff.
* Does it make sense?
* Did you include something unrelated to the overall purpose of the changes?
* **Did you forget to remove any debugging code?**
* Try keeping the changes in the code review request smaller, as review of larger changes becomes difficult.
* If possible, break a larger review request into multiple smaller ones.
* Try giving a clear and a **proper description** for the review request.
* Short summary of what is being done in the PR.
* Try to **respond to every comment**.
* **Be humble!**
* Mind that everybody’s code can be improved.
* You are not perfect.
* Accept that you will make mistakes.
* No matter how you good you are, you can still learn and improve.
* Don’t infer your professionalism and reliability as a software developer from infallibility and flawlessness.
* **You are not your code**
* Programming is just a skill. It improves with training – and this never stops.
* Don’t connect your self-worth with the code you are writing.
* Mind that finally, the reviewer wants the same as you: **Creating high-quality software**. You are on the same side.
* Mind the IKEA effect. **You might place a too high value on your own code**.
* Consider feedback as a valuable **new perspective** on your code
* It reveals your implicit knowledge that is not expressed in the code yet because it appears natural for you.
* It avoids a tunnel vision.
* Code reviews are a valuable source of **best practices** and experiences
* Code reviews are a **discussion, not a dictation**. It’s fine to disagree, but you have to elaborate your reservations politely and be willing to make compromises.

## Rules For the Reviewer
For the reviewer, it’s important to pay attention to the way they formulate the feedback. This is extremely crucial for your feedback to be accepted.

* Try to **understand the author’s perspective**.
* Review fewer than **200–400 lines of code** at a time.
* Aim for an inspection rate of fewer than 300–500 LOC per hour.
* Take enough time for a proper, slow review, but **not more than 60–90 minutes**.
* Use **I-messages**:
* Right: “It’s hard for me to grasp what’s going on in this code.”
* Wrong: “You are writing cryptic code.”
* **Talk about the code**, not the coder.
* Right: “This code is requesting the service multiple times, which is inefficient.”
* Wrong: “You’re requesting the service multiple times, which is inefficient.”
* **Ask questions** instead of making statements.
* Right: “What do you think about the name ‘userId’ for this variable?”
* Wrong: “This variable should have the name ‘userId’.”
* Always **refer to the behavior**, not the attributes of the author.
* Right: “I believe that you should pay more attention to writing tests.”
* Wrong: “You are sloppy when it comes to writing tests.”
* Accept that there are **different solutions**
* Right: “I would do it in another way, but your solution is also fine.”
* Wrong: “I always do it this way and you should too.”
* Distinguish between common best practices and your personal taste.
* Mind that your criticism may just reflect your personal taste and not an objectively wrong code.
* Make compromises and be pragmatic.
* Don’t jump in front of every train
* Don’t be a pedant. **Don’t criticize every single line** in the code. This will annoy the author and reduce their openness to further feedback.
* Focus on the flaws and code smells that are most important to you.
* **Respect and trust** the author
* Nobody writes bad code on purpose.
* The author wrote the code to the best of their knowledge and belief.
* Mind the **OIR-Rule** of giving feedback
* Observation - “This method has 100 lines.”
* Impact - “This makes it hard for me to grasp the essential logic of this method.”
* Request - “I suggest extracting the low-level-details into subroutines and give them expressive names.”
* Before giving feedback, ask yourself:
* Is it true? (opinion != truth)
* **Is it necessary?** (avoid nagging, unnecessary comments and out-of-scope work)
* Is it kind? (no shaming)
* **Be humble!** You are not perfect and you can also improve.
* It’s fine to say: **Everything is good!**
* Don’t forget to **praise**.

### References
* https://phauer.com/2018/code-review-guidelines/
* https://google.github.io/eng-practices/review/reviewer/