是的,但绝对是:
- 链接腐烂将是一个问题,理想情况下,可以从已知目标文档动态生成链接,但可以通过某种形式的配置获取前缀。如果服务器发生更改,则可以通过更新此config元素使旧代码有效。您也可以仅通过更改此前缀配置来使文档在本地可用。
- 版本控制:本着同样的精神,如果可以的话,请一定要在链接中包含版本控制功能,以便链接始终指向正确的文档版本。
- 使文档可编辑类似于Wiki类型的文档站点,您可以在其中动态纠正错误,理想情况下还允许用户在页面上直接发表评论。这将使您的用户更轻松地参与并找到他们所需要的东西,并且您将获得黄金信息以使您的文档保持良好的工作状态,但要确保您定期对其进行监视,并且大多数人都积极参与。
- 生成的模板使您的构建系统直接从代码中的注释生成文档的基本模板。尽管要保持简单,但这将确保每个链接始终指向有效的文档。如果您确实使用Wiki,请确保可以轻松地推送这些模板,并确保可以以与编写代码相同的方式升级文档站点(拥有一个不同于prod网站的dev网站,并且将代码推广到prod网站自动在产品网站中执行插入操作)。
如果您使用Java或.NET开发,则该文档可以包含在jar文件或DLL文件中,并且通过更改前缀,您的代码可以改为在本地获取。
如果您确实选择了wiki方法,我会热烈推荐DokuWiki,因为它很简单,并且它基于平面文本文件,这对于从构建系统进行自动注入非常友好。就是说,我对您的环境或客户不太了解,因此无法真正知道这是否适合YMMV。
我创建的一些最成功的工具采用了类似的方法,其中错误消息针对的是最有可能执行任务的实际用户。这意味着我必须进行大量的异常捕获和包装,以确保错误处于适当的抽象级别。我还确保每个错误消息都将包含最可能的错误源,并指出潜在的解决方案“您是否忘记设置xxxx配置值?”,“确保xxx和yyy通过给它们指定不同的名称不会冲突”等。从发生错误的上下文中将生成XXX和whatnot。
这种方法比较简单,但也有局限性。但是它有一个好处,那就是在需要链接时,始终会存在该文档。
您的方法是下一个发展。复杂得多,但潜在回报也更多。虽然这将是昂贵的,但是如果做得对,将很容易就可以收回成本。