avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject How do we get there? (was: Re:Where Where do you want to go?)
Date Mon, 05 Jan 2004 21:48:31 GMT
 > 2) how should we start refactoring Merlin to make it what we
 > all need?
 > * please note that development should be able to continue
 >   while refactoring occurs.

= Step 0 =

is a feature freeze. Not code freeze, feature freeze. Development can 
continue, but no new features. None.

= Step 1 =

Then, simply put, the first step is improving on the statistics:

* lines-of-code-per-class (must go down *a lot*)
* lines-of-code-per-method (must go down)
* lines-of-code-per-package (seems okay)
* lines-of-code-to-lines-of-api-documentation (must go up)
* lines-of-code-to-lines-of-testing-code (must go up)
* test coverage (must go to 70% at least for each and every class to be 
remotely convincing)

= Step 2 =

the second step is to make actual changes:

* full and correct javadocs must be added to each and every class and 
* the use of inner classes and static fields must be reduced to a minimum;
* class hierarchies must be untangled;
* code should be reformatted into consistent patterns (always use a 
'private XXX createXXX' or never use it, but at least always name it the 
same way; better make it protected, too)
* all hard-coded dependencies need to be removed;

= Step 3 =

at this point, it should be expected that test coverage is reasonable. 
The next step is then taking the steps to what I would be happy calling 
a 1.0 release and doesn't involve polite shaving but ruthless refactoring:

* about half of the current abstractions need to be removed;
* intra-package and intra-class dependencies should be minimized much more;
* intra-package and intra-class dependencies should be completely 
interface-based (except for simple value objects);
* the seperation between value objects and logic should be complete;
* +/- half of the terminology must go or each and every bit of it needs 
to be thoroughly debated;
* +/- half of the reflection usage must go;
* things like security, distribution, thread safety, classloader 
management, repository management, metadata management, configuration 
inheritance, profile inheritance, containment model inheritance must all 
be optional and the default implementations should steer way clear of them;
* etc etc etc.

= Me and stepping =

I don't even come close to having the time or the energy to do a 
significant part of that. I know Steve has it but it doesn't sound like 
he wants to commit to it.

Even if he and others do it will take months.

What I will commit to is the development of an extensive library of 
components to use for testing (I'm already working on that), but a lot 
of work will need to be done before I can even start thinking about 
adapting my tests to run them against merlin.

= in the meantime =

 > 3) What about the guy with simple needs?  What are we going to do for
 > him?

Given the current complexity of the merlin codebase, I feel it will take 
a loooong time before it can satisfy simple needs. IMHO we should 
repaint the avalon roadmap to reflect that: Merlin at the moment doesn't 
come close to being a migration candidate for fortress users, and it 
won't for quite some time to come.

= in the end =

 > 4) What about extensibility?  We need this if we are to survive.
 > Right now I get the feeling that Merlin is an all or nothing
 > approach.  Not a pick and choose the feature set approach.

when the system decomposition is clean and along the likely lines of 
customization and change, extensibility will come naturally. The current 
merlin decompositon is bad: its easily customizable in the wrong areas. 
The fortress decomposition is much more reasonable.

= releases =

Remember my comment about being fit for a 1.0 release? Well, we did the 
"fortress will be released real soon now" for too long; we shouldn't be 
doing it with merlin. Regular, incremental releases, one every month. 
Each one a little better than the previous one. Even containing the 
currently unknown big bugs in them. Sure.

= flame away =

off my soapbox now, and off to bed.


- Leo Simons

Weblog              -- http://leosimons.com/
IoC Component Glue  -- http://jicarilla.org/
Articles & Opinions -- http://lsd.student.utwente.nl/jicarilla/Articles
"We started off trying to set up a small anarchist community, but
  people wouldn't obey the rules."
                                                         -- Alan Bennett

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message