内部工具的“最后一公里”：如何进行用户体验？

在年初的《开发者体验——内部工具的“最后一公里”》一文中，我们讨论了什么是用户体验？如何设计用户体验？以及开发者体验的六大要素？在上一篇文章中，我们介绍了文档体验的设计，结合最近学习某项技术的糟糕开发体验，重新思考了一个好的错误呈现应该是什么样子。

在开始之前，让我们换个角度思考一下开发人员是如何处理错误的？

开发人员如何处理错误？

在经典的笑话场景中，一旦开发者收到错误，将通过以下三种方式解决：

所以，在模式方面，我们应该能够满足前两个场景的需求：告诉开发者足够多的错误信息，让开发者可以寻求帮助。

比如我们遇到：Segmentation fault (core dumped)错误，就是由于内存操作不当造成的，比如空指针、野指针读写操作、数组越界访问、常量破坏等。遇到这类问题，如果返回的错误信息太少，需要细化潜在的错误原因，大海捞针解决。因此，debug成为了此时最好的解决方案之一。

基本的错误处理机制可以告诉开发者，可以尝试用–help来解决：

hint: (e.g., 'git pull ...') before pushing again.
hint: Seethe 'Note about fast-forwards'in'git push --help'fordetails.

一个优秀的错误机制可以告诉开发者更多的信息，并建议开发者使用类似的方法来解决它。

出色的错误处理示例

这里主要介绍两种情况，一种是Rust语言，一种是Scoop（Windows下的命令行安装程序）。

Rust 语言示例

在我用过的大多数语言中，Rust 的编译器可能会抛出最“友好”的异常，毕竟它是一种新时代的语言。因此，在编写 Rust 时脚本错误是什么原因，我们是“编译器驱动的开发”。

先简单写一个缺少main函数的程序，然后运行，会报错：

error[E0601]: `main` functionnot foundincrate `lumos`
--> src/main.rs:1:1
|
1| / pub mod store;
... |
10| |
11| | }
| |_^ consider adding a `main` functionto `src/main.rs`

Formore information about this error, try `rustc --explain E0601`.
error: could not compile `lumos` due to previous error

在这个错误中，它告诉我们：

如果缺少 main 函数，请考虑在 src/main.rs 文件的第 11 行添加一个 main 函数

更多细节可以执行 rustc –explain E0601，其中 E0601 是错误码

在 IDE 中，可以直接用 Rust 语言的插件添加 main 函数。

后来从Rust的源码compiler/rustc_passes/src/entry.rs中的no_main_err函数中可以找到更多细节，这里不再展开。在Rust的编译器中，我们设计了自己的错误码机制，采用错误码+markdown的方式进行展示。执行上述说明参数后，即可读取相关的markdown文件并显示相关内容。因此，在初步总结中，它包括：

独家新闻示例

Scoop 是我从朋友圈看到的一个开源项目，它提供了一个自动化的错误处理解决方案。例如，当我们安装工具和软件时，发生了异常。它将提供：

创建相关问题的链接。一键在 GitHub 上创建对应的 issue

自动化尝试重现该错误。通过 GitHub Action 执行对应的脚本，看看是否有错误。

自动化试图给出解决方案。尝试通过Action给出解决方案，比如版本是否有问题，如果有问题，也可以尝试自动修复。

例子：

有关详细信息，请参阅相应的 GitHub Actions：

虚假渲染的四个要素 (TBC)

我初步梳理了第一版中错误处理的四个要素：

以人为本，信息友好。专为人类而非机器设计脚本错误是什么原因，返回有意义的错误信息，不责备用户（PS：映射回责备用户）

建立学习经验。分步说明，从错误代码到 GitHub 问题邮件组等等。

一致的设计。与 API 错误代码一样，Slack 的 API 设计原则要求与行业、其他产品和 API 保持一致。

避免错误。及时反馈，通过IDE消除，运行时接受，请求确认

基于这四个要素，我们可以思考一些潜在的虚假陈述模式。

错误渲染模式

基于以上原则，我尝试整理了一些相关的模式，将在：.

模式：帮助设计

站在开发者的角度思考问题，当开发者遇到问题时，他们将如何解决。几种常见的方法是：

谷歌搜索。我们是否需要在错误消息中提供足够的信息。

开源项目问题。我们是否直接提供相关问题搜索链接？

邮件表格。我们是否有工具可以一次性收集相关信息，例如日志文件等？

…

针对不同的情况，提供了优化方法，比如命令行语法高亮，方便开发者截图。

模式：自动提供潜在的解决方案

当开发者遇到一些常见问题时，建议用户尝试一些解决方案来解决。这在用户体验上已经被广泛使用，毕竟普通用户是更大的受众。

模式：内置错误代码文档

对于工具，由于安全因素，可能会有部分离线用户。在这种情况下，需要提供一个内置的方法，例如 Rust 中的错误代码文档来解决它。

模式：自动问题管理

如上 Scoop，通过 GitHub Action 搭建自动化机器人，实现问题的自动化处理。

模式：开发者可以贡献

以开源的形式，开发者可以贡献错误的内容。

其他

比如常见的FAQ等，也是一些不错的模式。