[Tutor] How to refactor a simple, straightforward script into a "proper" program?

[boB Stepp]

On Wed, Jan 1, 2020 at 6:19 PM DL Neil via Tutor <tutor at python.org> wrote:

> Why did I cut-out the code and the suggested improvements? Because the
> reason why many of us are reluctant to "maintain" or "improve"
> someone-else's code is an anxiety that if we fail to understand every
> nuance of thinking that went into the original author's work, we will
> introduce errors!

Methinks you giveth me too much credit for potential subtlety!  If
there are any "nuances" in the simple script I posted I am totally
oblivious to them!

[...]

> Accordingly, should we pay any regard to 'the rest', before completing:
>
> > 6)  There are no tests, which makes it more difficult to grow/maintain
> > the program in the future.

Aha!  You are holding me to a proper standard of coding expectations.
Alas, I am a mere hobbyist programmer with overly high aspirations who
routinely falls short of the lofty heights for which I strive
(SPLAT!).

> I've just re-read an interesting observation of the collection of tests
> one might build-up, as a system grows - a challenging question to ponder:
>
> - if the code and all other documentation of a program/system were
> 'lost', could you?should you, be able to reconstruct the whole from the
> test-set alone?

That is a very interesting question!  My initial reaction is no, but
the better the test suite the better the precise intent of the unseen
source code should be evident.

> I am currently working on code which aims to re-use other classes. There
> are three different data-structures which may be used as input, from
> basic strings, through PSL class, to a locally-coded data-object; the
> consideration then becomes: were all the inputs provided or do
> (different for the various sub-classes) defaults apply; then there are
> all the different real-world combinations which the data represents, eg
> does the transaction currently 'exist' or is it hypothetical at this
> point; and they're only the first three considerations which generate
> permutations or combinations!
>
> During the task, I have found that the new code has failed because I
> didn't adequately code around my own tests (TDD's intent), but also two
> further conditions:
>
> 1 my assumptions about how the underlying classes work were
> incomplete/faulty - and thus my 'new code' was inadequate, and
>
> 2 that when certain things didn't work, it was a fault in the provided
> classes - apparently a combination of factors they did not anticipate,
> and in at least one case, had no test to reveal (but my tests of my code
> (unintentionally) did).
>
>
> Whilst the latter was frustrating (which is one of the points I'm
> making), the advantage of being given not just the code (classes, etc)
> for re-use, but the tests to verify that code (and consequently the
> superstructure I was building 'above' it) have been an enormous
> advantage - had I needed to 'read the code' with no further help,
> perhaps I would have thrown it out and 're-invented the wheel'!
>
> (which decision, strangely enough, has justified many an (expensive!)
> system-rewrite project!)

Very interesting and thought provoking!


-- 
boB