Si os toca mantener ASP clásico (viendo los hilos de por aquí, a alguien le toca), van algunos trucos para que el código sea algo más llevadero sin tener que reescribir la aplicación entera.

1. Separar el HTML del Response.Write siempre que se pueda. En vez de esto:

Response.Write "<table>"
For Each fila In resultados
    Response.Write "<tr><td>" & fila("nombre") & "</td></tr>"
Next
Response.Write "</table>"

Mejor volver al HTML normal y solo entrar/salir de bloques <% %> para la lógica:

<table>
<% For Each fila In resultados %>
    <tr><td><%= fila("nombre") %></td></tr>
<% Next %>
</table>

Se lee muchísimo mejor, y cualquiera con conocimientos básicos de HTML (no solo quien sepa VBScript) puede tocar el maquetado sin miedo a romper la lógica.

2. Sacar la conexión a base de datos a un include común, en vez de repetir la cadena de conexión en cada .asp. Un único conexion.asp con <!--#include file="conexion.asp"--> al principio de cada página, para que cambiar de servidor de base de datos algún día sea tocar un solo sitio, no cien.

3. Usar Command con parámetros en vez de concatenar SQL a mano, el fallo de seguridad más repetido en código ASP clásico antiguo (inyección SQL por concatenar Request.Form directamente en la consulta):

Set cmd = Server.CreateObject("ADODB.Command")
cmd.ActiveConnection = Conexion
cmd.CommandText = "SELECT * FROM Usuarios WHERE usLog = ?"
cmd.Parameters.Append cmd.CreateParameter("usLog", 200, 1, 50, Request.Form("usLog"))
Set RS = cmd.Execute

Ninguno de estos tres cambios exige reescribir la aplicación, son mejoras incrementales que se pueden ir aplicando página a página según vayas tocando cada una por otro motivo.

Bruno C.

Sin reescribir nada, lo que más se nota en mantenibilidad son estos cambios, todos aplicables de forma incremental sobre código ya existente:

1. Parametrizar todas las queries con objetos Command de ADO en vez de concatenar SQL a mano. Es el cambio con más impacto en seguridad (elimina la inyección SQL clásica) y además hace el código más legible, porque separa la estructura de la query de los valores concretos.

2. Sustituir On Error Resume Next silencioso por gestión de errores explícita: comprobar Err.Number después de cada operación que pueda fallar y registrar el error (en un log, en una tabla de errores) en vez de dejar que el script siga ejecutándose a ciegas tras un fallo. On Error Resume Next sin comprobación posterior es la razón número uno de que los bugs en ASP clásico sean tan difíciles de rastrear.

3. Extraer la lógica de negocio de las páginas .asp a includes organizados por responsabilidad, aunque sigan siendo VBScript plano. No hace falta un framework MVC completo, solo separar "esto calcula/valida algo" de "esto genera HTML", para que cada página .asp acabe siendo más una plantilla que llama a funciones, no un totum revolutum de HTML y lógica mezclados.

Ninguno de los tres requiere tocar la arquitectura general de la aplicación, y los tres juntos hacen que el código heredado sea mucho más llevable de mantener sin asumir el riesgo/coste de una reescritura completa.

Carlos