The spec (ification) tells you
exactly what the problem is, i.e. a very precise version of the requirement. It tells you what the code has to do, without saying how it does it. It sounds like your data mapping document covers the bulk of that. The main thing about the spec is that it has agreement from the customer/your boss. "If it ain't in the spec, it ain't a bug" - if something doesn't work the way they expect, you should be able to say either "That's what the spec asks for" or "it isn't in the spec, so the behaviour is undefined". Ideally it should cover error cases etc (see my post in the other thread) as well as the data mapping.
As far as design goes, your aims are:
- To minimise code rewrites when you decide on a better way/make a mistake
- To minimise code duplication
- To make the code maintainable
So in the main you should try and identify functionality that can be generalised and re-used by different functions. An example of that might be reading a db handle and performing transformations. There's no point in rewriting the while ($db->fetchrow_array) loop over and over again for every data source, so you'll probably want a general "read_datahandle" type of function. Data::Sync does this sort of task, and has general read & write methods, with the read method calling the appropriate transformation from a hash of coderefs keyed on the field name. Your requirement is probably more complex, but that's the general gist.
Note that "there's no point" means "really try not to" - if you find a bug, you want to fix it in one place only; if you find a better way, you want to fix it in one place only, and you'll get really bored cutting and pasting the same code over and over.
--------------------------------------------------------------
"If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
John Brunner, "The Shockwave Rider".
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.