Hi Benjamin,

thank you for your response. Please find some comments inline.

Benjamin Reed:
>   code quality is important, and there are things we should keep in
> mind, but in general i really don't like the idea of risking code
> breakage because of a gratuitous code cleanup. we should be watching out
> for these things when patches get submitted or when new things go in.
I didn't want to say it that clear, but especially the new Netty code, both on 
client and server side is IMHO an example of new code in very bad shape. The 
client code patch even changes the FindBugs configuration to exclude the new 
code from the FindBugs checks.

> i think this is inline with what pat was saying. just to expand a bit.
> in my opinion clean up refactorings have the following problems:
> 1) you risk breaking things in production for a potential future
> maintenance advantage.
If your code is already in such a bad shape, that every change includes 
considerable risk to break something, then you already are in trouble. With 
every new feature (or bugfix!) you also risk to break something.
If you don't have the attitude of permanent refactoring to improve the code 
quality, you will inevitably lower the maintainability of your code with every 
new feature. New features will build on the dirty concepts already in the code 
and therfor make it more expensive to ever clean things up.

> 2) there is always subjectivity: quality code for one code quality
> zealot is often seen as a bad design by another code quality zealot.
> unless there is an objective reason to do it, don't.
I don't agree. IMHO, the area of subjectivism in code quality is actually very 
small compared to hard established standards of quality metrics and best 
practices. I believe that my list given in the first mail of this thread gives 
examples of rather objective guidelines.

> 3) you may cleanup the wrong way. you may restructure to make the
> current code clean and then end up rewriting and refactoring again to
> change the logic.
Yes. Refactoring isn't easy, but necessary. Only over time you better 
understand your domain and find better structures. Over time you introduce 
features that let code grow so that it should better be split up in smaller 
units that the human brain can still handle.

> i think we can mitigate 1) by only doing it when necessary. as a
> corollary we can mitigate 2) and 3) by only doing refactoring/cleanups
> when motivated by some new change: fix a bug, increased performance, new
> feature, etc.
I agree that refactoring should be carefully planned and done in small steps. 
Therefor I collected each refactoring item for the java client in a small 
separate bug in https://issues.apache.org/jira/browse/ZOOKEEPER-835 that can 
individually be discussed, reviewed and tested.

Have a nice weekend after Hadoop World!

Thomas Koch, http://www.koch.ro

Reply via email to