Notes on best practices. This is a work in progress and suggested guide lines, not a rulebook to follow like slaves.
Code Reviews
Let's do code reviews for all code changes.
- When possible, let's try to keep them small -> more review requests, less files to review per request.
- Don't spend too much time on each review -> the main purpose of our code reviews is communication (not finding bugs).
- Assign each code review to one person in particular and expect a response from them. CC as many other people as you like (to keep folks in the loop) but those folks do not need to respond.
Regarding rigor, I don't expect the reviewer to scrutinize the code (the burden is on me to test it) but instead to:
- get the gist of what I'm trying to do or let me know if its confusing (because I haven't done a decent job if the code change is confusing)
- let me know whether the approach I've taken seems reasonable or if there is a better way to do it
- give me a clue if the way I am testing it is missing major important cases
- point out any dependencies of which I might be unaware (e.g., if I change the REST API in a particular way, who might that change impactand is that okay?)