Five Principles of Bug Tracking[翻译]

五项原则之漏洞跟踪

                                                                                                                                                                     2014年11月24日

远程团队协作不像本地团队那样在同一个办公室里，远程需要更好的规范约束。

首先，我要说的是交流规范。在teamed.io这个团队中， 我们在最后的五年里，是通过远程协作来进行软件开发的。我们通过管理系统（如：Github, JIRA, Trac, Basecamp 等等）来严格的管理我们的任务，并且不鼓励任何其他形式的通信交流方式，像网络电话, HipChat聊天工具, 电子邮件或是电话。每个管理系统对于我们来说都是一个带有单独的有其生命周期的任务，有其特有的参与者和目标。多年来，我想分享一些我经历过的经验。如果你和你的团队是远程工作的话，那么你将发现它是多么的有用。

电视剧 巨蟒剧团（1969-1974）

 

1.保持一对一

每个错误标签都作为连接两个人的纽带:问题的识别和问题的解决。如果是个错误，我来报告出来，你来解决它。如果是个问题的话，我要知道是什么原因，你解释出来。如果是个任务，我让你做什么，你就做什么。任何情况下，都有两种主要的角色。无论在解决错误的过程中有多少人，只有这两个角色才是正式的。

 

错误标签记录者的责任是负责维护这个问题，当我报告了一个错误，我必须确定它的存在—这是我的职责。其他人也许会告诉我，我报告错了，这个错误不存在。他们也许还会说，他们不能探测到错误。他们也许还会说，我描述的任务太模糊，没人明白。有许多的争议。我的责任就是努力为了保维护标签的的正常。很明显，如果错误不存在，我就必须将错误错误取消。我就是其守护天使。

 

另一方面，错误解决者的责任是找到解决方案。当一个错误分配给我，我就必须解决它。我的职责就是确保我的解决方案是完美的。他也许会告诉我，我的解决方案有不足之处，不是很有效，或是不完整。而我的工作就是确信我是对的，他是错的。当然，是以合理的方式。为了找到足够的可被接受的解决方案，我不得不首先调查所有的可能性来了解问题，然后找到一种简洁的解决方式。但是，这是次要的，最主要的还是关注怎么说服错误记录者。我要时刻谨记，我最主要的目的是解决错误。

 

我的观点就是，无论有多少人讨论解决问题，永远都要记住，到底发生了什么—只有一个人负责提出解决方案，其他的人负责讨论（请看下文）。

 

2.解决它

记住，错误标签不是一个对话。你不是来这聊天的，你是来这解决问题的。当这个问题分配给你了，那么你就尽可能的解决它。

 

此外，切记，尽早的解决问题，对于项目的进展是很有好处的。时间越长，项目管理起来越麻烦。以为追踪和控制这些问题不是很容易的。很难知道到底发生了什么。你见过哪个开源项目有一些持续了2年的问题，并且有几百条评论，然后没有交付的？

 

对于项目管理者和参与者来说，这是不对的。每个错误应该有一些简短的认知，-1）一个问题，2）一个准确的询问，3）一个简短的解释，4)一个解决方案，5）解决，谢谢。这是理想的方案。

 

一旦你意识到问题进入了长期讨论的阶段，就要尽快的解决它。如果报告者不喜欢我的解决方案，该怎么办呢？那就找一个暂时的另他们满意的方案来解决它。可以在代码中使用“TODO”—这总比被问题长期困扰好吧。

 

一旦你发现提出的解决方案足够解决问题了，这时候就让报告者来解决它。如果你不介意周围的人说这个解决方案可能被接受，那么就明确的说，这是可以的。你要明确表示解决这个问题。试着这样：“@jeff，如果你没有任何疑问，请解决这个问题。”

 

3.不要解决它

每次你提出了一个问题，你就消耗了一些项目资源。每个问题报告者都意味着项目中花费了钱：1）这些钱用于发现问题和修复问题；2）对于项目管理者来说，他来找到解决问题的人；3）对于问题解决者来说，他尽量的来了解你提出的报告和解决方案；此外，4）其他人将会参与到讨论中。

 

如果你在没有在恰当的解决问题的时候，就把标签关闭了，而是将标签扔进了垃圾箱。一旦错误标签的内容发生了，是无法恢复的。所以，我们不能只是说,“这个标签不再有用了。”你的错误标签已经消耗了项目资源，并且花费了时间，为了使它们有可用之处，你不得不确定出来解决方案。

 

也许会是暂时的解决方法。可以改变项目中一行的内容。可以在代码中使用TODO标记来说明“我们意识到这个问题了，由于我们很懒，还没修复它”。总要做些事情，而不是什么也不做。

 

从不同观点角度来观察问题。当你开始发现这个错误标签，你在脑海里就要有东西了，关于你为什么报告了这个问题。即使有时候跟项目没有关系。如果你关了这个问题标签，在没有任何人看到这段代码的情况下，也许其他人可能会在这个问题上困扰几天甚至几年。然后，这个项目不能不再次花钱来重新标记错误标签，并讨论和解决这个相同的问题。即使你认为你发现的问题实际上不算是个问题，

那你也要让一个问题解决者来看看源代码，为了防止同样的问题在以后再次出现。

 

4.避免无意义—写下你的注解

每次你在标记错误的时候，都要写下注解。否则，如果你仅仅是因为想表达下观点就标记的话，你的评论将会变为无意义的垃圾。记住，标签是两个人之间的通信媒介—其中一个人报告了错误，同时，另个人要试图修复它。像“我试试其他方法怎么样”或是“我记得我之前修复了一个相同的问题”这些评论，都是让人恼火的和分心的。让我们真诚点，没有人真的需要或是关注什么观点。真正需要的是错误的解决方案。

 

如果你认为错误标签应该关闭了，因为解决方案足够好的。那你就写个注解给错误报告者，注解以“@jeff，我认为你的解决方案已经足够好了，因为…”开头。这样的话，你就帮助了他关闭了这个标签。

 

如果你认为解决方案是错误的，也记下的注解给标签报告者，以“@jeff，我认为你的解决方案不是很好，因为…”开头。这样的话，你就使得标签一直存在在这，直到有合适的解决方案出现。

 

再一次提醒，不要有无用的观点。而是，明确的在旁边注解出来—如果你喜欢这个解决方案，就关闭它。如果不喜欢这个解决方案，就保持它的开启。否则，只是让解决方案更加复杂，而对项目根本没有好处。

 

5.当产品出现问题，报告出来

我认为这是很明显的，但是我还有重申一次：每个问题都可能再次出现。每次你报告了一个问题，你就应该很好的解释产品为什么会出现问题。是的，产品没有像预期那样工作，或是没有正确的工作，甚至没有满足需求等等，这都是你的工作。

 

每个错误报告都应该伴有类似的结构：“这才是我们需要的，这是我们需要修改的，修复它”。每个错误标签，都是一个问题，一项任务，一个疑难，或是一个建议，都要以这种方式来处理。在提交的时候，你需要将项目从A点转移到B点。有时候，A点是不合适的，在B点可能会更好。所以，你需要解释A点和B点的情况。如果你可以解释怎么转移—问题是怎么再生的，怎么修复它，这会是非常令人满意的。

 

即使当你有问题，你也要以这种规范格式来处理。如果你有问题，就说明项目文档没有满足你找到问题的所在。这就叫做错误。应该修复它。以报告的形式，像“我怎么才可以看到X.class？”这么说，“目前的文档不完整，不能解释我怎么使用X.class，请修复。”

 

如果你不能解释怎么转移到另个地方的，那你就在标签中这么说：“我发现这个类不能像预期那样工作，但是我也不知道怎么处理这个问题。”这将给每个人一个明确的信息是你意识到了问题报告是不完整的。解决问题的第一步就是提取问题，使之在现。如果不能再现，很明显你的问题就会被关闭。

 

让我再次重申：每个错误标签都牵引着项目从A点到更合适的可以修复项目的B点转移。作为错误标签报告者，你的工作就是明确的清晰的记录出来出问题的那一行代码。

 

相关帖子

你也许会在这找到你感兴趣的话题：

• SLoc替代敲打代码
• 你花费了多少？
• 你是个黑客还是设计者？
• 增加账单
• 我们如何写产品愿景

 本内容原文地址：http://www.yegor256.com/2014/11/24/principles-of-bug-tracking.html