directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: [Shared] shared-ldap is a mess
Date Sun, 15 Apr 2007 15:39:27 GMT
On 4/15/07, Ole Ersoy <ole.ersoy@gmail.com> 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
www.iktek.com

Mime
View raw message