我的开发到写作过程

想法

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

刚开始写 Dev.to 文章时，我感到有些不知所措，如果有一篇关于如何撰写文章的教程，就能大大降低入门门槛。现在我已经写了六篇文章，写作也逐渐步入正轨，感觉很舒服，所以想和那些有兴趣尝试撰写技术文章的人分享一下。

我根据自己作为作家的需求调整了这个过程，确保我可以持续地撰写具有特定结构的科技文章，但我认为它对评论文章也同样适用。

准备工作

我把所有文章都保存在 GitHub 代码库中，这样我就可以在多台电脑上访问它们，并随时跟踪更改。就像写代码一样，有时我对修改不满意，想把它们和之前的版本进行比较。一个简单的文件版本管理器就足够了。

文件结构

我把正在发布的文章都放在一个drafts文件夹里。每次发布文章时，我都会在文章开头加上日期，然后把它移到这个published文件夹里，方便整理和存档。这样，如果我想在其他地方发布或者需要修改文章，就能随时查看我的文章和图片记录。

├── README.md
├── drafts
│   ├── more_accessible
│   │   └── main.md
│   └── writing_process
│       └── main.md
├── package-lock.json
├── package.json
└── published
    ├── 2020_10_31_color_migration
    │   ├── hero.jpg
    │   └── main.md
    ├── 2020_11_07_testing_postcss
    │   ├── hero.jpg
    │   └── main.md
    ├── 2020_11_15_marginal_linting
    │   ├── hero.jpg
    │   ├── main.md
    │   └── reviewdog-annotation.png
    ├── 2020_11_16_use_datetime
    │   └── main.md
    ├── 2020_11_22_testing_time
    │   ├── hero.jpg
    │   └── main.md
    └── 2020_11_29_bad_variable_names
        ├── hero.png
        └── main.md

Package.json

我使用 Prettierlint-staged在每次提交后自动格式化文章。这对于.md文件中的任何代码块都特别有用。

// package.json stub with the dependencies and scripts necessary for the commit hooks
{
  "scripts": {
    "lint": "prettier --ignore-path=.gitignore **/*.md",
    "lint:fix": "npm run lint -- --write"
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{js,jsx,css,scss,md}": "prettier --write"
  },
  "devDependencies": {
    "husky": "^4.3.0",
    "lint-staged": "^10.5.1",
    "prettier": "^2.1.2"
  }
}

VSCode

我使用Visual Studio Code来编辑和预览 Markdown 文档。我试过Mark Text和Typora，但都不太适合我——它们对 Markdown 的富文本编辑功能似乎在撤销/重做方面存在问题。

我使用以下 VSCode 插件来辅助写作：

• Spell Right是一款基本的拼写检查工具。
• VSCode Prettier会在每次保存时自动格式化我的代码。
• Write Good鼓励我使用主动语态，并删减不必要的词语。

以下是我的.vscode/settings.json插件配置项目级别：

{
  "editor.rulers": [100],
  "[markdown]": {
    "editor.wordWrap": "bounded",
    "editor.wordWrapColumn": 100
  },
  "editor.formatOnSave": true,
  "write-good.languages": ["markdown", "plaintext"],
  "languageToolLinter.serviceType": "public"
}

流程

创意💡

起初，我每周都很难想出新的文章选题，所以我开始记录一天中突然冒出来的想法。想到什么，我就把它们作为章节添加到我的文档里README.md。为了更深入地探讨这些想法，我会列出想要涵盖的要点。这些要点通常会成为文章的标题。如果电脑不在身边，我会用手机记下要点，README.md稍后再添加到我的文档里。

结构🏗

开始写文章时，我首先会尝试把标题结构写在页面上。这有助于我明确自己想表达的内容，并确保文章行文流畅。这时，我会把文章结构交给我的编辑（对我来说是我的妻子，但你可以找任何人来提供第二意见）。

初稿📝

现在我已经有了思路和结构，是时候开始撰写文章了。除了文章本身，我还会构建演示或测试应用程序来验证技术上的准确性。例如，jest-postcss在撰写《使用 Jest 扩展编写更简洁的测试》一文时，我创建了一个示例代码库，用于演示如何轻松添加新的 Lint 规则。我尽可能地通过 Dev.to 的Liquid 标签嵌入交互式工具（例如 repl.it 和 Code Sandbox），以使文章更具吸引力。

仔细阅读👀

我会先通读一遍，确保所有内容都通顺易懂。这一步会进行大量的修改和段落重组。我通常会把初稿放几个小时或一天，这样我就可以带着全新的思路再来审视它。

听听看🎧

因为我光靠阅读很难发现文章的问题，所以我用Mac的文本转语音功能来听自己的文章。这有助于发现那些难以理解或朗读起来很别扭的措辞。这种方法加上通读功能，可以减少我的编辑在文章上花费的时间——毕竟她是义务帮忙。

高级反馈🚥

这时我会请编辑通读文章，看看有没有什么需要修改的地方或遗漏之处。我尽量不让自己对已经写好的内容过于执着，因为任何部分都有可能被修改。

波兰 ✨

在处理完一些高层次的评论之后，我会请编辑和我一起逐字逐句地通读整篇文章，润色措辞。这样可以确保读者能够轻松理解文章的观点。自从我开始使用Write Good插件后，我们就不再需要花费大量时间来修改被动语态了。

发货！🚢

目前我直接将 Markdown 文件复制到 Dev.to 发布，发布前会先预览检查是否有问题。务必确保 Liquid 标签在发布前能够正常工作，因为它们在 VSCode 的 Markdown 预览中无法正常显示。

英雄图片

醒目的图片能够吸引读者的眼球。它们提供了一个向读者展示文章或作者自身特色的机会。我通常会使用自己拍摄的照片，但对于包含代码的文章，我开始使用Carbon.now.sh，以便帮助读者更清晰地了解文章内容。

这是我文章《停止使用“data”作为变量名》的配图。

结论

这就是我撰写技术文章的整个流程。我希望它能帮助任何想要开始写作的人，让写作过程不再那么令人畏惧。我很想了解大家在写作过程中还使用哪些其他工具、流程或服务。

您还可以查看我的模板库，我会尽量保持其更新，以反映我采用的任何新做法。