Lessons from refactoring

I enjoy the process of refactoring software — especially software that was written by other people. It forces me to understand things inside and out (which is a tough point to arrive at when all you do on that code is the occasional drive-by bug fix). On top of that, since the desired functionality is known already, it's all redesigning of the data model and writing code. There are fewer product-level questions that come up. The specification is pretty much set.

For this particular project, though, I have the unique challenge of making the new design pass muster with multiple parties. People are picky and they always have something to say, so I took special care this time to anticipate any objections and address them so they'd get a better sense of my thought process. I've still had to make changes — and I make them gladly — but I've found that having to explain each decision I'm making generally serves to clarify my thought process.

It certainly helps to have some time to think hard about these changes, too. It's a healthy thing to let a data model sit for a bit and soak into the minds of all stakeholders while their input is incorporated. It also helps when people are interested enough to give detailed and insightful feedback. Sure, it generally doesn't hurt to have more sets of eyes looking at a plan, but having a team of people analyzing it harnesses collective historical memory — great for backward compatibility — and makes the plan more bulletproof by ensuring that it addresses concerns from many points of view.

Popular posts from this blog

Arrays in Visual Basic and classic ASP

JavaScript: Checking for undeclared and undefined variables

A fix for LaTeX "Missing $ inserted." console message