The other day I wrote about effective code reviews. Once problem I’ve seen with check in reviews are that once the review take place it is common that one or two days of work have been put into the change so any comments on how the design of the code can be changed are typically too late once we reach a check in review. A bad design is usually changed but an OK design is rarely changed into a great design basically since the design is OK so both reviewer and author does not feel it is worth another day just to improve the design. So check in reviews are not the silver bullet for better designs. You have to do something else too.
On our team we have design reviews. A design review is something each developer calls out (just like a check in review is called out) and then the developer goes over a proposed design or a few test cases with another developer before he starts implementing things in code. These design reviews have proved to be valuable and has resulted in less design comments during check in reviews.
As of yet we have not tried pair programming which would replace both the design reviews and the check in reviews in a natural way.