Re: really big refactorings

Why do you want to call it a refactoring?

If it is to simplify communication it clearly isn't.
Every time you will call something like this
refactoring you will have to explain why you are
calling it a refactoring (like you did in your
original post). If you aren't going to explain it, you
risk to confuse people.

It is too specific to be added to a catalog, it is
probably too big to be described as a combination of
other smaller refactorings. It is certainly too big to
be applied in the refactoring process (like the
cataloged refactorings are applied).

So, beside wining the argument what else do you expect
to win? Presuming that it's not all about wining the
argument for you.

Regards,

Tamas

--- Richard <legalize <at> xmission.com> wrote:

> 
> In article
> <679385.49847.qm <at> web55610.mail.re4.yahoo.com>,
>     Tamas Szabo <balkan_tourist <at> yahoo.com>  writes:

Re: Re: really big refactorings

In article <811796.18953.qm <at> web55610.mail.re4.yahoo.com>,
    Tamas Szabo <balkan_tourist <at> yahoo.com>  writes:

> Fowler's example is performance optimisation.

Changes in performance are changes in the behavior of the system.

> Another example would be changing a Java app to use
> Java logging instead of log4j. I am changing it to
> remove a library dependency, not to improve the design
> of the code.

Removing a library dependency is a design improvement, IMO.
--

-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
      <http://www.xmission.com/~legalize/book/download/index.html>

        Legalize Adulthood! <http://blogs.xmission.com/legalize/>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

Re: Re: really big refactorings

--- Richard <legalize <at> xmission.com> wrote:

> Changes in performance are changes in the behavior
> of the system.

Yes, they are. And that's what Fowler says, it's on
the same or the next page as the definitions.
But he still doesn't call performance optimisation
refactoring.
Maybe because the main intent of the refactoring has
to be improving the design?

> > Another example would be changing a Java app to
> use
> > Java logging instead of log4j. I am changing it to
> > remove a library dependency, not to improve the
> design
> > of the code.
> 
> Removing a library dependency is a design
> improvement, IMO.

Ok, changing a Java app to use log4j instead of Java
logging because I want to wear a log4j t-shirt at
work.

Tamas

      ____________________________________________________________________________________

named pipe for output file fake

Hey, I just thought I'd pass along a nice way to fake an output file
in memory in a unit test under Win32.  Win32 has a named pipe
mechanism.  So instead of specifying an output filename to a routine
wanting to write to a file (too slow for a unit test), I created a
named pipe and passed the routine the name of the named pipe.  This
worked great -- everything stayed in memory and was nice and fast by
not going to the disk.  This may work for you in trying to unit test
Win32 C++ code that wants to write to a file.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
      <http://www.xmission.com/~legalize/book/download/index.html>

        Legalize Adulthood! <http://blogs.xmission.com/legalize/>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:refactoring-digest <at> yahoogroups.com 

Re: Re: really big refactorings

Richard wrote:
> In article <975157066.20080331093334 <at> acm.org>,
>     Ron Jeffries <ronjeffries <at> XProgramming.com>  writes:
>
>   
>> It needs to be
>>
>>   change, run, change, run, ...
>>
>> not
>>
>>   change,change,change,change,change,change,change,...,run
>>     
>
> If this is your characterization of what I've been saying, please go
> back and show me where I've said I'm doing the latter and not the
> former.
>
> If you're attacking the latter, then go right ahead, but realize it is
> irrelevant to what I'm saying because its not what I'm doing.
>   
My understanding of what you're saying is that the latter, though not 
necessarily a good thing, is still refactoring.

Specifically, you disagreed with this statement from Ron:

"The other is to work on a separate copy for a long long time and one
day release it. That would not be refactoring."

As I read it, that's similar to 

Re: really big refactorings

> Again, please (re)read the last chapter of "Refactoring" and read
> "Refactoring to Patterns".  

I think it's time you took a deep breath  You can assume everyone
here has read "Refactoring", and I would bet that most have read quite
extensively on the topic. Some us have even had articles published in
peer-reviewed magazines and spoken at conferences around the world on
this very subject.

> This is a limited view of refactoring that you're expressing

I don't believe so. In fact, so far, the only person who holds a
contrary opinion is you. There is not necessarily a problem with
limiting the scale of a technique anyway - it may actually be
desirable sometimes. Nothing scales indefinitely.

> Nowhere have I said that you don't keep a working system or that you
> leave unit tests failing (if you're fortunate enough to have them).

And nowhere did I imply that you did.

> Read the whole thing, yes.

OK. So do you not think your (and mine, too, shortly) problem might
not require something other than refactorings, in the same way that
working on legacy code does? Or do you think you can swap frameworks
with *only* small refactorings?

If so, I'm not sure what your original question was asking.

Rewrites, Architectural revamps, Redesigns....

To gallop away from the noise levels about when is a refactoring a refactoring.....

Let's for a moment contemplate things that are clearly not (patience,
I'll explain why this is still On Topic)...

Contemplate the following, not uncommon situation...

You have a large code base and a largish team slaving away on it....

The powers that be declare that "It Shall Also Do X", where X is not a mere
performance tweak or enhancement, but something substantially
different.

The very architectural fabric of the code, which perhaps is a bit
creaky, but functional, will plain rip if we squeeze X into it as
well.

How do manage....
   a) Risk management and change sprawl control.

   b) Keeping the team busy & coordinated. (Not waiting on the
       rearchitecting team, and the rearchitecting team not desperately
       trying to keep up with the rest of the team.)

   c) Version control strategies.

   d) Test, both unit and functional.

   e) Release strategies. (The rewrite typically spans one or more
       releases, both including and not including the rewritten code)

Re: Re: really big refactorings

Richard wrote:
> In article <1999820803.20080331075543 <at> acm.org>,
>     Ron Jeffries <ronjeffries <at> XProgramming.com>  writes:
>
>   
>> There are two ways of having the system work. One is to change it a
>> little every day and release it. That would be refactoring. The
>> other is to work on a separate copy for a long long time and one
>> day release it. That would not be refactoring.
>>     
>
> ...in your opinion.
>
> I disagree.
>
> The essence of a refactoring is making structural or design changes to
> a code base without affecting its behavior.
>
> Unit tests are not even required in order to perform a refactoring.
> I've performed many refactorings over the years without unit tests.
> (At the time I didn't know people were calling it Refactoring and I'd
> already been doing it for years before the term Refactoring was
> coined.)
>   
I'm afraid I'm inclined to agree with you, even though I'm not quite 
sure you agree with yourself .

As I read this discussion, there's little disagreement about the best 
practices for refactoring. Refactoring /should/ be done in small 
increments without breaking the code, if at all possible. What the 

Re: Rewrites, Architectural revamps, Redesigns....

John Carter wrote:
> The very architectural fabric of the code, which perhaps is a bit
> creaky, but functional, will plain rip if we squeeze X into it as
> well.

John, I try to not get into this situation (of a creaky code base), but 
I have always been able to refactor my way out of such a situation when 
I've needed to do so.  I'm not sure I can offer a recipe for any random 
team to do so.  I would want to know more about the current code, the 
desired changes, the team making the changes....

  - George

--

-- 
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

Open Web Application Security Project (OWASP) : April 2008