Question 1
Within a large organization, I've heard that it's a best practice to limit code reviews to just a few developers that are actively working on a code base. What is your process for conducting code reviews in this setting?
Question 2
What about getting a fresh set of eyes on the code base? Do you actively try to assign reviews to those who aren't involved in the day-to-day development of the code base (or even unfamiliar altogether with the code base)?
Would love to hear your thoughts on the above!
Top comments (1)
This is what worked for us:
Simple features or quick fixes: It is just a pull request, and there has to be another person in the same team that takes a look at the diff and approved the pull request.
Complex features or fixes that spans multiple repos, the a quick meeting with at least 2 other people. Simply walk through the code and talk about key decisions made and why (of course, some are in the comments).