October 16, 2019•411 words
Code reviews are super important for keeping track of changes, learning from team members and improving the quality of your code base. They take a lot of effort and can sometimes be hard to get right. I have compiled a list of things I like to keep in mind when prepping my code for review or doing a review of other's work.
Some things to keep in mind when getting your code ready for review by others:
- Review your code with a fresh set of eyes before assigning some one else. I struggle to do this one sometimes but it's a great thing to do to respect your teammate's time and help you catch things too.
- Make sure to let your reviewer know expectations of what kind of feedback you need. If it's just a draft and you want feedback on approach it will be different than a final review before shipping.
- Try to keep your changes small and atomic. Sometimes this can not be helped but when this happens try to chunk the review into pieces. I try to create commit chains that can be stepped through.
- Separate the code that you wrote from your ego as much as possible. This is hard to do and most people struggle to do this completely but it's important that you realize getting feedback should not reflect on you as an individual entirely.
Things to think about when reviewing:
- Do not nitpick. Try to recognize when things are personal design opinions versus actual issues. If there are small stylistic suggestions, make clear that it is that and not an actual problem. I like to preface comments like these with
- Take your time. To do a good review it might take some digging and work on your end. I sometimes end up digging into documentation, sample code libraries and more before giving advice.
- Do not dismiss choices or make vague suggestions, instead be clear with the problem you see and try to make strides to fix the issue with an alternative name, library or example code.
- Be careful to balance your remarks with calling out things you like too. Remember there is a person on the other end with feelings.
Obviously these are not exhaustive lists, there a lot more things to consider but these are some of the big things I try to keep in mind when reviewing or publishing code to be reviewed.