I am not a developer, but an agile coach. So my answer comes from that perspective.
There is a logical way to think about your question that should answer it, without needing a development background. I hope you will humor me.
Typically, we see a developer work on a piece of functionality, let's say it's in Java, and he or she writes the code and tests (unit, perhaps TDD) and validates that the code works and meets the requirements (or acceptance criteria).
At that point, another developer, commonly more senior, performs a code review.
At this time, the analysis is on Structural Quality and is enforced or validated via the code review. The review looks for numerous deviations from code standards, or even "transcendental" perspectives on code quality, which is hard to define and gets a bit "artsy".
The developers agree on changes to be made to improve the code based on these considerations, they are done, the developer again runs his test and validates that the changes that resulted from code review didn't break the functionality.
At this point, Functional Quality of the code is validated through QA and UAT.
If you change the order, and have QA and UAT spend their time on testing, and then perform code review and make changes to the code, wouldn't you need to have QA and UAT yet again validate that everything meets their specs?
You could take a short cut and assume nothing changed, but if you ever broke something you didn't detect in your tests, it could be a big problem. And if you ask them to repeat their testing again, that's highly inefficient and would not be appreciated.
So no, I have never seen any of my teams do it that way, and I've been working with at least a dozen or two agile teams for 8 years.