The whole Refactoring/VB.NET debate
Refactoring? What’s that? Wow, what do you know, you can find out the answer by going to the Refactoring Home Page; however, to summarize:
Refactoring is a technique to restructure code in a disciplined way. For a long time it was a piece of programmer lore, done with varying degrees of discipline by experienced developers, but not passed on in a coherent way. In July 1999 Addison-Wesley published my book describing Refactoring. The book describes the refactoring process, together with a catalog of refactorings. Since that book refactoring has played an increasingly visible role in software development. There is more written about it and since the beginning of 2001 we’ve seen a lot of development of a new breed of refactoring tools, which I believe will make a huge impact to the work of software development.
Paul Vick was kind enough to points out that VB.NET will have some refactoring support in the next release. How much or how little will be determined by several factors (time to market and user feedback are a couple of examples). He even lists out several areas that refactoring tools are able to accomplish and asks the community to leave feedback as to what features do developers consider a priority for getting into the next release (along with the reasoning why a developer considers this feature a necessity - ie. “C# does it“ isn’t enough of a reason). His post has generated a large amount of responses.
Another thing he points out is that it might not be called ‘Refactoring’. Some reasoning behind this is that VB.NET developers may not know what refactoring is and may just skip over the menu item. Personally, I don’t care what it is called. I’d like to see it (whatever it’s name is) there purely from the standpoint that anything that can save me some time and brain power… I’m all for it. Now, bear in mind, ‘Refactoring’ has been around for a very long time. It’s only until recently (2001’ish) that there was a term for it. Technically, ‘Find and Replace’ is a rudimentary form of refactoring.
Now, here’s where I do draw the line. Just because it might be called something else in VB.NET… does not mean that VB.NET is being “dumbed down” as several people have expressed concern over. What I find most interesting is that ‘Refactoring’ is something that occurs more often because you didn’t do a well thought out design in the first place… something that most VB.NET developers are accused of very often. Now wait a minute, I thought that all C/Java developers designed their applications prior to actually developing them… therefore, what is the critical need for refactoring? If it’s so perfect the first time; what’s there to refactor? ;-) OK, I know I’m being a bit cynical here, but the point is that refactoring tools are designed to allow the developer to make project wide changes to the code (basically, ‘find and replace’ with some intelligence).
I agree with G. Andrew Duthie when he states that it doesn’t really matter what language you are using, we are all .NET developers. However, I somewhat disagree with him concerning the languages need to be consistent with each other. If they were, what would be the point of having different languages. Each language is designed to offer various benefits that the others do not offer. This is true whether your talking about VB.NET, C#, C++, J#, Cobol, Fortran, whatever. As long as the language allows me to take full advantage of the underlying framework (including interop functions); I’m fine with however each language decides to implement this access. This is where I believe the consistency should be and I think that Microsoft has the same view.
Whatever it’s called in the end and to whatever degree the tools are implemented, whatever improves my speed to delivering product… I’m all for.