我曾多次面对一个团队想要构建自己的缺陷跟踪系统，这不是作为产品，而是作为内部工具。
我听到的支持意见通常是：
- 希望通过一些内部构建的Web框架来“吃自己的狗粮”
- 需要一些高度专业的报告或以某种所谓独特的方式调整某些功能
- 认为构建缺陷跟踪系统并不困难
如果要支持购买现有的缺陷跟踪系统，你可能会使用哪些论点？特别是，哪些功能听起来很容易但实际上很难实现，或者很难并且很重要但常常被忽视？
建立自己的漏洞跟踪系统不可取的原因
54
- Matt Sheppard
1
我们自己构建了系统。这并不难。它极大地改善了客户服务，因为它可以与我们自己定制的CRM集成。我们已经有了客户数据库……添加一些额外的字段并不难。我们公司非常成功。这是一个巨大的时间节省和客户服务优势。不需要使用多个系统很棒。现代技术可以轻松地将定制表单和报告放在网上。商业系统很复杂，学习曲线陡峭。工程师们很容易过度思考，使事情变得复杂。保持简单就好。 - David J
35个回答
81
首先，看一下这些 Ohloh 指标：
Trac: 44 KLoC, 10 Person Years, $577,003
Bugzilla: 54 KLoC, 13 Person Years, $714,437
Redmine: 171 KLoC, 44 Person Years, $2,400,723
Mantis: 182 KLoC, 47 Person Years, $2,562,978
从这些数字中我们能学到什么？我们可以得出结论：建造另一个Bug跟踪器是浪费资源的好方式！
所以，以下是我建造内部Bug跟踪系统的原因：
- 你需要在未来十年或二十年内消除所有菜鸟程序员的问题。
- 你需要花费一些钱来避免明年的预算削减。
否则就不要建造。
- Constantin
1
难以置信Redmine有这么多行代码..我以为它是用Ruby写的。 - kizzx2
40
我想反过来问一下，你为什么要自己建立呢？
如果你需要一些额外的字段，去选择一个可以修改的现有软件包。
特殊报告？从数据库中获取数据并制作即可。
认为这并不困难？那就试试看吧。对其进行详细规划，看看功能列表和所需时间是否越来越多。然后在列表完成后，在实现自己的方案之前尝试找到一个可以修改的现有软件包。
简而言之，在另一个轮子只需要进行微调以适应时，不要重新发明轮子。
- Lars Mæhlum
19
程序员喜欢构建自己的票务系统，因为他们曾经看到和使用过很多这样的系统，了解它们的一切。这样他们就可以保持舒适区。
这就像尝试新餐厅一样：可能会有回报，但也有风险。最好还是再点比萨饼。
还有一个关于决策制定的重要事实被埋藏在其中：做某件事情总是有两个理由：一个好的理由和一个正确的理由。我们做出决定（“构建我们自己的系统”），然后为之辩护（“我们需要完全控制”）。大多数人甚至不知道他们真正的动机。
要改变他们的想法，你必须攻击真正的原因，而不是辩护。
- Matt Winkelmann
14
- Stu Thompson
2
1你是反问，但这确实是我在许多地方看到的主要原因。Bug跟踪器是内部的，正是因为它需要与所有其他内部东西集成，通常在一个单一的庞大应用程序中，开发实践不佳。 - bignose
2还有一些集成产品可供选择。然后，还有“中间件”的概念。我坚持我的回答。 - Stu Thompson
12
有第三个选项，既不买也不建。市面上有很多好的免费Bug跟踪工具。
例如：
除非是为了学习目的，否则自己开发Bug跟踪器并不是一个好的时间利用方式。
其他链接：
- Anthony
1
免费是没错，但在我看来，Bugzilla和Trac都不太好。 - Orion Edwards
10
我只能说这是一个金钱问题——购买一个你知道对你有益的成品（有时甚至免费也不会尝试自己去开发）要比自己去开发一个更好。这是一个简单的先付款和后付款的游戏。
- Omer van Kloeten
2
因为“自由软件”并不存在... - alternative
并不是说这种支持不存在，但通常当你在一家使用免费软件的公司工作时，你会想购买一个支持包，除非你想自己开始修复其中的漏洞（即以后付出代价）。 - Omer van Kloeten
9
首先，反对自建的观点是：
想要在某个内部构建的 Web 框架方面“吃自己的狗粮”
当然，这引发了一个问题：为什么要自己构建 Web 框架呢？就像有很多值得信赖的免费 bug 跟踪器一样，也有许多值得信赖的框架。我想知道你们的开发人员是否有正确的优先级？谁在做能让公司真正赚钱的工作呢？
好吧，如果他们非要构建一个框架，让它从构建实际用于赚钱的业务软件的过程中自然演变出来。
需要一些高度专业化的报告或以某种据称独特的方式调整某些功能
就像其他人所说的那样，选择其中一个优秀的开源跟踪器并进行调整。
认为构建一个 bug 跟踪系统并不困难
嗯，我在几周内写了第一个版本的BugTracker.NET，起初完全没有C#知识。但是现在，6年后并花费了数千小时，仍有一大堆未完成的功能请求，所以这取决于你想让缺陷跟踪系统做什么。需要多少电子邮件集成、源代码控制集成、权限、工作流、时间跟踪、进度估算等等。缺陷跟踪器可以是一个非常重要的应用程序。
你会使用哪些论据来支持购买现有的缺陷跟踪系统？
不需要购买。有太多好的开源软件：Trac, Mantis_Bug_Tracker，还有我自己的 BugTracker.NET，只是列举了其中几个。
如果你只是为自己创建，那么你可以采取很多捷径，因为你可以硬编码。如果你为许多不同的用户在许多不同的情况下构建它，那么支持可配置性就很难了。可配置的工作流、自定义字段和权限。特别是哪些功能听起来很容易实现，但实际上很难，或者很困难但又很重要但经常被忽视？
我认为一个好的缺陷跟踪器必须具备两个功能，即FogBugz和BugTracker.NET都有的：1）集成传入和传出的电子邮件，以便整个关于缺陷的对话都与缺陷一起存储，而不是在单独的电子邮件线程中；2）将屏幕截图转换为缺陷帖子的实用程序，只需点击几下即可。
- Corey Trager
6
我认为最基本的理由是时间浪费。我怀疑它能否在一个月或两个月内完成。既然有这么多好的缺陷跟踪系统可用，为什么要花时间去开发呢？请给我举一个需要调整但不容易得到的功能的例子。
我认为一个好的缺陷跟踪系统必须反映你的开发流程。一个非常定制化的开发流程对公司/团队来说本质上是不好的。大多数敏捷实践都支持Scrum或这类方法，并且大多数缺陷跟踪系统也遵循这些建议和方法。不要过于官僚主义。
- Slavo
5
最重要的是，在你的缺陷跟踪器完成之前，你将在哪里提交错误？
但说真的。 工具已经存在，没有必要重新发明轮子。 修改跟踪工具以添加某些特定功能是一回事（我以前修改过Trac）... 重新编写一个就是愚蠢。
你可以指出的最重要的事情是，如果他们想要做的只是添加几个专业报告，那么不需要从头开始解决问题。此外，“自制解决方案”最后一点关心的是内部工具。如果它按照你的需求完成了工作，那么谁会在意你在内部使用什么？
- Loren Segal
5
一个缺陷跟踪系统可以是一个很好的项目，让初级开发人员开始学习。这是一个相当简单的系统，您可以用它来培训他们在编码约定等方面的知识。让初级开发人员构建这样一个系统相对便宜，并且他们可以在客户看不到的地方犯错误。
如果它是垃圾，您可以扔掉它，但如果使用了它，您可以让他们感觉到他们的工作已经对公司很重要。对于初级开发人员能够体验整个生命周期和所有知识转移机会的项目，您无法评估其成本。
如果它是垃圾，您可以扔掉它，但如果使用了它，您可以让他们感觉到他们的工作已经对公司很重要。对于初级开发人员能够体验整个生命周期和所有知识转移机会的项目，您无法评估其成本。
- Garry Shutler
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接