> am I the only one who sometimes finds refactored code harder to understand or change? No, you aren't the only one. I made a similar case in a related discuss

> am I the only one who sometimes finds refactored code harder to understand or change? No, you aren't the only one. I made a similar case in a related discussion a few months ago: http://news.ycombinator.com/item?id=1224210 http://news.ycombinator.com/item?id=1224210 http://news.ycombinator.com/item?id=1224206 http://news.ycombinator.com/item?id=1224206 This particular tutorial seems to have some merit, but it's a bit too clever for its own good at times. For example, the very first change introduces a named constant called SIGHT_SHOT_RADIUS_PX, which is not in fact used as a radius at all. Indeed, if it were, the later refactoring to split out a testForHits operation that in turn uses testForXAxisHit and testForYAxisHit would break down, because while testing for hits is a useful atomic operation, the tests on the two axes would not be independent and the logic in those functions is meaningless out of context. No unit test is going to warn you about traps like these, and breaking things down according to dogmatic rules rather than to separate meaningful, self-contained concepts does tend to create such problems IME.