News
Does Microsoft Understand Refactoring?
Microsoft is bringing refactoring support to Visual Studio .NET with the next
release (code-named "Whidbey"). Well, sort of. At the PDC this year, they
demonstrated some refactoring support in C#. Right-clicking in C# code gives you
a Refactor shortcut menu item with choices including Extract Method, Encapsulate
Field, Extract Interface, Surround With, Insert Expansion, Rename, and Change
Method Signature. "Insert Expansion" puts in code blocks for things like
property definitions or For Each loops, while "Surround With" can stack
if/then/else, try/catch, and other constructs around the selected code.
There's no refactoring support in VB .NET in the PDC build of "Whidbey."
But Paul Vick, Technical Lead on the VB .NET team, has indicated in his weblog that VB will be getting at
least some of these capabilities. They won't be grouped under the name of
refactoring, though. Vick points out that even many experienced and intelligent
developers haven't run across the term "refactoring," and suggests that it would
be better not to make people deal with the term to use the features.
Visual C++ doesn't appear to have refactoring support in the PDC build of
"Whidbey" either. I haven't seen any statement from Microsoft about whether it's
coming or not, so I'll focus on the VB .NET and C# support here. That support
gives me concern on several levels.
First, I really don't understand the decision to avoid the term "refactoring"
in VB .NET. Sure, there will be some (even many) VB developers who haven't run
across the term before. But is that any reason to protect them from it now?
Suppose the same thinking had been in place when object-oriented programming
started to creep into VB 4? "Oh, let's not call them classes; VB developers
don't have time to figure that term out. Let's call them boxes instead." Imagine
the difficulty that VB developers would have had in communicating with the rest
of the development world.
I think the way that classes were introduced into VB provides a pretty good
example of how refactoring could be introduced: don't try to hide or rename the
concept. Instead, use the same term as the rest of the industry and provide help
content to make it understandable by VB developers who haven't run across it
before. We know that the VB help team can do a good job when they're given the
resources; I have no doubt that they could produce a great guide to refactoring,
when to use it, its pitfalls, and the joys of test-driven development.
I've got a different concern with the C# implementation of refactoring: that
menu item includes a bunch of things that are not refactorings. The term was
defined quite precisely by Martin Fowler
in his book Refactoring: Improving the Design of Existing Code
(Addison-Wesley, 1999):
"Refactoring is the process of changing a software system in such a way that
it does not alter the external behavior of the code yet improves its internal
structure. It is a disciplined way to clean up code that minimizes the chances
of introducing bugs."
Here's my problem: the "Insert Expansion" and "Surround With"
pseudo-refactorings are practically guaranteed to change the external behavior
of the code. Refactoring, as practiced developers who embrace test-driven
development, involves making changes to code that don't affect its ability to
pass the current set of unit tests. Refactoring is a disciplined process, not a
code-name for "fast ways to write more code." By including non-refactorings on
the Refactoring menu, Microsoft is inevitably going to dilute the term and
destroy its precision.
So, for one group of developers, Microsoft is going to pretend the term
"refactoring" doesn't even exist. For another, it's going to use a well-defined
term in an ill-defined way. Both of these moves will make it hard for
Microsoft-oriented developers to talk to developers in the rest of the industry
about refactoring. Java developers using IntelliJ IDEA, for example,
benefit from a huge catalog of actual refactorings integrated into their IDE.
Microsoft could do worse than to copy that implementation.
Finally, although it makes sense to me that the two languages should be
different, I am dismayed to see the IDE support continuing to diverge for VB
.NET and C# developers. Microsoft apparently feels that C# developers want one
thing from their IDE, and VB .NET developers want another. I can't be the only
developer who moves back and forth, can I? After watching Microsoft invest
immense resources in moving all of their development tools into the same IDE
over the past several years, it's perplexing to see them allowing that IDE to
immediately devolve into separate tools for separate languages.
Of course, there are undoubtedly people working at Microsoft who understand
refactoring thoroughly and deeply. It's not like there's an official Microsoft
stance on the topic of refactoring. But it bothers me to see the Visual Studio
.NET team, and its client language teams, adding such confusing and watered-down
support for what could be a major productivity and code quality improvement if
it were done right.