We'll need to refactor this later



  • You work for a software company. During the course of enhancing an existing product, you find you need to use/reference/copy and paste code which resembles a bucketful of shit. You ask about that, and hear the reply: "ah, we know about that. Yep, shit it is. We hadn't much time when we knocked that code together, but we surely are planning to refactor this code, meanwhile we need to use it."

    Now please raise hands if, during your stay with that product, you have actually got to ever refactor that code.

    Me, I don't remember this happening in my lifetime. Success stories, anyone?



  • No, you're right. If they don't do it right the first time, it'll never be refactored later on.

    BUT! If you're in a software company that even realizes it should be refactored, you're probably in the top 50%. I'm not exaggerating.


  • ♿ (Parody)

    I have seen it, but mostly it's been me who's done the refactoring, and generally just under the cover of fixing something or other without mentioning the R word.



  •  "when we get the time, we can pull into a layby and fix this deflated tyre. In the meantime, we don't have time to fix it, let's just limp along at a much slower speed..."

    Sadly, short-termism often trumps longer-term savings and efficiency.

    nb: doesn't Agile embrace the idea of "refactoring later" if you come to create something new and realise you've already done something similar before, thus taking the opportunity to refactor and template both existing and new code?



  • I am an independent developer. I am considered very efficient, and the main reason is that I re-use my old code extensively. When I start on a new project, half the code is already written, copied from some previous site.

    That said, I admit that very often the old code is "crappy". What I do is copy and edit, not just to adapt to the new site, but also to improve the code. But I do not touch the old site at that time.

    Once the new code in the new package is working reliably, then I can back-port some or all of my changes to the old site. But I am careful not to break the old site. An improvement that will take an hour to back-port gets done; an improvement that will take a week gets postponed indefinitely.

    Of course, being independent, I don't neet my boss' permission to do this. I'm just being careful.



  • @boomzilla said:

    I have seen it, but mostly it's been me who's done the refactoring, and generally just under the cover of fixing something or other without mentioning the R word.

    Same here.



  • I've just got into a project where a critical part of the application is executed like this: the PHP code calls a Perl script, which then runs another PHP file. I've questioned the original developer (which happens to be my boss) why oh why they'd do something like that. His answer was that they were still learning back then (and apparently this was supposed to be efficient)... Sigh.

    Oh by the way, they already rewrote the whole application once, two years ago. This is "version 2". I wonder what the "version 1" code was like (I'd look up on the repository but guess what? They didn't used version control back then!)...



  • @blakeyrat said:

    No, you're right. If they don't do it right the first time, it'll never be refactored later on.

    But no company ever does it right the first time, so basically you're saying all code in production is bad? I wouldn't disagree.



  • @The_Assimilator said:

    @blakeyrat said:
    No, you're right. If they don't do it right the first time, it'll never be refactored later on.

    But no company ever does it right the first time, so basically you're saying all code in production is bad? I wouldn't disagree.

     

    But there is a difference in bad, badder, baddest and baddistic.



  • Had this conversation with lead developer the other week. I put down some refactoring work as chargeable on my timesheet and he said "We don't charge clients for refactoring".

    A discussion ensued, and he said that the reason we don't charge them for it is that the time we spend on it is avoidable - it is self-inflicted wastage of time, due to "getting the code wrong" that we "should have gotten right in the first place".

    Given that we have clients who drip-feed us requirements over a period of months, I fail to see how exactly we are supposed to know what is right in the first place when we don't even know how the code we are writing at that time is going to be used a few months down the line.

    So yeah, I just do and say I didn't. And still waiting to view the consistent perfection that is his code :)


  • Trolleybus Mechanic

    @LegacyCrono said:

    they already rewrote the whole application once, two years ago. This is "version 2". I wonder what the "version 1" code was like
     

    If it's anything like my experience, Version 2 is exactly like Version 1, but with different graphics.

    There's this system I'm working on now. The tabbed menus are a horrific kludge of insane. The entire menu is one .gif, with one highlighted tab, depending on the page. This means for 20 tabs, there's 20 different gifs. To add a 21st tab, you need to Photoshop a new image, plus change 20 other images to include this tab, and then rewrite the area map used for navigation. But that's the simple part.

    Navigating between the tabs uses an area map, with each area firing off a javascript function. The function (different on every page) kludges up the form's fields, then submits the form to a processing page. The processing page then evaluates the Request.Form("xxx") variables and the page it came from, and saves the form to the database.  This way if a user goes from, say, Address to Personal, all the Address form information is saved.

    Of course, it doesn't work in anything but IE, you can't use any .Net controls due to the direct access of Request.Form, all the save logic is hidden on a second page, etc, etc.

    When I questioned the-- wisdom-- of this design, another developer explained it was created about 7 years ago. It was during their transition from "classic" ASP to .Net. They really didn't understand how .Net worked, and this was the best solution they had. It isn't the best, but it works well enough, and isn't worth refactoring.

    Okay, fine. I can buy that. Except for the brand new subsystem that got build only months ago. It also has a tabbed menu interface. So, did they take what they had learned about .Net and create a quick, eifficent tabbed interface that uses postbacks and redirects to accomplish the same thing?

    Nope. The developer just copy and pasted the code, changed the form fields, created 10 new .gif images, rewrote the processing page to handle all the new forms, and now we have a 2004-era mistake masquerading as a 2011 "new idea" development.

    So yes, you should refactor bad code that's "working but we won't ever touch again", because someone is going to reuse it.

    Sidenote: How did I find out about just how deep the mess is? Client wants to put a .Net-based 3rd party control one on of those pages...



  •  @shimon said:

    Me, I don't remember this happening in my lifetime. Success stories, anyone?

    Yeah here! *holds up his hand*

     

    Know how it happened? I just did it. I refactored it. No requirement, no way to book my hours, no discussion, no approval. I just did it. And the result? As if by magic I got a post under which I could book hours, people were interested in the results and when I first presented it all, people started to pick up on it and offer more improvements. Read: improvements, not ideas on how to do it differently. They took what I did and went with it.

    Now if I actually had offered this as an idea, the whole deal would have been buried under endless discussions about implementation and necessity; put a group of 10 devs in a room and you end up with 10 opinions and 10 ways to implement something. But because I was just bold to go ahead and do it, it got done and in stead of repremanding me because I did something without approval, I got a raise. This is mostly because I did one thing I normally wouldn't do: I created a phantom case around the whole thing. A fake customer, fake partners, fake requirements but all still realistic to the point that someone could actually knock on the door and demand what I conjured up myself. And around that I did the refactoring, proving it through a "proof of value" application which I can now not only use to demonstrate the work that I've done, but it also acts as documentation, a training tool and the application is hooked into the release management cycle of that thing I refactored. You make changes to the core, you make changes to the proof of value application to prove that your change works. Plus you can easily demonstrate it again.

    It took a leap of faith, but boy did it feel like a win afterwards.

     



  • @erikal said:

    I just did it.
     

    Exactly. If you build it they will come, but you have to fucking build it.

    @erikal said:

    put a group of 10 devs in a room and you end up with 10 opinions and 10 ways to implement something.

    This happens all  the time. Large brainstorm sessions are death for creativity. People should work alone on these things.

     


  • Trolleybus Mechanic

    @erikal said:

    This is mostly because I did one thing I normally wouldn't do: I created a phantom case around the whole thing. A fake customer, fake partners, fake requirements but all still realistic to the point that someone could actually knock on the door and demand what I conjured up myself. And around that I did the refactoring, proving it through a "proof of value" application which I can now not only use to demonstrate the work that I've done, but it also acts as documentation, a training tool and the application is hooked into the release management cycle of that thing I refactored.
     

    Cool, though one critical point is that you didn't just refactor, you introduced a new feature and refactor at the same time.

    A pure "refactor" doesn't change any functionality.

    That being said, I think your way is the way to do it. Okay, maybe not the fake customer, etc-- but if you're going to be in there changing functionality, you might as well to some refactoring at the same time. 



  • @Lorne Kates said:

    If it's anything like my experience, Version 2 is exactly like Version 1, but with different graphics.

    There's this system I'm working on now. The tabbed menus are a horrific kludge of insane. The entire menu is one .gif, with one highlighted tab, depending on the page. This means for 20 tabs, there's 20 different gifs. To add a 21st tab, you need to Photoshop a new image, plus change 20 other images to include this tab, and then rewrite the area map used for navigation. But that's the simple part.

    I'm not sure if I should puke of cry. 

    @Lorne Kates said:

    Client wants to put a .Net-based 3rd party control one on of those pages...
    HA HA!



  • @shimon said:

    Me, I don't remember this happening in my lifetime. Success stories, anyone?

     

     I did it, but always on my own initiative because fuck this shit i won't work with such code knowing i can fix it in a reasonnable amount of time,  and in a small pirate ship kind of company.

    as soon as any kind of management is involved, no, refactoring never happens.

     



  • @Lorne Kates said:

    So yes, you should refactor bad code that's "working but we won't ever touch again", because someone is going to reuse it.

    Sidenote: How did I find out about just how deep the mess is? Client wants to put a .Net-based 3rd party control one on of those pages...

    So you continue to get paid for very long time.


  • Trolleybus Mechanic

    @C-Octothorpe said:

    I'm not sure if I should puke of cry.
     

    I cried, but the tears were made of stomach bile and blood.



  • @Lorne Kates said:

    @C-Octothorpe said:

    I'm not sure if I should puke of cry.
     

    I cried, but the tears were made of stomach bile and blood.

    I think you're doing it wrong...


  • @Lorne Kates said:

    @C-Octothorpe said:

    I'm not sure if I should puke of cry.
     

    I cried, but the tears were made of stomach bile and blood.

    Thank you for posting that right at lunch time.



  • @Lorne Kates said:

    Cool, though one critical point is that you didn't just refactor, you introduced a new feature and refactor at the same time.

    A pure "refactor" doesn't change any functionality.

     

    Yeah I'm difficult like that; I don't take terms too literally. I know what the wikipedia has to say on the topic, but I just don't agree with it :) To me a refactor equals an overhaul of code which may or may not change external behavior. I mean how often can you actually refactor something without breaking any external interface at all? Even unit tests apply.

     



  • @erikal said:

    I mean how often can you actually refactor something without breaking any external interface at all? Even unit tests apply.

    Uh... I do it all the time.

  • ♿ (Parody)

    @Sutherlands said:

    @erikal said:
    I mean how often can you actually refactor something without breaking any external interface at all? Even unit tests apply.

    Uh... I do it all the time.

    Yes, 100% agree. Sometimes it's super simple, like breaking up a method that's grown too long. That's typically the most common pure refactoring I ever do. It's more common that refactoring gets mixed in with fixing some bug or removing performance bottlenecks. But that doesn't mean that the interface into that functionality changed.

    If it does, the refactoring is probably happening because I wanted to change the interface in the first place, and the innards were just too awful / inflexible to reasonably make the changes.



  • @Sutherlands said:

    @erikal said:

    I mean how often can you actually refactor something without breaking any external interface at all? Even unit tests apply.

    Uh... I do it all the time.
     

    If refactoring breaks the external interface (including unit tests) then you're doing it wrong - the unit tests are there to verify that a refactoring [i]didn't[/i] break anything.

    Because refactoring pretty much has to be slipped in under management radar, it usually occurs in association with externally-visible changes.

    There may be refactoring [i]involved[/i], in order to get the codebase into a shape where a required change can be made without requiring additional goats' blood, but it doesn't [i]cause[/i] the change.

     



  • My biggest problem in life right now is not writing proper code, it is that I tend to fail at explaining myself properly. You are all correct and I value your opinions, I'll leave the discussion at that now. Perhaps in time, I'll be able to defend my own opinion with acceptable arguments. Turning 30 I started to open my eyes and my mind to the possibility that there is something beyond code; it will probably take me another decade to recover from the shock.


  • ♿ (Parody)

    @erikal said:

    You are all correct and I value your opinions, I'll leave the discussion at that now.

    Are you sure you're at the right forum?



  • @erikal said:

    Turning 30 I started to open my eyes and my mind to the possibility that there is something beyond code; it will probably take me another decade to recover from the shock.
     

    That happens to everybody turning 30, snowflake.



  • @erikal said:

    My biggest problem in life right now is not writing proper code, it is that I tend to fail at explaining myself properly.

    You know your boss, who's a giant blowhard? Who doesn't know shit and is completely incompetent?

    He's making more money than you because he realizes communication is everything. Everything. The sooner you learn this lesson, the better.



  • @erikal said:

    My biggest problem in life right now is not writing proper code

    If that's your biggest problem, perhaps software development isn't for you...



  • @boomzilla said:

    @Sutherlands said:
    @erikal said:
    I mean how often can you actually refactor something without breaking any external interface at all? Even unit tests apply.

    Uh... I do it all the time.

    Yes, 100% agree. Sometimes it's super simple, like breaking up a method that's grown too long. That's typically the most common pure refactoring I ever do. It's more common that refactoring gets mixed in with fixing some bug or removing performance bottlenecks. But that doesn't mean that the interface into that functionality changed.

    If it does, the refactoring is probably happening because I wanted to change the interface in the first place, and the innards were just too awful / inflexible to reasonably make the changes.

     Of course, this should be done in two distinct steps. I am a strong belieer in Red/Green refactoring. I also review code changes to make sure that the changes to the codebase are those that are *required* to accomplish the specific task. In general "drive by" coding (including refactoring when it is not a requirement of the specific task) is a leading source of software problems.



  • What is red/green refactoring?



  • @shimon said:

    You work for a software company. During the course of enhancing an existing product, you find you need to use/reference/copy and paste code which resembles a bucketful of shit. You ask about that, and hear the reply: "ah, we know about that. Yep, shit it is. We hadn't much time when we knocked that code together, but we surely are planning to refactor this code, meanwhile we need to use it."

    Now please raise hands if, during your stay with that product, you have actually got to ever refactor that code.

    Me, I don't remember this happening in my lifetime. Success stories, anyone?

    @blakeyrat said:

    No, you're right. If they don't do it right the first time, it'll never be refactored later on.

    BUT! If you're in a software company that even realizes it should be refactored, you're probably in the top 50%. I'm not exaggerating.

    we realize all the time and also tell our project manager, but he is more focus on money aspect
    thus giving all indian coders a bad name. just as there is concept of technical debt, there is also concept of golden goose.

    basic thing about golden goose is the antediluvian concept that once project is in production,
    the more bad the code, the more time of resource will require to fix it. thus ensure of decent money supply for long period of time.

    So all refactoring suggestions are only made note of in minute of meeting at defect prevention mtgs. then manager secretly laughing at idiot who make this suggestions.


  • ♿ (Parody)

    @TheCPUWizard said:

    @boomzilla said:
    If it does, the refactoring is probably happening because I wanted to change the interface in the first place, and the innards were just too awful / inflexible to reasonably make the changes.

    Of course, this should be done in two distinct steps. I am a strong belieer in Red/Green refactoring. I also review code changes to make sure that the changes to the codebase are those that are required to accomplish the specific task. In general "drive by" coding (including refactoring when it is not a requirement of the specific task) is a leading source of software problems.

    In theory, I agree with you, and I try to do it that way. In practice, theory gets thrown under the bus.



  • @boomzilla said:

    In theory, I agree with you, and I try to do it that way. In practice, theory gets thrown under the bus.

    How much (upper limit at least) gets "thrown under the bus" is [IMHO] the choice of the individual. Sometimes not an easy choice.



  • @Sutherlands said:

    What is red/green refactoring?

    It's not a type of refactoring but a method of writing code in general.
    It's the basis of test-driven development.

    The first stage of any bit of code-writing in TDD is to think about what you want the code to do and express that by writing a unit test. Of course the test will fail because you haven't written the code yet - but you still have to run it and check that it fails, because if it passes you know that the test is useless / incorrectly written. That is the red stage (red = fail)


    The next stage (green) is to write whatever rough, shit, crazy code is necessary to make the test pass.


    After that, you refactor. The important thing here is that refactoring is not an optional extra; it's an integral part of the process. The stage where you write whatever you can to pass the test is just that - a stage. One out of three. This can cause conflict with traditional-type project managers who think that refactoring is unnecessary.



  • @token_woman said:

    @Sutherlands said:

    What is red/green refactoring?

    It's not a type of refactoring but a method of writing code in general.
    It's the basis of test-driven development.

    The first stage of any bit of code-writing in TDD is to think about what you want the code to do and express that by writing a unit test. Of course the test will fail because you haven't written the code yet - but you still have to run it and check that it fails, because if it passes you know that the test is useless / incorrectly written. That is the red stage (red = fail)


    The next stage (green) is to write whatever rough, shit, crazy code is necessary to make the test pass.


    After that, you refactor. The important thing here is that refactoring is not an optional extra; it's an integral part of the process. The stage where you write whatever you can to pass the test is just that - a stage. One out of three. This can cause conflict with traditional-type project managers who think that refactoring is unnecessary.

    Sutherlands - thanks for posting the explaination. While I do agree with the above, there are also some additional items that are included in many methodologies....

      1) During refactoring, the only thing you are doing is refactoring. There are no changes to functionallity (this means no changes to tests).
      2) During the "Red" phase, there is no refactoring (ie changes to make the structure of the code better), every change is specific to the functionallity (ie the test) being worked on.

    Where things get "interesting" is when a change to code structure will impact the interface (and therefore the tests), but is being done for a non-functional reason. To a purist, this is not re-factoring it is a design change. This matches well with mathematics, where refactoring an equation is the re-organization of terms such that the equaion is identical  (A+1)(B+2)  becoming (AB + B + 2A + 2). There is no functional change (ok, on a math processor there may be, but I am talkng theory here) and the inputs and outputs both stay the same.  On the otherhand, if it is later found that B is always equal to 2A, then a change to either (A+1)(2A+2) or (2A^2+4A +2) is a change to the actual formula, and not a refactoring of that specific formula



  • @TheCPUWizard said:

    @token_woman said:
    @Sutherlands said:

    What is red/green refactoring?

    It's not a type of refactoring but a method of writing code in general.
    It's the basis of test-driven development.

    The first stage of any bit of code-writing in TDD is to think about what you want the code to do and express that by writing a unit test. Of course the test will fail because you haven't written the code yet - but you still have to run it and check that it fails, because if it passes you know that the test is useless / incorrectly written. That is the red stage (red = fail)


    The next stage (green) is to write whatever rough, shit, crazy code is necessary to make the test pass.


    After that, you refactor. The important thing here is that refactoring is not an optional extra; it's an integral part of the process. The stage where you write whatever you can to pass the test is just that - a stage. One out of three. This can cause conflict with traditional-type project managers who think that refactoring is unnecessary.

    Sutherlands - thanks for posting the explaination.

    +1, thanks Sutherlands! Credit where credit's due!



  • @token_woman said:

    +1, thanks Sutherlands! Credit where credit's due!

    Make that 2.

    I knew about the "it should fail first time around, else you fail at constructing a decent test" but I didn't know about the red/green terminology.

    I also wasn't aware about "hack it now, refactor later" in TDD. It makes sense, I guess - get it working, icing on the cake later.

    Apart from the red/green bit, are these stages in the overall TDD process given specific terms? Something to identify which phase you're in? 



  • @TheCPUWizard said:

    Sutherlands - thanks for posting the explaination.
     

    You made a mistake there.

     

     

     

     

    It's "explanation".



  • Thanks for all the praise for my TDD explanation.

    When CPUWizard attibuted it to Sutherlands instead of me, I thought this was kind of funny since my user name is what it is. So I posted a sarcastic comment pointing it out. Obviously a bit too dry and sarcastic (even given the tag about boobs, which I thought made it obvious). Sorry for any confusion.
    @Cassidy said:

    It makes sense, I guess - get it working, icing on the cake later

    The point is that in TDD refactoring is absolutely NOT "the icing on the cake". To see why not, look at this example (pseudocode):


    I want to write a function that adds 3 to a number. So I make a test


    sometest() {

    assert(addthree(4)==7);

    }


    Then I hack together the function to pass the test:


    addthree(integer input){

    return 7;

    }


    We have green. But wait what? Our function is useless and does not express adding 3 at all whatsoever.


    This next bit is the magical bit. What we do is REFACTOR. What does that mean? Above all else, it means REMOVE DUPLICATION. Well, where is the duplcation? The answer is that the number 7 is duplcated by appearing in both the tests and the code. The same piece of information is present in both. This is what people find hard to get about TDD, me included until I read Kent Beck and felt the lightbulb go on. You don't just refactor the code separately, but you refactor across the combination of code and tests.


    Giving, of course


    addthree(integer input){

    return input +3;

    }


    Some icing, huh?


    As for the names of the stages, there's no particular convention apart from the above-mentioned red-green-refactor.



  • ... should have said "too sarcastic, etc ... for everyone but dhromed, who appears to be awake" cheers dude :)



  • @token_woman said:

    Sorry for any confusion.

    Nah, it was just subtle... give them time, they'll catch up!

    @token_woman said:

    The point is that in TDD refactoring is absolutely NOT "the icing on the cake"....

    ...Some icing, huh?

    Okay... I was probably using the wrong terminology there. I didn't refer to icing in the sense of gold-plating software, more in the sense of that the task works (the tests pass) but the total work isn't considered finished. I know people often refer to frivilous additions as "just icing on the cake", but I use the expression during discussions about exit criteria and defining success (different to results).

    So.. you're right: it IS some icing, some pretty big and important icing - don't DARE deliver the cake without it. Next time I'll hunt down a more appropriate expression. My bad!

    @token_woman said:

    As for the names of the stages, there's no particular convention apart from the above-mentioned red-green-refactor.

    Okay. Cheers, Sunderlands - some useful information there.



  • @token_woman said:

    ... should have said "too sarcastic, etc ... for everyone but dhromed, who appears to be awake" cheers dude :)
    My humble apologies for not properly crediting you with the post.  Unfortunately I was in a rush, and credited the person who Asked the question, rather than the person who answered it. <blush>



  • @TheCPUWizard said:

    @token_woman said:
    ... should have said "too sarcastic, etc ... for everyone but dhromed, who appears to be awake" cheers dude :)
    My humble apologies for not properly crediting you with the post.  Unfortunately I was in a rush, and credited the person who *Asked* the question, rather than the person who answered it. <blush>
    Just like a woman... someone thanks me for something, and they have to rush to make themselves look good.



  • @token_woman said:

    We have green. But wait what? Our function is useless and does not express adding 3 at all whatsoever.

    This next bit is the magical bit. What we do is REFACTOR.

    To be pedantic, I think what drives changing the 'addthree' function from returning 7 is another test (e.g. assert(addthree(5)==8); would fail), not refactoring. Refactoring would be to remove any cruft in the function. Probably none would be required for something that simple.

    I didn't really understand red green refactor until I read through the presentation linked here.



  • @cmccormick said:

    To be pedantic, I think what drives changing the 'addthree' function from returning 7 is another test (e.g. assert(addthree(5)==8); would fail), not refactoring. Refactoring would be to remove any cruft in the function. Probably none would be required for something that simple.
    It does seem strange to call it refactoring but according to Kent Beck it definitely is. He gives a very similar example to mine near the end of chapter 1 of TDD By Example. Having made the test go green by returning a constant, he then gets rid of the duplication across code and tests, as part of the refactoring step.


    By adding another test you can accomplish the same thing in practical terms, but it's not as elegant. There's no logical reason why you couldn't pass both tests using a conditional (given 4, return 7; given 5, return 8). It becomes an arbitrary decision how many tests is enough tests to go "fuck it let's write real code now". It's nice if the real code can arise out of the removal of duplication.


    One thing that is really interesting here is that this definition of refactoring does seem to be at odds with the idea that refactoring shouldn't change functionality. A difference between Beck's approach and Fowler's maybe? Or a difference in the meaning of 'refactoring' inside of and outside of TDD context? The latter makes some sense to me because if the functionality is entirely defined by the tests, then anything that keeps the green bar going is not a change in functionality ...?



    Never mind about the Sutherlands mix-up, my period is over so I'm not upset about it any more :)



  • @token_woman said:

    One thing that is really interesting here is that this definition of refactoring does seem to be at odds with the idea that refactoring shouldn't change functionality. A difference between Beck's approach and Fowler's maybe? Or a difference in the meaning of 'refactoring' inside of and outside of TDD context? The latter makes some sense to me because if the functionality is entirely defined by the tests, then anything that keeps the green bar going is not a change in functionality ...?

    I see that as "no change in results" (rather than functionality), but I suppose the concept that decisions are based on a green status does imply that the test concerns itself more with the outcomes rather than the internal workings.

    I always saw refactoring as rewriting or reworking, more of a reorganisation of the code to something more elegant, understandable, maintainable.. rather than leaving it as a "working but ugly mess." I don't follow TDD methods (not formally) but on occasion I've compared the results of tests before and after refactoring to show there's no change in functionality...  it never occured to me that I was unconsciously basing my decisions upon green bars. Hmmm.

    @token_woman said:

    Never mind about the Sutherlands mix-up, my period is over so I'm not upset about it any more :)

    I can breathe easily again!



  • @Watson said:

    If refactoring breaks the external interface (including unit tests) then you're doing it wrong - the unit tests are there to verify that a refactoring didn't break anything.

    Just finished a 3 day intensive course on TDD with Wirfs-Brock and Yoder. They'd call the above statement wrong. The tests are there to give you confidence when you refactor, but that doesn't mean you're not allowed to break the tests. The tests should not be allowed to shackle you to a bad design, that goes against their entire purpose. If you can't do a refactoring that everyone knows is necessary, because the tests are going to break, you're quite awesomely missed the point of having unit tests. Tests are just more code, sometimes they need to change when something else changes.



  • @smxlong said:

    @Watson said:
    If refactoring breaks the external interface (including unit tests) then you're doing it wrong - the unit tests are there to verify that a refactoring didn't break anything.

    Just finished a 3 day intensive course on TDD with Wirfs-Brock and Yoder. They'd call the above statement wrong. The tests are there to give you confidence when you refactor, but that doesn't mean you're not allowed to break the tests. The tests should not be allowed to shackle you to a bad design, that goes against their entire purpose. If you can't do a refactoring that everyone knows is necessary, because the tests are going to break, you're quite awesomely missed the point of having unit tests. Tests are just more code, sometimes they need to change when something else changes.

     

    Perhaps I overstated the case somewhat, but "Tests are just more code" is where the disconnect came in: I was speaking of unit tests as the specification of what the program is supposed to do - something that refactoring (of which I was speaking specifically) is not supposed to affect ("Oh, it used to be able to uniformly distribute the barycentres but it doesn't any more because we decided to refactor.") Tests will be broken by changes ranging from single keystrokes to deletion of the entire codebase, and any refactoring involves making changes, but until the tests pass again you haven't finished that refactoring. And if the changes required by the refactoring includes changes to the code describing the tests then so be it.

    Refactoring isn't supposed to break the external interface: if the external interface needs to change it's supposed to be in response to changing requirements.



  • @Watson said:

    @smxlong said:

    @Watson said:
    If refactoring breaks the external interface (including unit tests) then you're doing it wrong - the unit tests are there to verify that a refactoring didn't break anything.

    Just finished a 3 day intensive course on TDD with Wirfs-Brock and Yoder. They'd call the above statement wrong. The tests are there to give you confidence when you refactor, but that doesn't mean you're not allowed to break the tests. The tests should not be allowed to shackle you to a bad design, that goes against their entire purpose. If you can't do a refactoring that everyone knows is necessary, because the tests are going to break, you're quite awesomely missed the point of having unit tests. Tests are just more code, sometimes they need to change when something else changes.

     

    Perhaps I overstated the case somewhat, but "Tests are just more code" is where the disconnect came in: I was speaking of unit tests as the specification of what the program is supposed to do - something that refactoring (of which I was speaking specifically) is not supposed to affect ("Oh, it used to be able to uniformly distribute the barycentres but it doesn't any more because we decided to refactor.") Tests will be broken by changes ranging from single keystrokes to deletion of the entire codebase, and any refactoring involves making changes, but until the tests pass again you haven't finished that refactoring. And if the changes required by the refactoring includes changes to the code describing the tests then so be it.

    Refactoring isn't supposed to break the external interface: if the external interface needs to change it's supposed to be in response to changing requirements.

     

    I agree with that in general, the catch I think would be if one of the requirements was forcing a design that was incredibly terrible.


Log in to reply