[
Lists Home |
Date Index |
Thread Index
]
I try to gauge the impact across the system's users and the architecture
you want to get to.
Changing the structures, and the refactoring of code that goes along
with those changes, opens up the system to subtle failures. Especially
if you don't yet fully understand the reasoning behind the existing
structures, you may later find that what you thought was a more
normalized form was not itself ideal. I'd prioritize those changes based
on an understanding of the history of faults that the existing system
has, using bug tracking history and anecdotal evidence of problem areas.
Then look at the features you want to get to. Put your resources toward
the biggest bang for the buck.
Leaving fields as-is is a recipe for having to fix something later on,
building workarounds to the flaws despite your best efforts to ignore
the problem. If you think there is something wrong now, there probably is.
What sort of tests exist to verify that the structures and in-use
queries actually perform as assumed? Sometimes structures which are left
in an apparently schizophrenic state only work because of code that's
been hacked to make up for the inconsistencies, leaving latent bugs.
Your apparent reluctance to touch the structures suggests a need for
unit tests.
Names are almost trivial to change, make a little impact on legibility,
but expose the users to the greatest risk of not-so-subtle failures.
Especially if they've constructed their own systems that depend upon
those names. I wouldn't hesitate to rename given other structural
changes, or introduction of alternative interfaces/views, but it is
dubious on its own.
Regards,
- Mitch
|
