Hacker News Reader

Comment by lamontcg | Hacker News Reader

I just got done staring at some code written by a prolific upper quadrant coder, that I'm going to have to noodle on and figure out how to disentangle some bad design decisions. I might be able to do a fairly short commit to refactor and extend, in which case my metrics will be crap. I might wind up looking at all the outstanding issues with this codebase and rewrite every class in this directory (in which case my LoC metrics will improve dramatically). Right now I'm probably one of those "stuck" coders that need "help". Kinda? But most software developers hit problems like this and run away in terror, and looking around me IDK who can really help me that much, I'll run my ideas by some colleagues, but the other ones who work on problems this gnarly are also neck deep in their own issues...

View on HN

Mikado Method might offer you some clues, or at least confirm some of your existing habits.

Basically, start a top-down refactor. When you find the bottom you stop, revert your code, and refactor from the bottom up.

You probably won't find the actual bottom, but in my experience the moment when I was about to give up and call it quits was usually just before I reached the bottom. Taking a break, and starting over from the spot where I stopped, usually the solution became obvious, and far less invasive than I expected.

Do I understand this correctly:

You start refactoring at a high level -- essentially set out to rewrite the whole chunk of code in which your refactoring work lies. And focus on the most important until you get to the inner-most structure.

Then when you are to the "sum(a,b)" level you start over with the original code base and refactor bottom up. With the knowledge of how it works all the way up to the top? Re-creating your original refactorings?

It seems interesting. Like tackling a math problem or puzzle from two directions. Are there certain situations in which it is most effective? Architectures? Paradigms?

Most refactoring is from the bottom up. Make the change easy, then make the easy change. I said "start a top down refactor" but redesigning from the top or all at once isn't really refactoring. Some of the actions look similar but you get few of the benefits of refactoring.

When the architecture problem has gotten away from you, or only becomes apparent late in the project, it's hard to see the trees for the forest. The only way to decompose the problem is to start somewhere and see what happens. With a top down rewrite the number of bits in flux becomes overwhelming, which is the anxiety I picked up from the previous commenter.

Mikado is just an exploratory development trick to help you find a way to make the change with refactoring. You try rewriting pieces until the number of concerns starts to multiply, you keep going essentially until your brain starts telling you, "this is nuts, you should stop", and you take that detail that broke the camel's back and do just that part, and build up and out from there.

Sounds like "Discovery" quadrant more than "Prolific" to me.

Reply on news.ycombinator.com