La documentación de una aplicación de acceso para los desarrolladores [cerrada]

Question

necesito para documentar una aplicación MS-Access que fue creado, desarrollado y mantenido por completo por un usuario de energía de más de 10 años.

Esta es una situación interesante, porque lo que quieren es un modo manual que un desarrollador puede venir en el futuro sin el conocimiento cambia de dominio y hacer previas a la interfaz, o el servidor en el momento oportuno.

Hay algunas preguntas en mi mente de este pequeño proyecto:

• ¿Qué es un buen manual de diseño de la creación de la aplicación? Microsoft Word no acaba de cortarlo.
• ¿Qué tipo de cosas te, el desarrollador, la necesidad de conocer con el fin de realizar cambios en cosas como formularios, informes, tablas u otros objetos de Access?
• Hay algo más que se perdió? Cualquier escollo?

Answer 1

En mi experiencia, los programas basados ??Acceso y VB6- se ven afectadas por la replicación de código y más deuda técnica que los programas en idiomas principales. No estoy seguro de por qué. Tal vez sea la naturaleza de acceso como un "prototipo" o base de datos "juguete" (aunque puede ser muy poderoso cuando se produjo correctamente).

Si tuviera que elegir entre gastar tiempo en la documentación y gastar tiempo en la reducción de la deuda técnica, por ejemplo, por remodularizing, lo que elimina código repetido, funciones largos de división, etc., yo elegiría esta última. La mejora de la capacidad de mantenimiento y facilidad de lectura sería mayor.

Answer 2

Se podría comenzar con la generación de algún tipo de documentación automática de código usando MZ-Tools complemento para VBA. El mismo complemento de ayuda se pueden limpiar las declaraciones de variables no utilizadas, generar números de línea, los procedimientos de reabastecimiento dentro de un módulo, etc.

La documentación de las formas es más difícil. Mi propuesta sería la de mantener una captura de pantalla, alltogether con un archivo .txt obtenido por el método application.saveAstext indocumentado.

Answer 3

Yo sé que esto está cerrado por mucho tiempo, pero no puede abstenerse de añadir mis 2 centavos:
En el caso mencionado, creo que el documento más útil para producir una documentación funcional (que debería haber existido antes de iniciar el desarrollo en un mundo ideal).
En segundo lugar se encuentra dentro del propio código, y que incluye la VBA, sino también las descripciones de los campos que se pueden configurar en Access y SQL Server.
En tercer lugar es una (o un conjunto de) buen diagrama de base de datos. Una vez conseguido eso, todo lo demás puede ser generada por el revelador nuevo usando sus herramientas favoritas.
Hablando sobre las herramientas, me gusta especialmente y recomendar:

• Herramientas MZ: especialmente para encontrar fácilmente lo que llaman las rutinas de la que su mirando
• Smart sangría: a código correctamente guión. Tratando de leer el código mal sangría me enferma
• SqlSpec: (no libre) genera documento HTML de la propia base de datos para la mayoría de los motores de base de datos

Answer 4

¿Usted ha intentado el utilizando el construido en documentador de bases de datos? Se imprimirá todas las tablas, índices, formas, controles, cada propiedad de los controles. Código, el SQL que se utiliza y casi cualquier cosa. Esto resulta en impresiones grandes, pero sólo masivas. Sin embargo, mientras que matará a unos árboles en el proceso seguro que es una gran manera de impresionar al jefe.