Advertisement

Refactoring in a Team

Bill Venners: In a team, different people have different tastes. A friend of mine worked at a company where a new guy joined the group, and he had particular ideas of what makes a good name. He liked to put m_ in front of member names, underscores between each word, and so on. He made some simple refactorings like the kind you recommend, but those refactorings caused some problems.

For example, some of the company's code was secret because of licensing restrictions, so legally the new guy couldn't access it. He ended up breaking that code, and my friend had to fix it. His refactorings also caused problems when my friend needed to fix bugs in multiple branches of the source code that represented different releases. Different branches now contained different names, so it was harder to fix the bugs in multiple releases. Also, people who had been there a while, like my friend, were used to the old names. At one point my friend couldn't find a method she was looking for because it had been renamed. The new guy's refactorings caused those kinds of problems.

Who in a team decides what's a good name? Who decides when and how to refactor?

Martin Fowler: Refactoring doesn't mean you pathologically rename a bunch of things just because you think it's good. You refactor if there's some benefit. If you're renaming, you look at some method that perhaps doesn't convey what it's supposed to do and the people who work on it prefer to call it something else. As far as naming conventions, the team must come up with the naming conventions they want to work with. You must be aware of that if you come in from the outside. If I came in as a consultant, I wouldn't impose my particular code conventions. I'd ask the team what its conventions are, review them, and use those. On the other hand, I would oppose a method called x374, because it doesn't convey the meaning.

As far as breaking a piece of secret code—that tells me their testing wasn't strong enough. Testing is a very important underpinning to refactoring.