Choosing Refactoring Targets

[ Team LiB ]

Choosing Refactoring Targets When you encounter a large system that is poorly factored, where do you start? In the XP community, the answer tends to be either one of these: Just start anywhere, because it all has to be refactored. Start wherever it is hurting. I'll refactor what I need to in order to get my specific task done. I don't hold with either of these. The first is impractical except in a few projects staffed entirely with top programmers. The second tends to pick around the edges, treating symptoms and ignoring root causes, shying away from the worst tangles. Eventually the code becomes harder and harder to refactor. So, if you can't do it all, and you can't be pain-driven, what do you do? In a pain-driven refactoring, you look to see if the root involves the CORE DOMAIN or the relationship of the CORE to a supporting element. If it does, you bite the bullet and fix that first. When you have the luxury of refactoring freely, you focus first on better factoring of the CORE DOMAIN, on improving the segregation of the CORE, and on purifying supporting subdomains to be GENERIC. This is how to get the most bang for your refactoring buck.

[ Team LiB ]