开发运营开发人员的一天:暂停工作、修复 bug 并执行代码评审

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

Visual Studio 2022 |Visual Studio 2019 |Visual Studio 2017 |Visual Studio 2015 |Visual Studio 2013

“我的工作代码评审 ”功能支持从一个工作线程切换到另一个线程的上下文。 此外,团队成员可以轻松将有关建议更改的消息交换为代码。 本文演示了这些功能,并继续学习了一天的虚构敏捷团队成员的教程。

注意

我的工作代码评审 功能可用于以下版本:

  • Visual Studio 2022:Visual Studio Community、Visual Studio Professional和Visual Studio Enterprise
  • Visual Studio 2019、2017 和 2915:Visual Studio Professional和Visual Studio Enterprise
  • Visual Studio 2013:Visual Studio Premium 2013和Visual Studio Ultimate。

Peter 忙于编写一些代码以完成积压工作 (backlog) 项任务。 然而, 他的同事发现了一个阻止它们的 bug ,他希望立即修复它。 他暂停了手中的工作并修复此 Bug。 他请求 Julia 评审修复情况,并在评审后检查修复结果并恢复其初始任务。

挂起当前工作

当 Peter 处理积压工作 (backlog) 项时,Julia 过来讨论困扰她的 Bug。 这是 Peter 所熟悉的区域,因此他创建了修复 Bug 的任务,并将其分配给自己。 他决定立即开始修复工作。

在开始处理新 bug 之前,彼得希望确保他目前的工作放在团队的服务器上一个安全的地方。 在 “我的工作 ”页上,Peter 选择 “挂起 ”以将 (保存到 Team Foundation Server) :

  • 他完成的所有工作包括对代码、测试和其他文件的更改。

  • 打开解决方案、窗口、断点、监视窗口变量和其他 Visual Studio 状态的位。

现在,他的工作区已干净,Peter 会将新任务从“可用工作项”拖动到“正在进行工作”。 他准备研究并编写修复程序。

注意

你的工作上下文链接到在“我的工作”页中显示为“正在进行”的工作项。 通过使用 “挂起 ”和 “恢复”,可以在不同的任务之间快速切换。 打开的解决方案和文件、代码更改以及 Visual Studio 布局都会一起切换。

挂起当前工作并开始执行另一项任务

暂停某些工作的屏幕截图。

  1. 连接: 如果尚未连接到要处理的项目,请 连接到项目

    1. 团队资源管理器中,选择“开始”图标“开始”,然后选择“我的工作”图标“我的工作”。
  2. 暂停 当前任务:

    1. 在“ 正在进行工时 ”部分中,选择“ 挂起”。

    2. 在显示的框中,指定要为这组挂起的工作指定名称,然后选择“ 挂起 ”按钮。 默认名称是当前正在进行的工作项。

  3. 开始处理新任务、bug 或其他工作项:

    1. 在选择工作项之前,你可能需要:

      • 通过选择“可用工作项”下的“新建”创建新的任务或其他工作项;或

      • “可用工作项”下选择其他查询。

    2. 将工作项从“可用工作项”拖动到“正在进行工作”。

      或者,可以通过从 “挂起的工作”下拖动它,切换到以前挂起的工作项。

提示

当前正在进行的工作项将链接到当前代码更改和 Visual Studio 状态。 若要允许 Visual Studio 帮助你组织工作,请确保你在从一个任务切换到另一个任务时,相应的项处于“正在进行中”状态。

调查 Bug

Peter 打开并阅读 Bug 工作项。 根据测试团队成员编写的说明,已付款的发票有时会被错误地标记为未付款。 存在附加到 bug 工作项的实验室环境快照。 Peter 可以打开运行测试的虚拟机,查看错误发票和 IntelliTrace 日志。 他跟踪以下方法存在的错误:

public class LocalMath
{
    public static bool EqualTo(double a, double b)
    {
        return a == b;
    }

从 IntelliTrace 日志中,Peter 发现此方法有时会因参数存在极小的差异而返回 false。 Peter 知道此类舍入误差在浮点算法中是不可避免的,同时,利用此方法测试浮点数字的相等性也较为不妥。

增加测试以显示错误

发现 bug 时,它显示单元测试存在差距,或者测试与用户的实际需求不匹配。 因此,在修复 Bug 之前,Peter 添加了一个将演示存在此错误的测试。

// Added 2012-02-02 for bug 654321:
/// <summary>
/// Make sure that number equality test allows for 
/// small rounding errors.
/// </summary>
[TestMethod]
public void TestDoublesEqual()
{
    // We allow a rounding error of 1 in 1000000:
    TestEqual(1, 1e-7, true); // Less than allowed error
    TestEqual(1, 1e-5, false); // More than allowed error
    TestEqual(1000, 1e-7, true); // Less than allowed error
    TestEqual(1000, 1e-5, false); // More than allowed error
}
private void TestEqual(double value, double error, bool result)
{
    // Try different combinations of error and value:
    Assert.IsTrue(result == LocalMath.EqualTo(value + error, value));
    Assert.IsTrue(result == LocalMath.EqualTo(value, value + error));
    Assert.IsTrue(result == LocalMath.EqualTo(value - error, value));
    Assert.IsTrue(result == LocalMath.EqualTo(value, value - error));
}

他运行了该测试,结果如预期一样以失败告终。

单元测试资源管理器的屏幕截图,其中显示了失败的测试是否相等。

让测试通过

Peter 修复代码:

public static bool EqualTo(double a, double b)
{
    // Allow for rounding errors.
    // For example, a == 2.0 and b = 1.99999999999

    const double allowedError = 1/1000000;
    return System.Math.Abs(a - b) < allowedError;
}

测试现在通过:

单元测试资源管理器的屏幕截图,其中显示了经过的测试是否相等。

请求代码评审

Peter 对自己对 Bug 的修复感到满意,但是尚未签入其工作。 他的团队使用代码评审来提高总体代码质量并降低创建更多 bug 的风险,因此彼得使用团队资源管理器从团队成员 Julia 和 Adam 请求代码评审。

请求代码评审

“我的工作”页 - “请求审阅”链接。“新建代码审阅”页 - 输入审阅者的姓名下拉列表,输入说明 (可选) 文本框,“提交请求”按钮。

  1. “团队资源管理器”的 “我的工作 ”页上,选择“ 请求评审”。

    此时会显示“ 新建代码审阅 ”页。

  2. “审阅者”图标。 指定一个或多个审阅者。

  3. 代码审阅图标。 指定审阅的名称。

  4. 区域路径图标。 指定区域路径。

  5. 批注图标。 为审阅者指定批注。

  6. 选择 “提交请求”。

审阅者将通过电子邮件接收请求通知。

你还可以请求对挂起的工作、搁置集或变更集进行代码评审。 若要查看更改集的列表,请打开 源代码管理资源管理器 并选择 “历史记录 ”按钮。

接受或拒绝代码评审

Julia 接收并接受代码评审请求。 她评审代码,并在文件和代码块级别编写注释,然后将代码评审反馈给 Peter。 Adam 太忙,无法评审代码,因此拒绝了请求。

Julia 在其注释中指出测试是错误的。 允许的误差应为输入值的指定部分,而不是常数。 因此,测试应将错误值乘以值。

// We allow a rounding error of 1 in 1000000
// as a fraction of the value:
TestEqual(1, 1e-7, true); // Less than allowed error
TestEqual(1, 1e-5, false); // More than allowed error
TestEqual(1000, 1000*1e-7, true); // Less than allowed error
TestEqual(1000, 1000*1e-5, false); // More than allowed error

提示

请注意,团队成员会将测试用作讨论焦点。 如果测试正确且足够,则代码也会如此。 与代码不同,每个测试表示单独的大小写。 因此,讨论测试通常比讨论代码更容易。

执行代码评审

“我的工作”页的屏幕截图 - 代码评审项。代码审阅页 - 拒绝链接、批注、拒绝按钮。
差异窗口的屏幕截图。代码审阅页 - 接受链接、总体注释、代码块注释。

  1. 团队资源管理器“我的工作 ”页上,转到 “我的代码评审 & 请求 ”部分并打开请求。

  2. “代码评审 ”页上,可以:

    • 选择 “接受 ”或 “拒绝” 以通知作者是否要执行评审。

    • 选择 “添加审阅者 ”,将其他审阅者添加到代码评审请求。

    • 查看对每个已为此工作项更新的文件的更改。

    • 展开 “注释 ”以与作者和其他审阅者讨论更改。

      • 选择 “添加总体批注”

        -或-

        选择代码块,然后从快捷菜单中选择 “添加批注 ”。

      • 选择 “发送批注 ”,使你的贡献对作者和其他审阅者可见。
    • 选择 “发送”和“完成” 以完成评审,指示代码是否需要更多工作。

响应代码评审

Peter 接收并响应了来自 Julia 的代码评审。

响应代码评审

代码的审阅者和作者可以根据需要交换注释。 作者一旦关闭评审,则评审就将结束。 每次有人参与讨论时,其他参与者都会收到电子邮件通知。

“我的工作”页的屏幕截图 - 代码评审项。“代码审阅”页 - 总体注释、文件注释、“关闭审阅”链接。

  1. 团队资源管理器“我的工作 ”页上,转到 “代码评审 & 请求 ”部分,然后双击该请求。

    还可以打开请求的快捷菜单,然后选择 “打开”。

  2. 阅读评论并根据需要进行答复。 若要回复批注,请选择“ 回复”,在出现的框中输入批注,然后选择“ 确定”。 若要发送批注,请选择“ 发送批注”。

  3. 若要查看文件并查看具有注释的代码块,或编辑文件,请转到 “注释 ”部分。 在 “文件” 子部分中,打开文件的快捷菜单,然后选择“ 比较 (只读) 编辑文件

  4. 当你和其他审阅者完成对彼此的评论的响应并准备好关闭审阅时,请单击“ 关闭审阅”,然后选择以下任一项:

    • 完成 以指示审阅已完成。

    • -或-

    • 放弃 以指示正在取消评审。

修复测试和代码

在阅读朱莉娅的评论后,彼得修复了他的单元测试,因为她建议。 测试现已失败。 这意味着代码不正确。

Peter 修复代码:

/// <summary>
/// Returns true if two numbers are equal.
/// </summary>
public static bool EqualTo(double a, double b)
{
    // Allow for rounding errors.
    const double allowedErrorMultiple = 1/1000000;
    double allowedError = (System.Math.Abs(a) + System.Math.Abs(b)) * allowedErrorMultiple/2;
    return System.Math.Abs(a - b) < allowedError;
}

测试再次通过:

单元测试资源管理器的屏幕截图,其中显示了经过的测试是否相等。

提示

若要修复此 Bug,请按照代码开发中的相同做法进行操作。 编写会失败的测试,然后设法让该测试通过。 仅在测试通过时,签入代码和测试。

Peter 现在将注意力转移到发现 Bug 的测试用例上。 在测试用例工作项中清楚说明了 Bug 的重现步骤。 他按照这些步骤操作,并发现已正确列出了发票。

签入修复

Peter 签入已修复代码和单元测试。 bug 的状态会自动设置为 “已解决”,“ 已分配给 ”值会自动重新分配给发现 bug 的测试团队的成员。 该团队成员将验证 Bug 是否已修复并关闭工作项。

签入修复

签入更新以修复 bug 的屏幕截图。

  1. 团队资源管理器“我的工作 ”页上,选择 “签入”。

  2. 查看 “挂起的更改 ”页的内容,确保:

    • 所有相关更改均列在“包含的更改”中

    • 所有相关工作项均列在 相关工作项中。

  3. 指定 注释 ,以帮助团队了解更改文件和文件夹的版本控制历史记录时这些更改的目的。

  4. 选择 “签入”。

继续处理任务

Peter 继续处理自己的任务。 他很快就可以继续工作,因为他的所有代码更改连同重要的状态图位(如打开窗口、断点及观看窗口变量)都已还原至工作区。

继续任务中的工作

恢复和完成任务的屏幕截图。

  • 团队资源管理器“我的工作 ”页上,找到 “ & 挂起的搁置工 时”列表。 打开项的快捷菜单。 有两种选择:

    • 如果要恢复挂起的工作,并自动暂停工作区中任何挂起的更改,请选择 “恢复”。

    • 如果要将挂起的工作与工作区中已有的挂起更改合并,请选择 “与正在进行的合并”。

当你继续工作时

受挂起工作项影响的窗格的屏幕截图。

当你继续工作时,Visual Studio 会还原:

  • 打开的解决方案
  • 代码更改
  • 打开的窗口的状态和位置
  • 断点
  • 监视窗口变量与表达式
  • 书签。