Re: [Shared] shared-ldap is a mess

[Ole Ersoy <ol...@gmail.com>]

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].

Old utility methods can be replaced gradually.  We just
need to map old utility methods to the new ones, so that
we know what to update.

Thoughts?

Cheers,
- Ole

Re: [Shared] shared-ldap is a mess

[Ole Ersoy <ol...@gmail.com>]

Emmanuel,

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.

WDYT?

Cheers,
- Ole



Emmanuel Lecharny wrote:
> 
> 
> On 4/15/07, *Ole Ersoy* <ole.ersoy@gmail.com 
> <ma...@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 <http://www.iktek.com>

Re: [Shared] shared-ldap is a mess

[Emmanuel Lecharny <el...@gmail.com>]

On 4/15/07, Ole Ersoy <ol...@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