【问题标题】:Documentation Generation - What boxes should I aim to tick?文档生成 - 我应该勾选哪些框?
【发布时间】:2011-04-18 00:34:52
【问题描述】:

我正在考虑要求我的团队为即将到来的一些重大项目更彻底地记录他们的代码并减少生活中的痛苦,我正在转向 XML 文档生成器,例如 SandcastleDoxygen 或 @987654323 @。

在评估最佳选择时,我应该牢记哪些主要考虑因素以及哪些经验导致您做出特定决定?

【问题讨论】:

  • 也可以看看docu

标签: asp.net documentation-generation evaluation


【解决方案1】:

对我来说,主要考虑因素是:

  1. 全自动:可以这样设置吗? 无需外部工作 创建或编辑文档。

  2. 完全风格化:文档可以完全风格化吗? 它在 wiki 或 pdf 中看起来很棒 生成后。我应该 能够改变颜色,字体大小, 布局等。

  3. 良好的过滤:我可以只选择我想成为的项目吗 生成。我应该能够 过滤命名空间、文件类型、 类等。

  4. 自定义:我可以包含页眉、页脚、自定义元素吗? 等等。

我发现 Doxygen 可以做到这一切。 我们的工作流程如下:

  1. 开发人员对代码进行更改

  2. 他们会更新刚刚更改的代码上方的文档标签

  3. 我们点击生成按钮

然后,Doxygen 将从代码中提取所有 XML 文档,过滤它以仅包含我们想要的类和方法,并应用我们为它预先制作的 CSS 样式。我们的最终结果是一个内部 wiki,它看起来像我们想要的那样,并且不需要编辑。

额外:我们的所有项目都在各种 git 存储库中。我们将所有这些下拉到一个根文件夹并从该根文件夹生成文档..

有兴趣了解其他人如何进一步实现自动化......?

【讨论】:

    【解决方案2】:
    1. 谁为文档付费?为什么? (系统是否足够稳定,是否增加了足够的价值)
    2. 谁来阅读它,为什么她不使用更有效的沟通渠道? (如果大部分时间/地点距离正确)
    3. 谁来更新它。
    4. 你打算什么时候销毁它? (如果在过去三个月内没有阅读或更新,则自动?)

    比起更多的文档,我更喜欢更好的代码来减轻我的生活痛苦,但我更喜欢场景和单元测试以及高级架构描述。

    [编辑] 编写和更新文档需要花费时间和金钱。 JavaDoc 样式文档对同时可见的代码量有严重的不利影响,对于使用代码的开发人员来说可能是一个好主意,但对于编写它的人来说却不是。

    【讨论】:

    • 嗯?我也相信可读​​的代码,但在我当前的项目中,我们有数百个小部件。为什么我要挖掘源代码来找到它们,然后必须阅读源代码来破译它们的作用?一个带有小部件图片的简单列表会很棒。但不幸的是,我们没有文档,现在这是一场噩梦。文档摇滚。
    • 好吧,然后编写一些代码来生成所有小部件的列表。这听起来很简单。
    • @Stephans:听起来,是的 :) 但它是 6 年前编写的定制引擎。没有什么是简单的。
    猜你喜欢
    • 2011-02-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-12-15
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多