Developers of Sympa

[IKEDA Soji <address@concealed>]

Hi Sympa develpers,


Recently I'm losing my confidence that Sympa 7 will emerge in
someday.

The biggest difficulty is refactoring on current code, I feel:
Sympa 6.2 includes numerous features added by various people, and not
a few of them have problems --- undone implementation (see e.g.
GH#231 [1]), broken logic (e.g. GH#235 [2]), code not thought out
well (GH#234 [3]), duplicate codes (found everywhere), ..., and most
of them are hardly documented in the beginning.

  [1] https://github.com/sympa-community/sympa/issues/231
  [2] https://github.com/sympa-community/sympa/issues/235
  [3] https://github.com/sympa-community/sympa/issues/234

I gave very recent examples above, but most of bug fixes and changes
we have dealt with in this one year (and more) are something like
them.  As soon as someone starts refactoring, they will be in maze
due to problems above.

Thus, I think of proposing two things.

                                 *

First: Should we throw Sympa 6.2 away?

If answer was "yes", we might not consider the second proposal below,
and could start writing Sympa 7 from scratch soon.  In this case
Sympa 6.2 would be dying gradually.

I feel this option is not so bad from view of mental health of
community.  Only disadvantage is that Sympa 7 at the end will
definitely lose compatibility with Sympa 6.2 or earlier.

If answer was "no", since we would have to find the way to achieve
both improvemnt (rather repair) of Sympa 6.2 and production of
Sympa 7, I will send a proposal afterward.


Please let us know the answer of your own.

Then, after you answered, please read following.


                                 *


Second: Change the way of refactoring.

Everyone says that we have to introduce unit test framework into
development of Sympa. However, we have not acomplished it.  I think
the reason is clear: Anyone don't have knowledge enough about what
is written in code, or even if they know, don't share knowledge.

Either by trial in the past (during pre-6.2) or by recent trial by
David on sympa-7.0 branch, I feel that we could not get satisfactory
result --- One of our goal was to write unit test.  However,
including almost only "use_ok" and "isa_ok" is not the unit test (it
proves just that module can compile).  The result will be the same if
the other worked. --- We don't know what we should include further.

As a solution, I propose to proceed refactoring on sympa-7.0 branch
as below:

  1. Write POD of module in question to reflect behavior of the
     module _clearly_.  Until we have finished writing, we must not
     touch the code.

     In fact, we may find mistakes and/or defects in the code.  We
     won't repair code at once, but will describe desirable behavior
     (instead of broken behavior) in POD. (See also note below.)

     We may also want to propose new feature or improvement.
     However, since we are writing POD describing existing code,
     such things should not be included in POD.  You may propose
     them at appropriate place else.

  2. Next, write unit test covering entire interface described in POD
     above.  We should include enough number of cases to test
     possible behavior (again, calling each method once at a time is
     not unit test).

  3. At last, we put our hand to actual code in source.

       - We repair problems found on 1. above.
       - We refactor the code in true meaning.

     This step will last until the code will pass all ceses of unit
     test.

Note: If a problem found while we carrying out steps 1. and 2. is
more or less severe, it may be fixed on sympa-6.2 as necessity (and
fix may be merged into sympa-7.0).  Anyways, we should not touch the
code on sympa-7.0 before step 3.


                                    *

What do you think?


Best regards,
-- Soji

-- 
株式会社 コンバージョン
ITソリューション部 システムソリューション1グループ 池田荘児
〒140-0014 東京都品川区大井1-49-15 アクセス大井町ビル4F
e-mail address@concealed  TEL 03-6429-2880
https://www.conversion.co.jp/