...
If it isn't tested, it doesn't work. Period. All new features require appropriate unit tests and integration tests as part of the development process. Passing tests should be checked in the same time as new code, and are fully in the scope of code reviews.
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?)
...