修复（修补）在开发中：是什么、阶段以及如何修正

开发中的“修复”是什么意思

修复（修补）——修正程序代码、配置或数据中的错误。该术语源自英语“to fix”（修理、修正），是程序员词汇中最常见的词语之一。修复可以很简单——修正一行中的拼写错误——也可以很复杂，影响到整个模块的架构。

“修补”这个动词具有双重含义：除了修复bug之外，它还可能意味着“在版本控制系统中记录更改”（来自英语“commit/fix”）。在这两种情况下，结果都是一样的——代码变得比干预之前更好。在专业社区中，这些词之间的差异很小，两者都被用作完全同义词。

正确修复bug的能力是程序员的关键技能之一。错误在任何项目中都是不可避免的，修复它们的速度直接影响产品质量和用户满意度。系统化的方法包括清晰的流程：重现、诊断、编写测试、修正、进行代码审查。

Bug的生命周期：从发现到修复

Bug的生命周期——错误从发现到完全消除所经历的一系列状态。理解这个周期有助于组织修复过程并避免错过关键步骤。在典型过程中，bug经历五个主要阶段。

发现和记录

第一阶段是发现bug，可以通过测试、错误监控、用户反馈或自动崩溃报告来实现。Bug在追踪器中记录，包括重现步骤、环境、预期和实际行为。好的bug描述是快速修复的基础。

重现和诊断

程序员在其环境中按照描述中的步骤重现bug。如果bug无法稳定重现，则需要额外的数据：日志、内存转储、屏幕录制。重现之后开始诊断——在代码中寻找根本原因。在此阶段，经常使用调试器、日志记录和性能分析工具。

编写测试和修正

在修正之前，建议编写一个重现bug的测试——这确保了修复确实有效，并防止将来出现回归。在测试以预期错误失败后，程序员编写修正代码。测试必须在修复后通过并添加到回归集中。

func testLoginWithInvalidCredentials() {
    let result = AuthService().login(
        email: "wrong@test.com",
        password: "wrong"
    )
    XCTAssertEqual(result, .failure(.invalidCredentials))
}

代码审查和验证

修复被发送进行代码审查——同事检查修正是否正确、是否破坏相邻模块以及是否符合代码标准。审查之后，修复进行回归测试。在理想周期中，在测试通过且更改被审查者接受之前，bug不被视为已关闭。

部署和验证

修正进入主分支并部署到生产环境。部署后，团队在生产环境中验证bug并跟踪指标：崩溃报告中相应错误的数量是否减少。Bug在追踪器中关闭，并注明修复版本的版本号。

Hotfix和bugfix：何时以及选择哪种方法

Hotfix——对当前在生产中影响用户的关键错误的紧急修复。这种修复在正常开发周期之外执行：从发布分支创建单独的分支，进行最小更改，测试分支并立即部署。Hotfix之后，更改必须合并到主开发分支。

Bugfix——经过完整生命周期的计划内修复：从记录到代码审查和回归测试。Bugfix包含在常规sprint中，不需要紧急部署。Hotfix和bugfix之间的区别在于紧急程度和流程，而不是更改本身的复杂性。

何时需要hotfix

Hotfix当在生产中发现阻塞关键功能的问题时需要：支付网关无法工作、认证失败、用户看到空白屏幕。在这种情况下，每停机一小时都会造成金钱和信任的损失。Hotfix应该是最小的——仅限消除问题的针对性更改，而不重构相邻代码。

何时bugfix就足够了

Bugfix适用于非关键错误：视觉bug、次要屏幕上的非关键崩溃、分析数据中的不准确之处。这些修复经过完整的验证周期并按计划进入发布。计划内的bugfix可以避免仓促更改可能导致的回归。

实践流程：如何正确修复Bug

正确的修复流程不仅仅是编写代码，还包括使修正安全且持久的一系列规范。让我们看看每次bugfix都应该遵循的操作顺序，无论其复杂程度如何。

本地重现bug

在编写代码之前，在你的开发环境中重现bug。没有重现，你就无法检查修复是否有效。使用与用户相同的数据——复制配置、功能标志、API版本。如果bug无法在本地重现，请在staging环境中添加临时日志记录。

编写因bug而失败的测试

好的实践是先编写一个测试，该测试重现bug并失败。这有两个目的：首先，你证明bug存在；其次，修复后测试通过，确认修正。测试保留在代码库中作为回归的防护。

@Test
fun testCartTotalWithPromotion() {
    val cart = Cart().apply {
        addItem(Item("T-shirt", 29.99))
        addPromotion(Promotion("10OFF"))
    }
    Assert.assertEquals(26.99, cart.total())
}

进行最小修正

最小更改是bugfix的关键原则。不要沿途重构相邻代码，不要在同一个commit中修复其他bug。每个commit应该正好解决一个问题。这简化了代码审查、必要时回滚以及对更改历史的理解。一个更改——一个提交。

检查修复是否有效且不破坏其他部分

编写修复后，运行整个回归测试套件。如果修复影响共享模块，还要检查相邻模块的测试。运行linter并确保代码符合项目中接受的标准。只有在此之后才创建Pull Request。

追踪工具和最佳实践

Bug追踪系统是修复过程不可分割的一部分。它们确保没有错误丢失、指定负责人、跟踪状态并收集统计数据。工具的选择取决于团队规模和工作流程，但基本功能相似：创建任务、生命周期、优先级、与VCS的集成。

流行工具

Jira——最广泛使用的企业级项目系统，支持灵活的工作流、自定义字段以及与Bitbucket/GitHub的集成。GitHub Issues——内置追踪器，适合中小型团队，与Pull Request集成。Linear——具有极简界面和高速度的现代追踪器，在创业公司中受欢迎。

修复的最佳实践

第一：修复原因，而不是症状。如果应用程序因nil崩溃，不要将整个代码包裹在if let中——理解为什么值变成了nil。第二：修复应包含证明修正的测试。第三：不要在同一个commit中修复两个bug——这会复杂化回滚。第四：在commit描述中添加指向追踪器中任务的链接。

• 使用conventional commits格式：fix(auth): handle nil token
• 始终在commit描述中添加指向issue的链接
• 检查测试在修复前后是否通过
• 对于hotfix，从发布分支创建单独的分支，而不是从develop
• 部署后不要忘记将hotfix 合并到develop