incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandeep Tata <>
Subject Re: working together
Date Thu, 09 Apr 2009 17:37:26 GMT
>> Even automatic
>> refactoring without unit tests makes me uncomfortable.
> I don't know how else to say this: that's an unwarranted overreaction.

Probably :-)
I think automatic refactoring tools have been tested enough for java
now that we'd probably be fine using them without unit tests.
However, much of the really useful refactoring of the code we want is
beyond simple automatic ones.

>> 2. Big refactoring makes it difficult for the original developers
>> (A&P) to review patches quickly.
> That is why I break the refactoring parts into separate patches.  It
> is not hard to review when changes are split up this way.

Agreed. I'm a big fan of refactoring for simplicity. I'm making the
argument to slightly delay big ones because:

1. I think the FB team has had very limited bandwidth to devote here.
(Not a criticism, just an observation)
2. They are relatively new to Apache processes and are learning to
balance with with their FB commitments.

I'm just suggesting we continue to make a few concessions until we
have a first release. We're still figuring out a process for
committing changes! Like it or not, this is still early days!

>> perhaps we should hold off on accepting big refactorings
> Unless we have vastly different ideas of what "big" means (which is
> possible), I emphatically disagree.

Again, I think many of refactoring patches we're discussing on JIRA
are perfectly acceptable, and in my opinion, much needed. For
instance,  CASSANDRA-52 and CASSANDRA-58. OTOH, refactoring the entire
set of messaging classes (which is something we should get to
eventually -- I'd hate to see more bugs like CASSANDRA-21) would
qualify as a bigger refactoring. I'm not suggesting we put these off
for a long time, but just until we have a basic first release!

> The important question is not, "Is refactoring more dangerous than
> doing nothing?"  Of course it is.  Writing code is always more
> dangerous than not writing code.


> The real question is, "Is adding new features while refactoring more
> dangerous than adding new features without refactoring?"  And the
> answer is no.  Refactoring improves the fit of the code to its current
> purpose rather than grafting layers of new features on top of a
> foundation that was not meant to support them.  Refactoring also helps
> prevent bugs -- for example my remove patch introduced a bug fixed in
> r761093 -- because I only modified one of three copies of a piece of
> code.  It can also expose bugs in existing code.  See CASSANDRA-58 for
> an example of a bug that Jun Rao noticed because of a refactoring
> patch.

I understand the purpose and merits of refactoring code :-) There are
many parts of the code I'd like to clean up too...
My argument is simply an attempt at solving some of the birthing
trouble our community is having. It is not a technical argument
for/against refactoring...just a suggestion for altering their timing
them so that we can move forward more easily.

View raw message