This is a nicely written article with a lot of valuable, spot-on guidance.

I suggest generalizing the notion of "code review" to include peer reviews of any artifact that people develop for a software project that has the potential of containing errors: requirements, designs, tests, help screens, even documentation. The highest quality leverage comes from detecting errors in requirements, before they get turned into the wrong code.

People often don't consider that technical peer reviews like these are interpersonal interactions as well as technical activities. Because human beings with their egos, attitudes, and sensitivities are involved, it's important to be thoughtful and considerate even in how one provides feedback to the author of the work being reviewed.

I've written extensively on this topic, Including my book "Peer Reviews in Software." The following articles might be helpful as well:

"The Soft Side of Peer Reviews," https://medium.com/swlh/the-soft-side-of-peer-reviews-ced46d6d63ee

"Making Peer Reviews Work for You," https://medium.com/analysts-corner/making-peer-reviews-work-for-you-4a63533e0ab6

"The Seven Deadly Sins of Software Reviews," https://medium.com/swlh/the-seven-deadly-sins-of-software-reviews-b7180f86d365

"Requirements Review Challenges," https://medium.com/analysts-corner/requirements-review-challenges-e3ffe3ad60ef