Re: Refactoring

[chromatic]

The most important part of this is testing. Test, test, test.

If you don't know what your code is supposed to do, if you can't verify that it does what it's supposed to do, you can't ever refactor it. That's a problem.

A normal programming language gives you different ways to solve the same problem. Perl gives you more. If you've done a reasonably good job of encapsulation, you can often tweak things to improve them.

You won't be free to do this until you have external verification that the code you modified has the same (good) effect that it did before.

Refactoring is good. Refactoring without testing is nearly impossible.

Update: Okay, okay. Confident refactoring without testing is difficult. Avoid it if you can.

[dws]

Refactoring is good. Refactoring without testing is nearly impossible.

That's a bit strong. While cleaning up or migrating legacy code, I've done a lot of refactoring without having a solid base of unit tests. It can be done, but it's tough on the psyche.

I think a more accurate statement is:

It is difficult to refactor with confidence without having a complete set of regressions tests that cover the code you're refactoring.

In fact, having adopted the "write your tests first" dictum from eXtreme Programming, I'm finding it uncomfortable to do any development without having a set of regression tests at hand. An infectious notion, that.