Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Evaluating an application for maintainability
Message
From
27/05/2010 11:30:41
Mike Yearwood
Toronto, Ontario, Canada
 
 
To
27/05/2010 10:19:32
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Environment versions
Visual FoxPro:
VFP 8 SP1
OS:
Windows XP SP2
Network:
Windows 2003 Server
Database:
Visual FoxPro
Application:
Desktop
Miscellaneous
Thread ID:
01466223
Message ID:
01466248
Views:
64
>6) "Overuse" of common functions and methods and classes
>a) is this possible? although code reuse is something to strive for, ie.e. code using common class libraries, etc. However, changing core classes or functions exposes us to the risk of breaking multiple parts of the application.
>Looking for ideas here.
>
>7) EVALUATION OF NEED FOR REGRESSION TESTING
>If a client says to me - "I need change X tomorrow no matter what" . The most efficient way to effect the change, it seems, is to modify, for example, a data handling class that is used by numerous functions in the application. But changing the data handling class, directly, is risky? No? should I subclass it? Suppose it is not an OOP application? In any event, changing common code probably means that, at least theoretically, the whole application needs to be regressions tested - a huge endeavor? No? Ways to speed that up?
>In general, the concept of regression testing and how the application design impacts the need for it, seems to me to be a huge topic for evaluating an application's maintainability. Looking for ideas here.
>
>

re #6
I argue there is no such thing as overuse of common code. If you have multiple copies of similar code and discover a bug in one, determining and fixing that same bug in several similar programs far outweighs any risk and you have to regression test each of those. If the spark plug is designed correctly - at design time, each instance of it at runtime will work. If you change the spark plug design, regression test the one instance in all it's test cases and it must work in all places where it is used. If something fails at runtime, you need to update your tests to handle that scenario, tweak the design, retest until the plug is perfected.

re #7
Most systems that I have seen are spaghetti - numerous strands of code dangling from a menu, with very little modularity. Most programmers start in on a new application by attempting to grok the entire bowl. Since each strand is independent, I have had lots of success walking from the menu to a single strand and effecting the change.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform