Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Evaluating an application for maintainability
Message
De
27/05/2010 11:30:41
Mike Yearwood
Toronto, Ontario, Canada
 
 
À
27/05/2010 10:19:32
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 8 SP1
OS:
Windows XP SP2
Network:
Windows 2003 Server
Database:
Visual FoxPro
Application:
Desktop
Divers
Thread ID:
01466223
Message ID:
01466248
Vues:
65
>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.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform