[ukoms]

In company I work, we've developed through years quite complex code review. First of all - we're programming in Perl 5.21 and because of this we made coding standards to ensure people will code in simmilar manner. Second - we have mailing list where summary of all commits is send - code, reason, project description etc. Every developer is allowed to read those commits and if he find anything suspicious - he can rand code check (or wtf) message and authour of questioned code has to respond (either by correcting his code or explaining why he did what he did). Third - we do partial reviews during project. Whenever sprint is finished - there goes minireview. Fourth - after project is finished - there is inner team project code review, where developers take step back and look themselves on their and theirs teammates code. Fifth - when inner-team review is finished and all issues are fixed - there is outer-team review. Senior Engineer or Software Architect is appointed to overview whole code, but at this point any developer from any team is allowed to join outer-team review.

Leading reviewer after finishing his work decide about eventual after-fix review (if something was really messed up despite all precautions).

And - just for sure - before releasing code to production releasing architect take quick eye look on git diff. If nothing sting him on his eye - code is like Dobby - free!