标签 文档 下的文章

Doxygen 是一款广泛使用的开源文档生成工具,它通过代码注释来生成文档。

在试着熟悉别人的代码时,你总希望他们留下的代码注释能对你理解代码有所帮助。同理,无论为了自己还是其他人,编写代码时写注释是好习惯。所有编程语言都有专门的注释语法,注释可以是一个单词、一行文字、甚至是一整段话。编译器或解释器处理源代码时会忽略注释。

注释不能完全取代文档,但是有方法可以使用注释来生成文档。Doxygen 是一个开源的文档生成工具,它能够根据代码注释生成 HTML 或 LaTeX 格式的文档。Doxygen 让你在不用额外操作的情况下创建代码结构概览。尽管 Doxygen 主要是用来给 C++ 生成文档的,它对其它语言同样适用,比如 C、Objective-C、 C#、 PHP、Java 和 Python 等。

要使用 Doxygen,你只需要在源代码中使用 Doxygen 能够识别的语法来写注释。Doxygen 会扫描源码文件,然后根据这些特殊注释生成 HTML 或 LaTeX 文档。下面的示例项目会演示如何使用 Doxygen 注释,以及文档是如通过注释生成出来的。示例代码可从 GitHub 上获得,本文中也将引用 Doxygen 手册及文档 的相关章节。

在 Linux 上安装 Doxygen

在 Fedora 上可以通过软件包的形式安装 Doxygen。打开终端运行命令:

sudo dnf install doxygen

在基于 Debian 的操作系统上,可以通过以下命令来安装:

sudo apt-get install doxygen

使用

安装完 Doxygen 后,你需要在项目中按 Doxygen 可以识别的格式来注释代码,还要提供一个 Doxyfile 配置文件来控制 Doxygen 的一些行为。

注意:如果你用的是 GitHub 上的示例项目,你可以忽略下面一步。

如果 Doxyfile 文件不存在,你可以用 Doxygen 生成一个标准 Doxyfile 模板文件。切换到项目根目录下,运行:

doxygen -g

参数 -g 表示 生成 generate 。现在应该会出现一个名为 Doxyfile 的新文件。通过命令调用 Doxygen:

doxygen

现在应该能会有两个新文件夹:

  • html/
  • latex/

默认情况下,Doxygen 会同时输出 LaTeX 和 HTML 格式的文档。本文主要关注 HTML 文档。你可以在 Doxygen 官方文档的入门小节中找到关于 LaTeX 格式输出的更多信息。

双击 html/index.html 打开 HTML 文件。用空的配置文件生成的文档如下图:

A screenshot of a doxygen generated main page on Firefox. The content field under My Project Documentation is blank.

现在我们试着修改 Doxyfile 文件,并在源代码中添加特殊注释。

Doxyfile 文件

Doxyfile 文件中可以定义大量的可调选项,本文通过介绍示例项目的 Doxyfile 文件我只能覆盖其中很小的子集。

第 35 行:项目名称

你可以在这里指定项目名称,它最终会显示在 页眉 header 和浏览器标签上。

# The PROJECT_NAME tag is a single word (or a sequence of words surrounded by
# double-quotes, unless you are using Doxywizard) that should identify the
# project for which the documentation is generated. This name is used in the
# title of most generated pages and in a few other places.
# The default value is: My Project.

PROJECT_NAME           = "My Project"

第 47 行:项目简介

项目简介会以略小的字号显示在页眉上。

# Using the PROJECT_BRIEF tag one can provide an optional one line description
# for a project that appears at the top of each page and should give viewer a
# quick idea about the purpose of the project. Keep the description short.

PROJECT_BRIEF          = "An example of using Doxygen in C++"

第 926 行:包含子目录

允许 Doxygen 查找源代码和文档文件时递归遍历子目录。

# The RECURSIVE tag can be used to specify whether or not subdirectories should
# be searched for input files as well.
# The default value is: NO.

RECURSIVE = YES

第 1769 行:禁用 LaTeX 输出

如果你只想生成 HTML 文档,可以通过这个开关禁用 LaTeX 输出。

# If the GENERATE_LATEX tag is set to YES, doxygen will generate LaTeX output.

# The default value is: YES.

GENERATE_LATEX = NO

修改完成后,你可以再次运行 Doxygen 来检验修改是否生效了。可以在调用 Doxygen 时使用 -x 选项来查看 Doxyfile 文件的变更项:

A screenshot of the terminal showing the differences, Project Name, Project Brief, Recursive, and status of Generate Latex

通过调用 diff 命令,Doxygen 仅显示当前 Doxyfile 文件和模板文件的差异。

特殊注释

Doxygen 通过扫描源代码文件中的特殊注释和关键字来生成 HTML 文档。示例项目中的 ByteStream 类的头文件可以很好地解释特殊注释的用法。

下面用构造函数和析构函数作为示例:

/*! @brief Constructor which takes an external buffer to operate on
*
* The specified buffer already exist.
* Memory and size can be accessed by buffer() and size().
*
* @param[in] pBuf Pointer to existing buffer
* @param[in] size Size of the existing buffer
*/

ByteStream(char* pBuf, size_t size) noexcept;

特殊注释块有不同的格式风格。我倾向于使用 /*! 开头(Qt 风格),每行前添加 *,以 */ 结束注释块。你可以参考 Doxygen 手册的文档化代码小节,以大致了解不同的风格选项。

Doxygen 注释分两个部分:简要描述和详细描述。它们都是可选的。在上面的例子中的注释块是对紧跟其后的构造函数声明的描述。在 @brief 之后的文本会显示在类概览小节中:

A screenshot of the C++ example of using Doxygen showing the Byte Stream Class Reference. The categories in the list are public member functions, writing (operators for writing to the stream), and reading (operators for reading from the stream)

在空行(空行是段落分隔符)之后是构造函数的实际文档。用 @param[in/out] 关键字标注传递给构造函数的参数,Doxygen 基于此生成参数列表:

Screenshot of the Doxygen example showing the parameters under ByteStream

值得注意的是 Doxygen 为 buffer()size() 方法自动生成了链接。相反,Doxygen 忽略了析构函数前的注释,因为它并没有使用特殊注释:

// Destructor
~ByteStream();

现在你已经看到 Doxygen 的绝大部分功能了。通过使用一种稍微改良的注释格式,让 Doxygen 能够识别它们。通过使用一些关键字,你甚至可以进一步控制格式化。在下一节中,我会进一步介绍 Doxygen 的其它特性。

其它特性

现在几乎所有的工作都可以通过对源代码注释的方式完成。通过一些微调,你可以轻松地优化 Doxygen 的输出。

Markdown 格式

为了进阶的格式化,Doxygen 支持 Markdown 和 HTML 命令。Markdown 速查表可以在 这里 下载到。

项目主页

除了自定义页眉之外,html/index.html 几乎没有其它内容了。你可以通过使用关键字向其中添加一些有意义的内容。因为主页通常不是针对某个源代码文件的,你可以将要显示在主页的内容放到项目根目录下的一个单独文件中。示例项目中就是这样做的,其输出效果如下:

The Doxygen Example Documentation field now contains headings and documentation: Introduction, Running the example, System requirements, and Building the code, with step by step examples and code snippets (all can be found in the example on GitHub)

自动链接生成

上面已将提到了,当你引用代码的其它部分时,Doxygen 会自动识别并生成相应链接。但要注意,这要求被引用部分也有文档才行。

更多信息可以在官方文档的自动链接生成中找到。

分组

ByteStream 重载 overload 了的读写流操作符 (<<>>)。在类的概览中可以发现操作符被分为读和写两组。分组是在 ByteStream 的头文件中定义的。

分组的语法以标记 @{ 开始,以 }@ 结束。在标记范围中的内容都属于这个分组。在 ByteStream.h 中的实现如下:

/** @name Writing
* Operators for writing to the stream
* @{
*/

(...)

/** @}
* @name Reading
* Operators for reading from the stream
* @{
*/

(...)

/** @} */

你可以在官方文档的分组中找到更多相关信息。

LLVM 支持

如果你用 Clang 构建项目的话,可以通过使用 -Wdocumentation 选项让 Clang 对特殊注释进行检查。想了解该特性的更多信息,可以参考 LLVM 用户手册和 Dmitri Gribenko 的展示报告,它们可以在 Clang 网站上找到。

谁在用 Doxygen

Doxygen 是在 1997 年首次发布的。尽管有些年头了,现在仍然有很多项目在使用 Doxygen。比如 NASA 的飞行软件框架 F Prime、图像处理库 OpenCV、包管理器 RPM。你还可以在其它领域发现 Doxygen 语法标记的身影,比如内容管理平台 Drupal 的文档标准中。

注意:Doxygen 输出的 HTML 文档风格类似于九十年代网页。并且它也难以描绘元编程和模板编程架构。在这些情况下,你应该选择 Sphinx 而不是 Doxygen。

(题图:MJ/4d354094-397e-4ac5-a80d-25b9c736ede5)


via: https://opensource.com/article/22/5/document-source-code-doxygen-linux

作者:Stephan Avenwedde 选题:lkxed 译者:toknow-gh 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

提升 DevOps 文档成熟度的过程与达到 DevOps 或 DevSecOps 成熟化的历程是类似的。

为了能在软件迭代交付周期内按时交付优质的文档,DevOps 和 DevSecOps 的文档实践也需要是敏捷的。这与实现 DevOps 类似,只是更偏向自动化和敏捷的内容处理方法。如果文档现在才进入你的机构的 DevOps 讨论,那么是时候让文档实践追上 DevOps 的步伐了。

下面是 DevOps 文档成熟度的四个层次:

第一层:临时且孤立

在最低一级成熟度(最不成熟),文档编制工作没有和 DevOps 开发对齐。开发团队和文档团队按照各自的路线开展工作,常常导致文档落后于开发。在竞争激烈的“云”世界里,因为文档问题而推迟产品发布是不可接受的。

人员

这个阶段的文档编制人员还没有摆脱传统的工作方式。 技术写作 technical writer 人员隶属于一个中心化的单独团队,与开发团队是脱节的。技术写作组和开发团队之间的鸿可能是由多方面原因造成的:

  • 造成团队分裂和孤立的公司政治
  • 团队只是将技术文档视为项目验收清单上的检查项,而不是推动项目成功的资产
  • 事后才雇佣技术写作人员
  • 技术写作的优先级与开发团队的实际情况不匹配

这个阶段,另一个在人员配置上的挑战是如何“界定工作完成”。刚接触敏捷实践的技术写作可能难以适应 CI/CD 工具链和流程。

文档工具和流程

这个阶段的技术写作仍习惯于使用传统的办公工具,比如办公套件和布局程序。这些工具不够敏捷,没有版本控制和内容管理的要求。它们无法与 DevOps 工具链高效集成,不能支撑快速开发。在这个成熟度,技术写作仍然参照遗留的模板和流程。

成果

这个级别交付的文档可能是过时的,甚至缺乏技术准确性的。如果开发团队以 DevOps 的速度推进工作,而技术文档编制却遵循传统的非敏捷流程(使用专有的工具和交付格式),这就很难让文档迭代速度并跟上应用程序的变化。

第二层:实验和试点

DevOps 文档成熟度的第二层是实验/试验阶段。这个阶段是 DevOps 团队主管和技术写作采取行动打造更敏捷的文档实践和工具的第一步。

理想的情况下,这些实验是 相关方 stakeholder 支持的试点项目的一部分。他们能够从文档交付流程的改善以及其与 DevOps 实践的集成中获益。

人员

本阶段的人员可能来自以下三种形式:

  1. 有远见的技术写作为了更好地完成工作,用自己的时间来实验更敏捷的工具。并且向领导层提出更敏捷的文档编制过程的想法。
  2. DevOps 负责人或工程师试用 Hugo 和 Jekyll 等工具,并将这些工具集成到 CI/CD 流水线中。然后 DevOps 小组教授技术写作如何使用它们。
  3. 团队引入了第三方承包商或顾问,他们在 DevOps 文档工具方面具有专业知识,并且了解文档工具适合嵌入到 CI/CD 工具链和 DevOps 生命周期的位置。

文档工具和实践

HugoJekyll 是本阶段开始出现的工具。在这个阶段也出现新的内容策略和技术写作方法。

成果

实验试点阶段理想的成果应该能够“ 落地并推广 land and expand ”。也就是说其它项目组也可以将其付诸实践。

这个阶段的实验也包括内容策略和发布流程上的根本性变化。其它非试点项目组的技术写作可以学习和使用它们。

试点带来的另一个可能的产出是 技术写作招聘流程 的变化。你需要针对 DevOps 和你新引入的文档工具对内部编写人员进行培训。

新的文档工具和流程是此阶段的关键成果,你需要通过演示、状态报告和内部案例研究等方式,将这一成果推给领导层、相关方和其它团队。

第三层:部分自动化和扩展

DevOps 文档成熟度的第三层(部分自动化和扩展)就是“落地并推广”的进一步行动。在这个阶段,其它 DevOps 团队借用试点项目中产生的 DevOps 文档工具和流程,吸取其中的经验教训。

人员

在这个成熟度,技术写作和 DevOps 团队开始更紧密的协作。招聘新的技术写作主要关注具有 DevOps 环境经验的人选。

工具和文档实践

技术写作开始从抛弃传统的工具和流程,转到更敏捷的文档工具上,比如:

在这个成熟度,技术写作也负责调整遗留的文档实践。

成果

DevOps 文档工具和实践超越试点项目,成为标准实践。在这个成熟度,随着新团队使用新的文档工具和流程,持续学习是必不可少的。

第四层:完全采用

在最高一级的 DevOps 文档成熟度(完全采用且自动化)所有工具、实践和流程已经到位,以支持将文档为项目中的高优先级事项。要达到这一成熟度,需要不断实验、迭代和团队协作。

人员

完全自动化使 DevOps 团队与技术写作之间的协作更紧密。这一阶段的标志是,技术写作牢牢地融入到项目团队的工作流程中。文档工具的维护工作由一些大型企业负责,它们拥有专职维护 DevOps 工具链的工程师。

文档工具和实践

在这个成熟度,技术写作统一采用 Markdown 语言和自动化工具。

成果

本阶段的成果是一套完整的工具和实践,它们支持自动化在线文档发布。技术写作者可以按需发布和重新发布文档,以支持迭代开发流程。

持续学习是这个阶段的另一项成果。技术写作和工具链维护者寻找改进自动化和流程的方法,以帮助文档实践。

总结

提升 DevOps 文档成熟度的过程跟达到 DevOps 或 DevSecOps 成熟化的历程是类似的。我希望行业能够将更灵活的文档实践和工具作为公司推进 DevOps 进程中的一个部分。提高 DevOps 文档成熟度应该作整体 DevOps 成熟化甚至 DevOps 到 DevSecOps 转型的一部分。

(题图:MJ/154429b7-bdfc-4b34-9a81-55d9fe33ab07)


via: https://opensource.com/article/22/2/devops-documentation-maturity

作者:Will Kelly 选题:lujun9972 译者:toknow-gh 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

文档对于开源软件项目至关重要。我们询问了我们的贡献者,他们在文档编写中最喜欢使用的标记语言是什么。

文档很重要,而易读的文档更重要。在开源软件世界中,文档可以告诉我们如何使用或贡献一个应用程序,就像 游戏 的规则书一样。

有很多不同类型的文档:

  • 教程
  • 操作指南
  • 参考指南
  • 软件架构
  • 产品手册

我们向一些贡献者询问了他们的技术文档工作流程,他们更喜欢使用哪种标记语言,以及为什么会选择其中一种。以下是他们的回答。

AsciiDoc

过去几年中,Markdown 一直是我的标准语言。但最近我决定尝试一下 AsciiDoc 。这种语法并不难,我在 Linux 桌面上的 Gedit 就支持它。我计划暂时坚持使用它一段时间。

—- Alan Formy-Duval

就低语法标记语言而言,我更喜欢 AsciiDoc。我喜欢它,是因为其转换过程一致且可预测,没有令人困惑的“口味”变化 。我还喜欢将它输出为 Docbook,这是一种我信任其持久性和灵活性的标记语言,它有大量的语法标记。

但“正确”的选择往往取决于项目已经在使用什么。如果项目使用某种口味的 Markdown,我就不会使用 AsciiDoc。嗯,公平地说,我可能会使用 AsciiDoc,然后使用 Pandoc 将其转换为草莓味的 Markdown。

当然,我认为 Markdown 有其应用的时间和场合。我发现它比 AsciiDoc 更易读。AsciiDoc 中的链接是这样:

http://example.com [Example website]

而 Markdown 中的链接是这样:

[Example.com](http://example.com)

Markdown 的语法直观,以读取 HTML 的方式呈现信息,大多数人都以相同的方式解析此类数据(“Example website……哦,那是蓝色的文本,我将悬停一下以查看它指向哪里……它指向 example.com”)。

换句话说,当我的受众是人类读者时,我通常会选择 Markdown,因为它的语法简单,但仍具有足够的语法可以进行转换,因此仍然是一种可接受的存储格式。

虽然像 AsciiDoc 这样简洁的语法看起来更令人吃惊,但如果我的受众是要解析文件的计算机,我会选择 AsciiDoc。

—- Seth Kenlon

reStructuredText

我是 代码即文档 的忠实支持者,它将开发者工具融入到内容流程中。这样可以更轻松地进行高效的审查和协作,尤其是如果工程师是贡献者。

作为一个标记语言的行家,我在 O'Reilly 写了整整一本关于 AsciiDoc 的书,还使用 Markdown 在各个平台上发布了上千篇博文。但目前,我转向使用 reStructuredText,并维护一些相关工具。

—— Lorna Mitchell

不得不提到 reStructuredText。在我大量使用 Python 编程时,它已成为我的首选。它也是 Python 长期以来用于文档源码和代码注释的标准。

与 Markdown 相比,我喜欢它不会受到非标准规范的困扰。话虽如此,当我处理更复杂的文档时,确实还得使用许多 Sphinx 的功能和扩展。

—— Jeremy Stanley

HTML

能不用标记语言我就不用。

不过,我发现 HTML 比其他标记语言更易于使用。

—— Rikard Grossman-Nielsen

对我来说,撰写文档有各种方式。这取决于文档将要放在何处,是作为网站的一部分、软件包的一部分,还是可下载的内容。

对于 Scribus 来说,其内部文档采用 HTML 格式,因为需要使用内部浏览器来访问。对于网站,可能需要使用维基语言。而对于可下载的内容,可以创建 PDF 或 EPUB 格式。

我倾向于在纯文本编辑器中编写文档。我可能会使用 XHTML,以便将这些文件导入到像 Sigil 这样的 EPUB 制作工具中。当然,对于创建 PDF,我会使用 Scribus,虽然我可能会导入用文本编辑器创建的文本文件。Scribus 具有包含图形并精确控制其布局的优势。

Markdown 从未吸引我,我也从未尝试过 AsciiDoc。

—— Greg Pittman

我目前正在使用 HTML 撰写大量文档,所以我要为 HTML 代言一下。你可以使用 HTML 创建网站或创建文档。请注意,这两者实际上并不相同 —— 当你创建网站时,大多数设计师关注的是呈现。但是当你编写文档时,技术作者应该专注于内容。

当我用 HTML 撰写文档时,我遵循 HTML 定义的标签和元素,并不关心它的外观。换句话说,我用“未经样式化”的 HTML 编写文档。稍后我总是可以添加样式表。因此,如果我需要强调文本的某一部分(比如警告),或者给单词或短语加重语气,我可能会使用 <strong><em> 标签,像这样:

<p><strong>警告:激光!</strong>不要用你剩下的那只眼睛看向激光。</p>

或者在段落中提供一个简短的代码示例,我可能会这样写:

<p><code>puts</code> 函数将一些文本输出给用户。</p>

要在文档中格式化一段代码块,我使用 <pre><code>..</code></pre>,如下所示:

void
print_array(int *array, int size)
{
  for (int i = 0; i < size; i++) {
    printf("array[%d] = %d\n", i, array[i]);
  }
}

HTML 的好处在于你可以立即在任何 Web 浏览器中查看结果。而你使用未经样式化的 HTML 编写的任何文档都可以通过添加样式表来美化。

—— Jim Hall

意料之外的答案:LibreOffice

在上世纪 80/90 年代,当我在 System V Unix、SunOS,最后是 Solaris 上工作时,我使用了 nrofftroff 和最终的 groffmm 宏。你可以了解一下使用 groff_mm 的 MM(前提是你已经安装了它们)。

MM 并不是真正的标记语言,但它感觉像是。它是一套非常语义化的 troff 和 groff 宏。它具备标记语言用户所期望的大多数功能,如标题、有序列表等等。

我的第一台 Unix 机器上也安装了 “Writers' Workbench”,这对我们组织中需要撰写技术报告但没有特别进行“引人入胜”写作的许多人来说是一个福音。它的一些工具已经进入了 BSD 或 Linux 环境,比如样式(style)、用词检查(diction)和外观(look)。

我还记得早在上世纪 90 年代初期,Solaris 附带了一个标准通用标记语言(SGML)工具,也可能是我们购买了这个工具。我曾经使用它一段时间,这可能解释了为什么我不介意手动输入 HTML。

我使用过很多 Markdown,我应该说是“哪种 Markdown”,因为它有无数种风格和功能级别。正因为如此,我并不是 Markdown 的铁杆粉丝。我想,如果我有很多 Markdown 要处理,我可能会尝试使用一些 CommonMark 的实现,因为它实际上有一个正式的定义。例如,Pandoc 支持 CommonMark(以及其他几种)。

我开始使用 AsciiDoc,相比于 Markdown,我更喜欢 AsciiDoc,因为它避免了“你使用的是哪个版本”的讨论,并提供了许多有用的功能。过去,让我对 AsciiDoc 感到困扰的是,有一段时间似乎需要安装 Asciidoctor,这是一个我不太想安装的 Ruby 工具链。但是现在,在我所用的 Linux 发行版中,有了更多的实现方式。奇怪的是,Pandoc 可以输出 AsciiDoc,但不支持读取 AsciiDoc。

那些嘲笑我不愿意为 AsciiDoc 安装 Ruby 工具链,却乐意安装 Pandoc 的 Haskell 工具链的人……我听到你们的笑声了。

我羞愧地承认,我现在主要使用 LibreOffice。

——Chris Hermansen

现在就编写文档吧!

文档编写可以通过多种不同的途径来完成,正如这里的作者们展示的那样。对于代码的使用方法,特别是在开源领域,进行文档编写非常重要。这确保其他人能够正确地使用和贡献你的代码。同时,告诉未来的用户你的代码提供了什么也是明智之举。

(题图:MJ/9543e029-322d-479f-b609-442abc036b73)


via: https://opensource.com/article/22/12/markup-languages-documentation

作者:Opensource.com 选题:lkxed 译者:ChatGPT 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

建立良好的文档可能是困难的,但它对有效的沟通至关重要。遵循这个框架来编写并与正确的人分享文档。

成功和可持续的项目,与那些消失无踪的项目有什么不同?答案是 —— 社区。社区是开源项目的发展动力,而文档是构建社区的基石之一。也就是说,文档的意义不仅仅在于文档本身。

建立好的文档可能很困难。用户不愿意阅读文档,因为它不易查找,它很快就过时了,它冗长,或者它不全面。

开发团队不写文档,因为他们陷入了“对我来说显而易见,所以对所有人都显而易见”的陷阱。他们不写,因为他们忙于开发项目。要么是需求变化太快了,要么是开发得还不够快。

但是好的文档仍然是团队和项目之间最好的沟通工具。考虑到项目随着时间的推移往往会变得更大,这一点尤其重要。

文档可以是团队或公司内部的唯一真理。这在协调人们朝着共同的目标前进,以及在人们转移到不同的项目时保留知识方面非常重要。

那么,要如何为一个项目写出合适的文档,并与正确的人分享呢?

什么是成功的社区文档?

要想在你的社区文档编写中取得成功,你需要:

  • 规划你的路径
  • 使其清晰简单
  • 灵活变通,根据具体情况调整路径
  • 做版本控制

图片展示了建立文档的整个流程

灵活并不意味着混乱。许多项目之所以成功,就是因为它们组织得很好。

James Clear(《 原子习惯 Atomic Habits 》一书的作者)写道:“你并不是提升到了你目标所在的水平,而是降低到你整个系统所在的水平。”一定要组织好过程,使水平足够高,才能取得成功。

设计流程

文档本身就是一个项目。你可以把写文档当作写代码一样。事实上,文档可以是一个产品,而且是一个非常有价值的产品。

这就意味着你可以采用与软件开发相同的流程:分析、获取需求、设计、实现和维护,把文档作为你的一个流程对待。

在设计流程时,要从不同的角度考虑。不是所有的文档都适用于所有人。

大多数用户只需要一个了解项目概况的文档,而 API 文档则是留给开发者或高级用户的。

开发者需要了解库和函数的文档。用户则更需要看到示例、操作指南,和项目与其他软件相配合的架构概述。

图片展示了编写文档时的不同视角

总之,在创建任何流程之前,你必须确定你需要什么:

  • 关注的群体: 包括开发者、集成商、管理员、用户、销售、运营、高管
  • 专业水平: 要考虑到初级、中级和高级用户
  • 详细程度: 既要有高层级的概述,也要有技术细节,所以要考虑如何呈现这些内容
  • 路径和入口: 人们如何找到文档,如何使用文档

当你思考这些问题时,它可以帮助你构建你想通过文档传达的信息的结构。它定义了文档中必须包含的内容的清晰指标。

下面是如何围绕文档建立一个流程的方法。

编码约定

代码本身应该有意义。文档应通过良好的类名、文件名等来表达出来。通过思考以下内容,创建通用的编码标准和自我注解的编码过程:

  • 变量命名约定
  • 通过使用类、函数命名方案使名称易于理解
  • 避免深度嵌套,或 根本不嵌套
  • 不要简单地复制和粘贴代码
  • 不应使用长方法
  • 避免使用幻数(改用常量)
  • 使用提取的方法、变量等
  • 使用有意义的目录结构、模块、包和文件名

开发时测试

测试不仅仅是关于代码应该如何工作。它还涉及如何使用 API、函数、方法等。编写良好的测试可以揭示基本用例和边缘用例。甚至还有一种 测试驱动开发 的实践,专注于在代码开发之前创建测试用例(应该测试什么以及如何测试的分步场景)。

版本控制

版本控制(即使是对文档进行版本控制)可以帮助你跟踪更改的逻辑。它可以帮助你回答为什么这么修改。

确保提交期间的注释能解释为什么进行更改,而不是进行了哪些更改。

编写文档过程越吸引人,就会有更多的人参与其中,为它添加创造力和乐趣。你应该通过以下方式考虑文档的可读性:

  • 软件代码约定
  • 图表和图形(也通过文字进行解释)
  • 思维导图
  • 概念图
  • 信息图表
  • 图片(突出显示重要的部分)
  • 短视频

通过使用不同的交流方式,你可以提供更多的方式来参与文档。这有助于防止误解(不同的语言,不同的含义)和有助于通过不同的学习方式进行学习。

以下是一些用于创建文档的软件工具:

  • Javadoc、Doxygen、JsDoc 等: 许多语言都有自动化的文档工具,以帮助捕获代码中的主要功能
  • Web 钩子和 CI/CD 引擎: 允许持续发布文档
  • Restructured Text、Markdown、Asciidoc: 文件格式和处理引擎,帮助你从纯文本文件中生成美观且实用的文档
  • ReadTheDocs: 是一个可以和公共 Git 存储库联动的文档托管主机
  • Draw.io、LibreOffice Draw、Dia: 制作图表、图形、思维导图、路线图、计划、标准和指标等
  • Peek、Asciinema: 记录终端命令操作
  • VokoscreenNG: 录制屏幕和鼠标点击操作

文档很重要

编写文档的过程和协议与项目本身同样重要。最重要的是,它把项目的信息和项目的创造传达到位,更加令人兴奋。

快速进入项目和流程,以及了解一切是如何工作的,是文档一个重要的功能。它有助于确保众人持续参与。通过在团队中构建一种“语言”,可以简化流程,更清晰地理解所要做的事情。

文档旨在传达价值,即无论是通过团队成员还是通过应用程序的用户的言行,来展示出某些东西。

要将这个过程视为一个连续的整体,并在其中融合使用沟通、流程和文档的方式。

图片展示了文档作为一种沟通的过程

文档是一种沟通手段。

(题图:MJ:document development illustration in high resolution, very detailed


via: https://opensource.com/article/23/3/community-documentation

作者:Olga Merkulova 选题:lkxed 译者:alim0x 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

让你的开源项目文档充满活力,从而吸引各种经验水平的用户。

开源软件项目通常拥有非常多样化的用户人群。有些用户非常擅长使用该系统,并且只需要很少的文档。对于这些实力派用户,文档只需要提供必要的提示,并且可以包含更多的技术信息,比如说在 Shell 中运行的命令行。有些用户可能只是初学者。这些用户需要更多的帮助来设置系统并学习如何使用它。

写一个同时适合这两个用户群体的文档是令人生畏的。网站文档需要在 “提供详细的技术信息” 和 “提供更多的概述和指导” 之间寻求一个平衡。这是一个很难找到的平衡。如果你的文档不能同时满足这两个用户人群,那么考虑一下另外一个选择 —— 动态文档。

探索在网页中添加一点 JavaScript 使用户可以选择自己想看的内容。

构建你的内容

你可以把例程添加的你的文档中需要同时满足 专家 expert 初学者 novice 的地方。在这个例程中,我们可以使用一个虚构的名为 AwesmeProject 的音乐播放器。

你可以用 HTML 编写一个简短的安装文档,通过 HTML 的 class 功能同时为专家和初学者提供操作指南。

例如,你可以用下面的代码来为专家定义一个段落:

<p class="expert reader">

这同时指派了 “专家类” 和 “读者类”。你可以用下面的代码来为初学者创建一个相同的段落。

<p class="novice reader">

完整的 HTML 文件同时包含初学者的段落和专家的段落。

<!DOCTYPE html>

<html lang="en">

<head>

<title>How to install the software</title>
</head>

<body>

<h1>How to install the software</h1>

<p>Thanks for installing AwesomeProject! With AwesomeProject,
you can manage your music collection like a wizard.</p>

<p>But first, we need to install it:</p>

<p class="expert reader">You can install AwesomeProject from
source. Download the tar file, extract it, then run:
<code>./configure ; make ; make install</code></p>

<p class="novice reader">AwesomeProject is available in
most Linux distributions. Check your graphical package manager and search for AwesomeProject to install it.</p>

</body>

</html>

例子中的 HTML 文档没有与之关联的样式表,所以浏览器中会显示所有的段落。

Image of html in black text.

我们可在文档中添加一些简单的样式来为 读者 reader 专家 expert 或者 初学者 novice 突出任何元素。为了使不同的文本更容易区分,让我们把读者类的背景颜色设置成米白色,专家类的字体颜色设置为深红色,初学者的字体颜色则设置为深蓝色。

<!DOCTYPE html>

<html lang="en">

<head>

<title>How to install the software</title>

<style>

.reader {
background-color: ghostwhite;
}

.expert {
color: darkred;
}

.novice {
color: darkblue;
}

</style>

</head>

<body>

<h1>How to install the software</h1>

当你在浏览器中查看这个网页时,这些样式有助于突出这两个段落。安装指导的所有段落都有一个米白色背景,因为他们都有 读者 reader 这个类。第一个段落的字体是深红色的,这是由 专家 expert 这个类定义的。第二个段落的字体是深蓝色的,则是由 初学者 novice 这个类定义的。

Image of html in red and black text.

添加 JavaScript 控件

这些类的应用,使你可以添加一些简单的 JavaScript 函数,只显示其中一个内容块。一个方法是,首先给所有的读者类元素设置 display:none 。这会将内容隐藏,使其不会在页面上显示。然后,用函数将你想显示的类元素设置为 display:block :

<script>
function readerview(audience) {
  var list, item;
  // hide all class="reader"
  list = document.getElementsByClassName("reader");
  for (item = 0; item < list.length; item++) {
    list[item].style.display = "none";
  }
  // show all class=audience
  list = document.getElementsByClassName(audience);
  for (item = 0; item < list.length; item++) {
    list[item].style.display = "block";
  }
}
</script>

要在 HTML 文档中使用这个 JavaScript,你可以吧这个功能附加到一个按钮上。由于 readerview 函数需要一个 听众 audience (这应该是相对那个虚拟音乐播放器来说的)作为参数,你可以使用你想查看的听众类别来调用这个函数,可以是 读者 reader 专家 expert 或者 初学者 novice

<!DOCTYPE html>
<html lang="en">
<head>
<title>How to install the software</title>
  <style>
    .reader {
    background-color: ghostwhite;
    }

    .expert {
    color: darkred;
    }

    .novice {
    color: darkblue;
    }
  </style>
</head>

<body>

<script>
function readerview(audience) {
  var list, item;

  // hide all class="reader"
  list = document.getElementsByClassName("reader");

  for (item = 0; item < list.length; item++) {
    list[item].style.display = "none";
  }

  // show all class=audience
  list = document.getElementsByClassName(audience);

  for (item = 0; item < list.length; item++) {
    list[item].style.display = "block";
  }
}
</script>

<h1>How to install the software</h1>

<nav>

<button onclick="readerview('novice')">view novice text</button>

<button onclick="readerview('expert')">view expert text</button>

</nav>

<p>Thanks for installing AwesomeProject! With AwesomeProject,
you can manage your music collection like a wizard.</p>

<p>But first, we need to install it:</p>
<p class="expert reader">You can install AwesomeProject from
source. Download the tar file, extract it, then run
<code>./configure ; make ; make install</code></p>

<p class="novice reader">AwesomeProject is available in
most Linux distributions. Check your graphical package
manager and search for AwesomeProject to install it.</p>

</body>
</html>

有了这些设置,用户可以在网页上选择他们想看的文本。

Image of window that allows you to select between novice and expert text.

点击任何一个按钮都将只显示用户想要阅读的文本。例如,如果你点击了 “ 阅读初学者内容 view novice text ” 按钮,你就只会看到蓝色段落。

Image showing blue text when you press the novice button.

点击 “ 阅读专家内容 view expert text ” 按钮,就会隐藏初学者文本,只显示红色的专家文本。

Image of red text after the expert button is clicked.

将此扩展到你的文档

如果你的项目需要你为不同的听众编写多个操作文档,你可以考虑使用这种方法,一次发布,多次阅读。为所有的用户编写一个文档,是每个人都能很容易的发现和分享你项目的文档。而你也不必同时维护尽在细节上有所不同的多个文档。


via: https://opensource.com/article/22/12/dynamic-documentation-javascript

作者:Jim Hall 选题:lkxed 译者:duoluoxiaosheng 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

不想让文档成为事后的想法?或许你该尝试一下全新的写作方式。

很多工程师与手工艺者都对他们使用的工具有特别的要求。为了顺利的完成工作,你需要最好的工具和使用它们的技巧。软件开发中最好的工具在应用到其他的数字创作领域中也可以是很强大的。 文档即代码 Docs as Code 的方式就是很好的例子。“文档即代码”意味着使用与代码开发相同的工具和工作流来撰写文档。文档即代码的支持者认为,这样的方式可以在降低写作者的工作量的同时,也带来了更好的文档。

文本格式与源文件控制

从传统的写作平台切换到文档即代码方式时,最主要的调整是将写作内容保存在基于文本的标记格式中。这一转变使得基于纯文本的工具都适用于文档写作。无论你选择 DocBookMarkdown 或者其他的标记语言,从只使用一种工具到使用一种标准格式配合多种工具是一种巨大的转变。

找到支持你的工作流程的工具是非常重要的。很多开发者在文档即代码项目中使用他们的 代码编辑器。因为他们已经是这些工具的高阶用户,一切都很顺利。而找到适合团队里其他专业人员,比如技术撰稿、编辑、信息架构师和文档产品责任人的工具可能需要一番努力。这里有一些选项可供参考:

  • 各种 优秀的 Markdown 编辑器 之一
  • 附带良好的预览工具的代码编辑器可能更适合非程序员
  • 流行的 Git 托管服务的网页界面尤其适用于偶尔有需要的贡献者

一旦内容以标记语言的格式安全地保存,就可以使用 Git 这样的版本控制进行管理。Git 相比大多数文档平台具有更多的功能:

  • 清晰详细的文档版本历史:谁在什么时候改变了什么。如果你有良好的提交信息惯例,你甚至可以了解到为什么会有这样的变更。
  • 简明的并行修改过程。在 Git 中使用分支工作意味着任何人可以做出他们想要的任何改变,并在最后合并所做的变更。
  • 先进的协作与审查工具。所有的源代码管理平台都被设计成支持详细审查每一个变更,并根据需要进行讨论,使每个人都确信这个变更可以继续进行。
  • 自动质量检查,比如拼写检查和链接检查。这不仅节省了时间,而且可以发现可能遗漏的错误。

源代码管理有很多优点。但要记住,如果你准备入门源代码管理,它有一定的学习曲线。这是一些有助于撰写者入门的优秀的 学习资源文章。你也可以让具有好奇心的文档撰写者自行寻找对他们有用的学习材料,而不是请你的工程师来培训他们。(问我是怎么学会的? —— 当然是通过艰苦的方式!)

拉取请求和评审循环

所有的源代码管理平台都围绕 拉取请求 Pull Request 这一概念设计的,这有时也称为 合并请求Merge Request:有时候,某个人或某个团队先将一系列改变整合到一起,然后请求把这些修改拉到主项目中。不过从许多方面来说,在文档中一次处理多个变更比在代码中更容易。改变一篇文章中的某个地方,比更改代码并发现有其它几个地方依赖它,副作用更小。

最强大的协作工具是 diff,它可以通过一个易于理解的方式展示旧版本与新版本之间的差异。该工具有许多不同的版本,可以使比较视图更易于查看:双栏模式、行内模式,甚至是渲染过的 Markdown 模式。团队中的每一个成员都可以选择最适合他们的工具。举例而言,网页视图通常用于查看细微变更,而对于更大的变更,我习惯于使用 vimdiffMeld 在本地浏览。

评审意见可以被添加到整个修改中,也可以添加到拟议的变更的个别行中。一些项目限制了行的最大长度,即硬换行,或者一行一句,以使得向文本的特定的部分添加注释更加容易。可以添加进一步的修改与评论,直到审查过程结束,修改被接受。由于拉取请求在项目仓库以队列形式展示,这是一种很好的方式,可以展示目前正在进行的任务以及需要进行检查操作的任务。diff 工具使得评审人员更方便地添加他们的思考。尤其是你在与技术受众工作时,你可以通过他们日常使用的工具获得来自他们的评论。

持续集成与部署

以纯文本形式提供你的文档的源代码有很多益处,你可以轻易找到每一个需要修改的位置,你可以使用现有的诸如 wcgreptree 之类的工具,来处理潜在的大型文档集。当你将这些与源代码管理平台结合起来之后,你可能获得更多的可用工具,并且它们都是开源的。

另一个工作流程上的巨大提升是持续部署的能力。简单来说,这意味着,每当一个拉取请求被合并到主项目中,项目可以直接自动化部署到位。如果这个变更足够好,就可以放进项目中,它也足够好到可以在放到文档网站上帮助你的读者。典型情况下,持续部署是配置在一台单独的自动化服务器上的,比如 Jenkins 或者 Git 钩子。不论哪种方式,基于文本的标记语言与文档即代码平台(通常是静态网页生成器,比如 HugoSphinx)结合来生成文档网站,然后自动部署。

在部署之前,同样的自动化流程可以被用于对将要合并的拉取请求进行检查。在一个编程项目中,通过计算机自行进行代码检查、代码测试和其他的质量检查已经习以为常。通过类似 Vale 之类的工具可以对文本进行检查,文档项目也可以同样对待。你也可以添加其他的工具,比如添加一个链接检查器来确保文中所有的链接都是有效的。

用于文档流程的代码工具

被工程师们熟知并喜爱的工具都是非常好的工具,它们同时也可以用于其他类型的项目中。对于文档而言,它们提升了宝贵的效率,尤其是当你希望你的文档与你的团队同步推进的时候。上面讨论到的所有工具都是开源的,你可以亲自尝试,也可以为大型全球团队,亦或者介于两者之间的团队,部署它们。愿你的成文过程和编程过程一样顺畅。


via: https://opensource.com/article/22/10/docs-as-code

作者:Lorna Mitchell 选题:lkxed 译者:CanYellow 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出