This is something I saw Kent do and have since copied myself (when I can). When someone asked Kent to look at something he would sit with them and look at the code. When he had a comment they would refactor the code there and then to put the change into place.

Apart from the immediate feedback, the thing I find valuable about this is that once you have done a few refactorings you start to see things you would have never seen before. This is because you are ''seeing'' what the code looks like rather than imagining what it might look like. Often these second order observations are much more important than the first round. I do code reviews this way (when I can) because I want to gain these second order insights.

There are people issues here. Many would not feel comfortable about changing code there and then. A way to handle this is to ensure you have a copy of the pre-review code handy. Do the refactorings, and then the reviewer walks away. The reviewed person can then choose to accept or reject changes freely.

--MartinFowler

Very interesting Martin! Certain aspects of this sound somewhat similar to
a WritersWorkshop (Im thinking in particular of the "accept or reject changes freely"). --BradAppleton

I do this a lot, and it works great.  A good way to learn how some code works
is to play with it, and refactoring is a concrete thing you can do to it.

--RalphJohnson

I've gotten to the point where I can't just ''read'' code,
I have to ''edit'' it. (OK, I can read up to 30 lines, but not much more.) --KielHodges

----
CategoryRefactoring