David Clyde

This process works beautifully well: https://chromium.googlesource.com/chromium/src/+/master/docs/code_reviews.md#OWNERS-files … but you need reviews hooked unconditionally into your process. Github added their own version https://github.blog/2017-07-06-introducing-code-owners/ … Still figuring out how much can be applied to smaller teams.

You shouldn't be checking in code that *wasn't* reviewed anyways on large teams. If you are working on a small project sure (like.. <4 people), but too many things can break on large projects.

Best not to make this process optional; needs to be process-enforced and submits should not go live until LGTM, with a raft of local presubmit tests. It's a constant fight between project velocity and stability.

Counter point: We don't do any reviews and don't have more problems than other code bases I worked on. Would slow us down tremendously.

How senior is your team?

I won't name names but I once worked on a large well known game where code reviews were completely optional, and not even heavily encouraged. Totally worked fine. Not sure where I personally stand on the issue but I'm pretty ok with working in either environment.

I suspect that's most games. Would be amazing to gather a state of the industry. However, worth noting that code reviews can be about a lot more than perceived gate-keeping. One big benefit is the rapid spread of knowledge as people feel empowered to dig into other areas.

There is nothing stopping people from using them to spread information and a safety net without them being required in all situations. Programmers should be trained to know when they need help and when they don’t and make it safe to ask for it either in communication or review.