I have been tasked with the job of evaluating the maintainability of a large VFP application that is deployed in several hundred sites. The owners of the application want to determine whether it would be worthwhile to continue with maintenance of the application or whether a rewrite would be required. I haven't seen the application yet. However, in advance of seeing the application, I need to define the criteria I will use for evaluating the application.

I'm looking for some feedback and ideas on how to approach this task. Some of the main ideas I have so far are:

1) DATABASE DESIGN
Database design usually drives the code. If the data model is bad, the code will be designed around the data model, and therefore, bad as well. In my view this is the usually the single biggest determinant of maintainability.

2) CODE QUALITY
A) There are many of the 'obvious' factors. Some that come to mind immediately for quality VFP specific code are:
a) Minimal use of public variables b) use of short functionally cohesive functions or methods c) proper scoping and declaration of private and local variables d)minimal use of 'private' if a new app

B) LOOK FOR EFFICIENT CODE
example: code that repeats the same blocks of code multiple times in a case statement is inefficient. Code where the functionality has been refactored into a separate function or method is more efficient. This concept applies throughout the application

3) CONVERSION from Xbase/DBF code to SQL code
a) Looking for ideas.

4) EVALUATION OF DUPLICATE FUNCTIONALITY
a) "copy and paste code" - the same prg or form, or report can be copied multiple times and then varied slightly. Very inefficient, but, maybe better from the standpoint of regression testing. How to evaluate when duplicate functionality isn't such a bad idea, if ever. Looking for ideas.

5)QUALITY OF TABLE HANDLING CODE
a) Badly designed code uses default data session in a form, leaves tables open - subject to alias name is already in use errors
b) can make endless examples of table handling code that breaks an application. Some extra examples would be helpful.

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.


I know this is a far reaching involved post. Any feedback whatsoever is appreciated!