directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [Shared] shared-ldap is a mess
Date Sun, 15 Apr 2007 16:03:00 GMT

I think we are thinking the same thing.

Since this is digital we get to make a brand new room.

We then make a system for storing things in the new room.

Each thing going in the new room has a designated spot.

Then we take things in the old room that are ready
to be placed in the new room, and put it there.

Then we write javadoc according to our defined
quality requirements.  The javadoc is the
inventory control system for the new room.

When someone needs something they check the javadoc.

This way the new room is really clean.

This is like taking a messy room, removing everything,
dusting off and cleaning up various things that were in the room,
and then putting everything back in the proper place.

So I'm just using the new room as the final destination for
classes that have been cleaned up.  Class that are ready to
go, can just be put there.  In this case, the fact that they are in
the new room only symbolizes that they have gone through our quality
control process.


- Ole

Emmanuel Lecharny wrote:
> On 4/15/07, *Ole Ersoy* < 
> <>> wrote:
>     SNIP
>      > (1) touch only as needed and contain until rewrite
>      > (2) refactor gradually as best as we can without big bang or until we
>      > realize that a big rewrite is needed later but still try to
>     improve it
>      > (3) ... any more ideas?
>     How about this?
>     We start with fresh Utility Classes.
>     Each class is centered around a core concern,
>     such as:
>     Navigation
>     IO (create, read, update, delete)
>     Parsing
>     Each method that goes in these
>     classes has to be well documented (javadoc)
>     and tested (All corner cases
>     and edge conditions).
>     We also follow an agreed upon set of conventions
>     for defining the Utility packages and Class Names (And Ideally
>     class members, but that requires more discussion to find
>     conventions that are acceptable to all I think).  I also
>     need to look at Jakarta commons to see if they have other
>     methodology that could be useful.
>     We then generate Javadoc and put it in a central
>     place, so that utility concern classes and methods
>     are visible.
>     When one of us needs a utility, and can't find it in the new shared
>     utilities, we ask on the mailing list
>     If no-one responds,
>     the person needing it creates it
>     and puts it in an existing utility class,
>     or creates a new class corresponding to a new
>     concern area.
>     This allow a clean utility library to grow as needed
>     by the team.  I think it's essentially option [2].
> I don't think this is a viabl option. This will just lead to another new 
> big mess. We have a lot of good classes in shared-ldap, and we should 
> reorganize them. Rewriting everyting is simply crazy. We have some parts 
> which are also really bad, and we know which ones, noyt becaus ethe code 
> is bad, but because the target was missed. For instance, the Message 
> classes are really really bad. We have to rethink the way to mix two 
> tragtes into one set of classes for those set of classes (internal 
> message manipulation, and codec)
> We also need to separate some classes into smaller packages, like 
> utility packages, codec package, etc.
> But ditching what we have because it's a mess is a kind of NIH syndrom. 
> It's like a messy room : you don't throw everything in your room just 
> because it's a mess, you clearly clean the room.
> -- 
> Cordialement,
> Emmanuel L├ęcharny
> <>

View raw message