Re^2: "Designing" a Perl program

if this is related to the data consolidation requirement you posted about some time ago (Automating data loading into Oracle), at the very least your design should include something like this:
SOURCEFIELD           TRANSFORMATION          TARGETFIELD
sourcedb.name         lowercase               targetdb.fullname
sourcedb.firstname    uppercase               targetdb.givenname
..
[download]

<blushes>. Yes. Good eye. What you describe above is what I have come to call the "data mapping" document. That one I understand very well, and also understand its importance. I will be, of course, producing that.

I am not sure at this time that my programming will be OO. I am very weak in OO, and I don't want to complicate my life for now. I mentioned UML because UML seems to be the technique du jour, and others in my team always mention it. I am not convinced they all know its utility. I know and understand flow charts, and intend to use them.

I have to take source data, do magic to it, and stuff it into target tables. There is not much more to it at that level. Of course, the magic is complicated at times, and there are many different kinds of source data, and many different target tables.

As I mentioned above in my reply to dragonchild's advice, I don't have any specs, and I don't understand what specs means in this context. From your advice, it seems I have a chance to make them up now. Please elaborate.

--

when small people start casting long shadows, it is time to go to bed

Comment on Re^2: "Designing" a Perl program Download Code

Replies are listed 'Best First'.
Re^3: "Designing" a Perl program by g0n (Priest) on Jan 14, 2006 at 20:15 UTC
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".	[reply] [d/l]
Re^3: "Designing" a Perl program by philcrow (Priest) on Jan 16, 2006 at 15:30 UTC
If you like flowcharts, call them activity diagrams your friends will think they are UML. Phil	[reply]