Tech Off Thread

5 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

A New Age "Old" Debate E&C vs Refactoring

Back to Forum: Tech Off
  • User profile image

    OK, so I've read the reasons "why" all over the place and  I still don't like them but the fact remains the Refactoring was chosen over Edit & Continue as a feature in Whidbey for C#.

    Maybe because I don't fully understand what Refactoring is, being a VB6/C# guy, I don't get how its going to make me more productive than E&C.  Seems to me that "fix as you go" is more productive than "variable scramble". 

    Seems to me E&C would be see more action than Refactoring since you often have to fix errors in your code but I can't see the benefit of having the option of renaming objects/variables on a whim.  Maybe someone can enlighten me on why I should care about Refactoring.

    and countless others....

  • User profile image

    Entire books have been written on the subject by very smart people, but let me tell you why I think refactoring is a great feature to add.

    There are many unknowns in software projects. Even the smallest piece of software, once it gets into the hands of users, is going to produce some unforseeable requests for changes or new features. And work on an existing project is never a straight road to deployment. Requirements change or become better understood, databases change, new class libraries are released, new developers are hired.

    The truly paranoid will keep the value of PI inside a configuration file ... just in case.

    The point is, with all this change going on outside the software, the software has to change too. Even a solo developer writing software is going to discover a better way to implement a method, or realize a piece of code inside of one method is suddenly needed in two places. It happens all the time.

    It's risky to change a working design. It's risky to change working code. Having refactoring and test driven development tools reduce the risk. 

  • User profile image

    I'm confident that I'll be using the refactoring features far more frequently that Edit and Continue, simply because it'll increase the speed at which I can write code. Even better, I'll be able to eliminate a number of stupid small bugs whilst doing it!

  • User profile image

    I think the root cause of many bugs is a design that has become too brittle (or was brittle in the first place) - the symptom of the design's deterioration is generally more bugs appearing, because the whole thing becomes more difficult to maintain, etc.

    So, E & C emphasises fixing the symptoms, rather than trying to fix the root cause, as refactoring claims to be able to do, or at least help with.

    So, in terms of productivity, refactoring should enable the whole thing to be maintained easier, and this should lead to less bugs, so less need for 'edit and continue', and therefore greater productivity.

    With 'edit and continue', you'd continually be patching up holes in the boat - you might do that more efficiently, but it would still be patching.

    I think thats what the refactoring guys would say anyway, and I tend to agree with them.


  • User profile image

    I think your perspective on this depends on what sort of developer you are.

    If you're working on a lot of new code, or if you're rearchitecting some piece of an application, refactoring is great.  You see some duplicated code somewhere, and want to create a new function and call it from both those places - that's refactoring, and the tools can make that job easier.

    If you're working on existing legacy code and especially if you're a maintenance guy, Edit and Continue is a great way to be able to do things in the code without having to kill the whole process (or set of processes), compile, and start over.  Edit and Continue is a debugging tool, Refactoring is a development tool.

    I've heard arguments that Edit and Continue is bad; most of those same arguments would apply to the statement that source level debugging is bad.  It's a tool, and if developers find the tool useful (as I do), then it needs no other justification.

    One of my favourite tools in the Visual Studio IDE is the ability to grab the program counter (the yellow arrow) and move it while you're debugging.  I know it's dangerous, and it scares me to think about what's going on on the stack behind the scenes, but when I've just had my application call a function, and the function has failed, it lets me back up one and this time, step into it and see why it's failing.  Sure there are situations where this won't work, but for the places it does work, it's a huge time saver.  Same with Edit and Continue.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.