为开发人员记录访问应用程序 [关闭]答案

【问题标题】：Documenting a Access Application for Developers [closed]为开发人员记录访问应用程序 [关闭]
【发布时间】：2010-05-26 19:59:15
【问题描述】：

我需要记录一个完全由高级用户创建、开发和维护超过 10 年的 MS-Access 应用程序。

这是一个有趣的情况，因为他们想要的是一本手册，以便未来的开发人员可以在没有先验领域知识的情况下进入并及时对前端或后端进行更改。

对于这个小项目，我有几个问题：

什么是好的手动设计创建应用程序？ Microsoft Word 并没有完全削减它。
作为开发人员，您需要了解哪些内容才能对表单、报表、表格或其他 Access 对象等内容进行更改？
还有什么我错过的吗？有什么陷阱吗？

【问题讨论】：

我想说作为一名开发人员，我更喜欢良好的代码注释、统一的命名约定和良好的设计，而不是我可能永远不会阅读的文档。当您说“没有先验领域知识”时，不清楚您是指 Access 还是特定应用程序。如果是前者，祝你好运——你可以写一本书。如果是后者，请看我的第一条评论！
我的意思是，企业作为“领域知识”来源的运作方式。我花了几周时间了解了很多的怪癖、意外的业务规则和其他行为，这些都与数据库的设置方式和应用程序整体的工作方式极为相关。
问题是这类文档一旦完成就很少更新。也许用户创建的 Wiki 的想法将是一个想法。这个想法是任何新用户总是在 wiki 中发布他们的问题，然后得到答案并更新它们。他们必须有时间这样做。另外，为什么不在 Access 应用程序中执行此操作。创建一个表格，其中一个字段按表单名称和另一个备注字段。每个表单都有一个按钮，该按钮针对该表打开一个表单，创建/更新与该表单对应的记录。然后用户在此处更新备注字段。
大部分情况下这是一个低维护程序。对于任何类型的问题，已经有适当的机制（并且该文档应该对此进行补充）。 wiki 或“错误”表不适用，但这是个好主意。此外，该程序只有 3 个主要用户和一些辅助用户。
一份应用说明文档，其中包含特定于应用程序的领域知识，并且是最后一个开发人员在工作过程中获得的，这听起来是个好主意。除了一堆松散组织的笔记之外，我看不到其他任何东西。我做第二个托尼的维基推荐。这是捕获和维护此类信息的一种非常好的方法（尽管不一定适用于每个项目）。

标签： ms-access documentation manual

【解决方案1】：

您可以从使用 MZ-Tools 插件为 VBA 生成一些自动代码文档开始。同一个插件可以帮助您清理未使用的变量声明、生成行号、重新排序模块内的过程等。

记录表单更加困难。我的建议是保留屏幕截图，以及通过未记录的 application.saveAstext 方法获得的 .txt 文件。

【讨论】：

感谢 MZ-Tools 的提示。还有其他类似的 MS-Access/VBA 工具吗？此外，此应用程序中的 VBA 代码量几乎为零。 all 几乎都在 Access 对象中。

【解决方案2】：

根据我的经验，与使用主流语言的程序相比，基于 Access 和 VB6 的程序受到更多代码复制和技术债务的困扰。我不确定为什么。也许这是 Access 作为“原型”或“玩具”数据库的本质（尽管正确生成时它可能非常强大）。

如果我必须在花费时间编写文档和花费时间减少技术债务之间做出选择，例如通过重新模块化、消除重复代码、拆分长函数等，我会选择后者。可维护性和可读性的改进会更大。

【讨论】：

我会说这是 Access 如此易于使用的结果，以至于对最佳编程实践一无所知的人能够在其中创建应用程序。网络上有这么多“标签汤”，这不是 Access 的错，也不是 HTML 的错——这是功能而不是错误。
不过，我会支持您的实际建议 - 与彻底解释意大利面条链之间的关系相比，为了可维护性进行重构会更好地利用开发人员的时间！
@David：当我在高中和大学一年级时，我为那些编写应用程序但对数据库规范化一无所知的人修复数据库获得了补充收入。
@David，不幸的是，几乎所有应用程序都在 Access 对象中，而不是 VBA，除了默认生成的用于打开报告/表单的内容。
@Uri：我今年高中毕业 30 年了，我仍然靠修复由不知道的人创建的 Access 数据库谋生他们在做什么。这不是 Access 的缺陷——它实际上是其最大的优势之一，因为它使那些没有高水平专业知识的人能够创建有用的东西。

【解决方案3】：

我知道这已经关闭了很长时间，但我不能不加我的 2 美分：
在提到的案例中，我认为最有用的文档是功能文档（在理想世界中开始开发之前应该已经存在）。
其次是代码本身，包括 VBA 以及可以在 Access 和 SQL Server 中设置的字段描述。
第三是一个（或一组）漂亮的数据库图。完成后，新开发人员可以使用他最喜欢的工具生成所有其余内容。
说到工具，我特别喜欢和推荐：

MZ 工具：专门用于轻松查找哪些例程调用了您正在查看的例程
智能缩进：正确缩进代码。试图阅读严重缩进的代码让我感到恶心
SqlSpec：（不是免费的）为大多数数据库引擎生成数据库本身的 HTML 文档

【讨论】：

-1 ?请评论为什么这样我们都可以学习！
我讨厌人为-1，无缘无故。我认为你的 cmets 很有用。也许不是最终答案，但不是投反对票的理由。

【解决方案4】：

您是否尝试过使用内置的数据库记录器？它将打印出所有表、索引、表单、控件、控件的每个属性。代码、使用的 sql 以及其他任何东西。这会导致大量但只是大量的打印输出。然而，虽然它会在这个过程中杀死几棵树，但它确实是给老板留下深刻印象的好方法。

【讨论】：

是的，我看过它，就像你说的，结果是巨大的。由于这些表没有与 FK 正式链接，因此它错过了很多这些关系。当它生成超过 200 页时，它并不是最棒的工具 XD。
如果您花时间不仅要记录应用程序，而且要实施适当的参照完整性，那么必须从事该项目的未来开发人员会感谢您。而且，是的，它可能需要大量的数据按摩来修复或删除孤立的记录。当我被雇用来接管由不那么出色的开发人员创建的应用程序时，我已经这样做了无数次。这通常是我在进行任何实际工作以增强应用程序本身之前要做的第一件事。在一个背后有蹩脚的数据架构的前端工作就像试图擦亮一个粪便。
是的，这个小项目有两个阶段。记录当前项目的现状，然后我自己创建一个正确制作的第二个版本，这很可能是一次冒险。
值得记录你要用更好的东西替换的东西吗？
是的，这将是几个月。 @David-W-Fenton 如果你能总结一下你在 cmets 中的想法作为答案，我会接受。