您在平台竞标中中标了，或者，您已收到客户的要求。
你做的第一件事是什么？
有一本剧本很有价值。每次开始研究代码中的新更改时都要遵循的过程。
它使您的工作更可预测、更完整和更正确。你会成为更好的开发者。
需要发生什么
让我们以平台中标中的项目为例。这是最简单的。
需要发生什么？
- 编写实现该功能的代码
- 为该功能代码编写测试
- 确保所有测试通过
- 打开拉取请求
- （通常）通过代码审查
- 通过 UI 测试和 QA
- 成功部署到所有环境
好多啊！这不仅仅是“编写代码”的步骤。
您的操作手册
每个人对如何构建剧本的偏好都会略有不同。但重要的是你有一个。
所有这些步骤都不会像预期的那样落到实处！他们采取计划和经验来执行。
这是我开始一项新任务时所做的。也许它会对你有所帮助。
- 我开始一个新的 git 分支。这通常是我的第一步。
- 我找到了需要更改的代码部分，但我还没有进行更改。这可能需要一段时间，因为代码可能有多层，我可能需要在多个地方进行更改。
- 我为我将要更改的功能寻找任何现有测试。如果我幸运的话，已经有很好的测试了！如果我没有，我会编写测试来帮助我确信我没有破坏任何东西。我还通过首先测试代码更好地理解了代码。
- 现在，我准备好做出尽可能小的改变。不要让拉取请求的范围扩大。专注于你的任务和需要发生的事情。
- 当然，我也为我的新代码编写测试。有时我使用 TDD。其他时候，我对何时以及编写什么测试更加宽松。
- 我在开发时经常运行单元测试。它们是我告诉自己过得如何的第一工具。好的编码是反馈的问题。单元测试提供最紧密的反馈循环之一。
- 一旦单元测试通过，我就会将更改推送到 GitHub。我打开了一个拉取请求草案，这样其他人就不会自动分配审查了。我让我们的 GitHub 自动化负责运行完整的测试套件。
- 在完整套件运行的同时，我给自己进行了一次代码审查。令人惊奇的是，当我在 GitHub 中审查自己的代码作为差异时，我看到了多少小错误或优化机会。在我请求审查之前，我希望我的代码尽可能小和干净。
- 如果所有测试都通过，我会请求审查以从我的团队那里获得反馈。
- 当我准备好部署时，我让我们的 CI/CD 管道处理细节。但我立即对这些变化进行现场排查测试，因为它正在通过环境。
常识
本操作手册可能看起来像是常识。
当然你需要测试你的代码！当然，您应该保持代码更改干净且小！
不幸的是，常识并不那么普遍。通过为自己创建一个明确的运行手册，我不会让常识成为偶然。
每次进行更改时，我都遵循相同的步骤。
每日清单
我每天早上都会为软件开发人员写一些新东西。
如果你喜欢我的文章，点赞，关注，转发！