持续集成软件开发/敏捷的实际应用
< 持续集成软件开发
最近，我一直在思考当使用问题跟踪来处理从功能需求到文档到缺陷跟踪的所有任务时，哪个票据状态可能是合适的。这让我开始思考代码同行评审的必要性以及这些评审可能有多么乏味。事实证明，至少有一个 Trac 插件包含用于代码注释的钩子，以便进行同行评审。但是，它似乎不包含任何形式的正式签字功能。
我开始考虑，如果有一个用于同行评审的插件（用于 Trac 或 Redmine 或其他工具）会很好。但是，明智地使用它，以使同行评审过程成为工作流程中不可或缺的一部分的方式定义我们的工作流程，我们可能能够简化流程。我们真的需要一个插件，或者我们是否可以使用“正在评审”状态来实现相同目的？我想这个问题的答案取决于你想要多严格。
以下是关于票据（或问题、任务、工作项，或者我们选择如何称呼它）历史的思考。
- 新建
- 进行中
- 已解决（或者，如果我们确定某个票据不应该完成，我们有其他选择，例如延期、拒绝、重复等）
- 正在评审
- 已关闭
使用这样的设置，我们可以使用“已解决”状态作为指示问题已完成，但尚未准备好关闭的指标。只有在采取了适当的同行评审行动后，票据才会被关闭。谁来决定这些行动是什么？这由项目经理（或团队负责人）决定，并通过票据的适当路由来实施。负责同行评审的个人被分配到票据。看到“正在评审”状态后，这位同事会审查代码变更（观察附加到票据的变更集）并提出评论（在票据说明中）。
我知道这听起来有点工作量，但我看到了这种方法的一些主要好处。
- 跟踪 - 我们现在拥有所有同行评审评论的审计日志。通过将我们的票据系统与配置管理集成，票据、变更集和评审评论将链接在一起，不会丢失在某些电子邮件线程或文档中。
- 节省时间 - 任何曾经参与过同行评审的人（我猜大多数项目经理和开发人员都参与过）都知道它们可能非常耗时。因为似乎没有人有时间，所以我们试图通过进行大量代码评审来节省时间；我们等了很长时间，然后我们面临着要进行大量代码的同行评审。这导致了下一个好处…
- 更好的评审重点 - 我不知道你怎么样，但我发现自己更擅长评审少量代码或单个功能区域，而不是尝试一次性评审数千行代码。我们都很忙，这种情况不会改变。当你发现自己需要在周末进行同行评审，并且必须阅读和标记 5 个类文件时会发生什么？你会把正在做的事情都放下去做吗？你会尝试，但时间很短，所以你匆匆忙忙。
- 沟通 - 当我花时间审查变更集时，这对团队和进行审查的个人都有益。现在我对其他人正在做什么、它在哪里实现、它是如何实现的等等有了更多了解。我不必再去麻烦 Joe 开发人员，问他是否完成了这样那样的事情。我已经知道他完成了，因为我审查了他的代码。
所有这一切都假设我们的团队在处理问题跟踪和版本控制方面遵循良好的项目管理。这意味着我们必须拥有组织良好的票据，并且必须以某种有意义的方式提交变更集。这应该是显而易见的。