Yes. I think that instead of saying "Stop thinking!", this might inspire us to respond with a more positive tone, like "Great idea! Let's write it down on this list, and get back to it when we've finished this sequence of moves." IE: Finish one thing before going off on some tangent.
Fully agree and actually had a similar experience some years ago. We were faced with a larger piece of code, which was starting to become a big ball of mud not with no clear separation of concerns. We started by defining new boundaries for these concerns and in a first step just moving the respective pieces of code to these new contexts, without too much thinking. After that we had least had separated the code according to the different domains. Only then did we start to explore and think about how to couple them, which was the much harder part. But at least we could base the decisions then on a much clearer picture.
I appreciate your advice around structural vs behavioral changes too. It's stuck with me for awhile and trying to keep them separate. Thanks for all your learnings :)
Yes. I think that instead of saying "Stop thinking!", this might inspire us to respond with a more positive tone, like "Great idea! Let's write it down on this list, and get back to it when we've finished this sequence of moves." IE: Finish one thing before going off on some tangent.
("Squirrel!!!)
While reading your post, a mental image of Breadth-First Traversal came to my mind. Thanks for the index card tip!
Fully agree and actually had a similar experience some years ago. We were faced with a larger piece of code, which was starting to become a big ball of mud not with no clear separation of concerns. We started by defining new boundaries for these concerns and in a first step just moving the respective pieces of code to these new contexts, without too much thinking. After that we had least had separated the code according to the different domains. Only then did we start to explore and think about how to couple them, which was the much harder part. But at least we could base the decisions then on a much clearer picture.
Great post on refactoring well, Kent.
Loved the in-depth example and the thought process every step of the way
Even when the principles can be stated simply, there is still tons of technique that goes into mastering refactoring.
Agreed.
I appreciate your advice around structural vs behavioral changes too. It's stuck with me for awhile and trying to keep them separate. Thanks for all your learnings :)