我的第一次开源贡献：保持代码相关性

之前，我解释了 fork 代码仓库的重要性。 一旦我完成了制作我的第一个开源拉取请求的实际“编写代码”部分，我感觉非常棒。 看起来最困难的部分终于结束了。 更重要的是，我对我编写的代码感到非常满意。

我决定做的一件事（结果证明这是一个极好的选择）是使用 测试驱动开发 (TDD) 来编写代码。 使用 TDD 很有帮助，因为它为我提供了一个起点，以及一种了解我所做的事情是否真正有效的方法。 因为我的背景是构建 Web 应用程序，所以我很少遇到编写没有有形、可见输出的代码的问题。 这种测试优先的方法帮助我实现了飞跃，开始在一个无法手动评估进度的工具上工作。 事实上，我编写了一个清晰的测试也帮助我最终获得了我的拉取请求的批准。 审阅者在他的代码评论中强调了该测试。

另一件让我感觉很棒的事情是，我用大约 20 行代码完成了整个事情。 我从经验中知道，较短的拉取请求更容易审查。 这种短小的代码通常花费的时间更少，并且审阅者可以只专注于更改的少量代码行。 我希望这会增加我的机会，让维护者之一会查看我的工作并对其充满信心。

令我惊讶的是，当我最终将我的分支推送到 GitHub 时，diff 显示我更改了多行代码。 我在这里遇到了麻烦，因为我已经太习惯我常用的开发设置了。 因为我通常在一个单独的项目上工作，所以我几乎没有考虑过我在后台运行的一些工具，这些工具让我的生活更轻松。 罪魁祸首是 prettier，一个代码格式化程序，它会在我保存编辑过的文件时自动修复我所有细微的空格和语法差异。 在我通常的工作流程中，这个工具非常有用。 我合作的大多数开发人员都安装了 prettier，因此我们编写的所有代码都遵守相同的样式规则。

然而，在这个新项目中，样式规则已经被抛诸脑后。 该项目实际上包含一个 eslint 配置，声明应使用单引号而不是双引号。 然而，为该项目做出贡献的开发人员忽略了此规则，并同时使用了单引号和双引号。 与人类不同，prettier 永远不会忽略规则。 当我工作时，它主动将我更改的每个文件中的每个双引号都转换为单引号，从而导致数百个意外的更改。

我尝试了几分钟来删除这些更改，但是因为它们在我工作时一直在持续发生，所以它们被嵌入到我的所有提交中。 然后我性格中 B 型的一面占据了上风，并决定保留这些更改。 “也许这没什么大不了的，”我想。“毕竟他们说他们想要单引号。”

我的错误是将这些不相关的更改包含在我的 PR 中。 虽然从技术上讲我是对的，这不是什么“大不了的事”，但审查我的代码的维护者要求我撤销这些更改。 我最初的直觉，即保持我的拉取请求小而切中要害，是正确的。

这里的教训是，你应该尽可能保持你的更改最小且切中要害。 请注意你拥有的任何可能适用于你的正常工作流程的工具，但如果你正在处理一个新项目，这些工具可能没有那么有用。

免费建议： 如果你正在寻找一种无需编写任何代码即可提交开源 PR 的方法，请选择一个不遵守其样式指南的项目，在其上运行 prettier，并将结果作为你的整个拉取请求。 不能保证每个项目社区都会欣赏这一点，但这值得一试。