One agenda item: I think we should discuss the following list
(recently sent by Thomas) and boil it down into some action items
(jiras if they don't already exist) with assignee's where possible.
I've been discussing Maven support for a while, maybe this is a good
time to do it.
Patrick
* The code is tightly coupled
* most so called "Unit-Tests" are actualy integration tests. They run the
whole application and test one specific functionality.
* no uniform configuration: command line parameters, system properties,
configuration file (java properties)
* configuration properties copied to static class members
* feature bloat on fragile foundation: e.g. chroot + automatic resubscribtion
does not work
* implementation unlike specification: allowed characters in path
* still on ant instead of maven (depends how you see ant vs. maven)
* circular object dependencies (e.g. ZooKeeper <-> ClientCnxn)
* methods with +100 lines of code and nested conditions depth well over 5
* general attitude against refactoring, no knowledge or appreciation of
"effective java" (Josh Bloch) or "clean code" (Robert C. Martin)
* magic numbers instead of enum
* still bound to inline copy of jute (HadoopIO, avro predecessor)
* even hand coded (de)serialization in leader election
* no client-only jar. Every client gets the full server code.
* unhandy API triggered (at least) two client API wrappers: zkClient, cages
* insane amounts of code duplication
* horrible, fragile thread programming: plenty of "XYZ extends Threads"
instead of
- implements runnable
- or better: executor framework
- or much better: actors (see Akka)
-> leads to fear of refactoring, because nobody understands all
synchronization needs.
On Thu, May 19, 2011 at 9:17 AM, Benjamin Reed wrote:
> please respond to this email to add things to the agenda for the dev
> meeting. here are my items:
>
> item: we need to figure out a better way of managing recipes.
>
