我的书有一个会对我使用“开源”进行连字符处理大喊的大型工具。它运行约5500个自动检查，每次git提交时重建五种格式，如果我稍微暗示我仍然在我离开的工作岗位上，它就会失败。为了一本书。那是一个人写的。我并不是为了这样做而开始的。大多数人开始写作项目时会开启Word或Google文档，而我同样沿着这条道路开始。我甚至尝试了一些专门设计的创作工具，但每个工具与我每天作为开发者使用的工具相比都感觉很劣质。我做了“唯一合理”的事情，把它们都扔掉，用Git、Markdown和CI构建管道写完了整本书。如果你读过我如何过度设计我的家庭网络——两次——这些都不会让你感到惊讶。我已经制作网站几十年，所以这个跨越很短：构建网站的相同工具可以构建书籍，不需要最后一刻的魔法把标准Word文档变成完全成型的书。过程中有失误，但最终，我不会用其他任何方式来写《开放与异步》。以下是我的做法：内容 # 显然，内容本身保存在Git仓库中的Markdown文件中。毕竟，那是我一天中大部分时间待的地方。我使用VS Code，装了几个散文扩展（如下所列）。每一章都是一个单独的Markdown文件，而一个单一的index.yml文件定义了顺序，使重排章节或添加新章节变得容易。实际上，我大部分时间是在iPad上写的——在浏览器标签页中使用Codespaces，配合蓝牙键盘，经常在晚上和周末离开桌子时写作——而Git仓库使得无论我在哪里打开，都能保持同步。我可以专注于文字，而一个坏主意只需一次git回退即可消失。更不用说，我在我的IDE中得到了关于我写作的实时反馈，就像我从ESLint或Prettier处获取代码的实时反馈一样。测试 # 由于内容就是代码，下一个合乎逻辑的步骤就是设置自动化测试。这种像测试代码那样测试散文的方式，我已经争论了好几年；这让我走向荒谬的极端。我以两种方式实现这一点：实时和推送（CI）。实时 # 在本地，当我打字时，我运行了几个VS Code扩展，给我提供实时反馈。具体来说：Markdownlint - Markdown语法和格式一致性 Harper - 语法和词汇选择，完全在设备上 LanguageTool - 语法、标点和风格 Vale - 我自己的风格规则和禁止词汇 Alex - 不敏感或排斥的措辞 Write-good - 弱散文：被动语态、模糊表述、陈词滥调所有六个扩展在CI中也会运行（Alex和Write-good整合到了Vale中；详细如下）。它们共同为一个全面的语法引擎叠加了数百条精心策划的风格规则——所有这些在实时中突出了我的错误，就像红色波浪线标记类型错误一样。每次推送 # 除了在CI中运行那些开源的linter（一些阻塞），我还建立了一个自定义的测试套件：一个独立的Node内容验证器脚本、一个Vitest套件和Playwright规范。验证器是有趣的部分。每个都是几行代码，读取Markdown并推送带有文件和行指针的错误。最喜欢的：我不再在GitHub工作，所以任何声称我仍然这样做的句子都会导致构建失败。// 我在GitHub的时间必须以过去时态呈现——关于它的现在时 // 就业声明导致构建失败。 function validateGitHubTense ( files ) { const patterns = [ //