Re: Clearly setting apart the code we want to replace?

Subject: Re: Clearly setting apart the code we want to replace?

From: David G <..hidden..>

Date: Tue, 18 Oct 2016 08:30:55 +0800

Hi Erik,

On 16/10/16 22:27, Erik Huelsmann wrote:

Hi all,

The source code in our project falls into two categories:

1. the code we newly wrote (and which we want to maintain)

2. the code that we inherited (and which we want to replace)

I'm Glad you said "want to replace" rather than "need" here, it's a vital distinction that hasn't always been made in the past.
Right at the moment we have good momentum in improving the UI, UX, Testing coverage, and squashing those pesky little bugs that we've been finding.
The inherited code, while it certainly has it's issues and is fragile does work (on the whole) and while we DEFINITELY want to replace it to make our lives easier, we don't have an immediate NEED to do so.
What I'm getting at is, unlike in the past were there was a belief that we had a strong need to replace it, for now the cost benefit (in terms of time) says we should spend our valuable time working on the things that we currently are.
The remaining legacy code will get replaced in stages when we have a good NEED to start doing so.

Where to find code of the first and the second category, is pretty clear to most of us. However, it's not to any new-comers to the project.

In order to improve this clarity - making it easier to communicate about it - I'm proposing to move all *library* code that we intend to replace from lib/ to old/, meaning

* lib/LedgerSMB/??.pm -> old/LedgerSMB/??.pm

* lib/LedgerSMB/PriceMatrix.pm -> old/LedgerSMB/

* lib/LedgerSMB/Form.pm -> old/LedgerSMB/

* lib/LedgerSMB/Num2text.pm -> old/LedgerSMB/

* lib/LedgerSMB/Session.pm -> old/LedgerSMB/

* lib/LedgerSMB/old_code.pm -> old/LedgerSMB/

* lib/LedgerSMB/PGOld.pm -> old/LedgerSMB/

While I'm aware we didn't inherit PGOld, but I think it's code we want to phase out anyway.

(Note that the above only applies to current master, meaning 1.6+)

I'd go one step further, and actually use,

* lib/LedgerSMB/$legacy_files -> old/lib/
* bin/* -> old/bin

This allows us to start getting some support scripts that a sysadmin would normally expect to find in a bin dir where they belong.
Things like create a new company (from the command line), and possibly scripts for direct import of data, upgrading a src install, verifying that dependencies are correctly installed, who knows what else we may want.

Furher more, I'd like to remove the REST_Class::* and REST_Format::* handlers, as they apply to REST services which we never really supported.

I'm happy to drop the REST handlers, especially in light of the Plan we came up with when I met up with you while I was in Europe.

If we do things this way, then there are 2 directories with code we want to "dump": bin/ and old/. I think that concept is quite easy to explain.

Comments?

Regards
David G

------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot