>> 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.
