Refactoring Reveals Truths
The refactoring process helps eliminate these potential bugs and expose these enhancements by iteratively driving the complex towards the simple. Reducing the algorithm down to its barest form also helps you see how it’s similar to other algorithms in your code base. These are all second-order effects, to be sure, but second-order effects pay off.
[…]
The algorithm has revealed its beautiful internal symmetry now. Very clear intent, very clear algorithm, and each component is simple. It’s now more obvious how to tweak and modify this algorithm.
3 Comments RSS · Twitter
I don't get where "if let view = theirSuperviews.first(where: mySuperviews.contains) { return view }" comes from. It's not in the original code, then its added in, and then removed as being superfluous.
Which perhaps explains why I try not to refactor my code until it becomes clearly necessary.
@Peter I noticed that, too. Sadun’s original Objective-C version doesn’t have that, either. However, I still think the main point of the post is sound.
@Peter The question is why have 2 checks instead of just 1, right? In the process he describes, there were 2 checks for the "direct ancestry" step, and I think that's why he initially kept 2 checks when he combined them with the indirect ancestry check. I can see how one might start by doing checks both ways, as the direct ancestry checks was requiring that, before realizing the second one is in fact superfluous once you include all the views in the arrays. I do think it speaks for the process of simplifying an algorithm, where it can take a few 'duh' moments before one realizes all the edge cases can actually fit into the general case with no or minor modifications.
> I try not to refactor my code until it becomes clearly necessary.
I think he makes a good point about why a refactor is a good idea in this case: the initial code is full of edge cases and is complex, so I would not be confident it's bug-free.
