til / strong code-review culture
Code reviews are more about transferring knowledge inside a team and coming up with alternate solutions than finding bugs in the code. A strong code review culture will give us better code and better developers.
The why is more important than the how. Take the time to write a thorough PR description that explains the code change. Include documentation and links if they are relevant. You might not stay at the company forever and if you leave the context of the PR leaves with you. If you do stick around, your future self will thank you.
Written communication can often be perceived as negative. Review what you’ve written before publishing. Try to read it as the one who will receive the text, and try to make it feel as positive as possible. Use the Socratic method.
The PR is a discussion. Don’t tell the author to do something, ask them about it.
Extract this to a service → What do you think about extracting this to a service?
Conflicts will arise and are not necessarily a bad thing. If we don’t agree, be open to discussing the issues and the process.
What to review #
- Think about naming.
Naming is hard. Renaming is harder. Spend the time up front. — @laurieontech
- Review the complexity and make suggestions for possible improvements.
- Tests and test coverage. 100% coverage isn’t absolutely necessary, but make sure that we’ve added tests for the most crucial paths.
- Updates relevant documentation.
Styling is important, but it shouldn’t be a manual step. Solve it using automation. Use Rubocop, ESLint, Prettier etc.