Jonathan Ellis <jbel...@gmail.com> wrote on 04/07/2009 09:02:22 PM:
> > On Tue, Apr 7, 2009 at 10:11 PM, Avinash Lakshman > <avinash.laksh...@gmail.com> wrote: > > The part that is very disconcerting are the following: > > (1) If one becomes a committer one is not expected to blitz through the code > > base and start refactoring everything. > > There are two reasons I refactor. > > One is, I always try to leave the code better than I found it. This > helps fight technical debt. In a project the size of cassandra you > have to do this or you end up with fragile code that you cannot change > without introducing regressions. Usually this is not because the > original code was bad, but because the requirements changed as the > project grew and now there is a better way. Or sometimes there is an > idiom better suited to a situation that the original author was not > familiar with. That's okay too; nobody's perfect. > > An example of this is r762440, replace String.indexOf != -1 with > String.contains (review by johano). > > Two is, if I am going to introduce a new feature I will try to > refactor first without changing behavior in such away that the feature > becomes easier to add. This breaks the changes up into smaller pieces > which are easier to review and easier to validate against regressions. > (The more things you change at once, the harder it is to find which > caused a problem.) > > A specific class of this kind of change is merging copy/pasted code > into method calls. Duplicate code makes it hard to add features > because you have to know about the duplicates and remember change all > when you change one. There is a lot of this in cassandra. Examples > include r762440, r762440, r762440. (This specific area of the code > did bite me while implementing remove; that's what the "os x error" > thread on google groups was about.) > > So there is a method to my madness. :) > In my opinion, the kind of refactoring that removes duplicate code is necessary. This reduces the chance of introducing bugs and makes it easier for adding new features. This kind of refactoring is probably better done sooner than later. Of course, it would be great if the original developers can guide this process. Jun IBM Almaden Research Center K55/B1, 650 Harry Road, San Jose, CA 95120-6099 jun...@almaden.ibm.com
