I'd recommend doing code reviews more often than monthly. If you do them monthly you really have to review everything that has been produced in a month in one go, which will take a long time. Long tasks which require lots of concentration tend to be done quite sloppily cos people get tired. And you have to review everything in one go, cos if not it could be many months between something being written and reviewed.

Better in my opinion to have weekly reviews, where one particular chunk of functionality is reviewed. In a team of four or five developers, this means that everyone has their code reviewed roughly monthly, and doing it so regularly makes it easier to get into the habit of doing them.

Not sure how to cope with resistance from the team. Frankly, people who aren't willing to have their code reviewed are people I wouldn't want to work with anyway. Cos if they don't want their code reviewed, presumably they don't want anyone else to maintain their code either, which is just stupid.

When I wrote our code review guidelines, I made it clear that code review is not meant to be competitive; it's not about finding fault with each other. It's about learning good techniques from each other and about helping each other. Perhaps you can break the ice by volunteering to be the first one have your code go under the microscope.