53

现在有好几次,我遇到了一个团队想要构建自己的错误跟踪系统的计划——不是作为产品,而是作为内部工具。

我听到的赞成的论点通常是这样的:

  • 想在一些内部构建的网络框架方面“吃我们自己的狗粮”
  • 需要一些高度专业化的报告,或者以某种据称独特的方式调整某些功能的能力
  • 相信构建一个bug跟踪系统并不难

您可以使用哪些论据来支持购买现有的错误跟踪系统?特别是,哪些功能听起来很简单,但实施起来却很困难,或者哪些功能既困难又重要,但经常被忽视?

4

35 回答 35

80

首先,看看这些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

我们从这些数字中学到了什么?我们了解到构建 Yet Another Bug Tracker 是浪费资源的好方法!

所以这是我建立自己的内部错误跟踪系统的原因:

  1. 您需要在十年或两年内消除所有的 bozocoders。
  2. 你需要冲一些钱来避免明年的预算减少。

否则不要。

于 2008-10-07T19:39:28.133 回答
39

我想把这个问题转过来。你到底为什么要建立自己的?
如果您需要一些额外的字段,请使用可以修改的现有包。
特别报道?进入数据库并制作它。

相信不难吗?那就试试吧。对其进行规范,并查看功能列表和时间增长。然后在列表完成后,尝试找到一个可以修改的现有包,然后再实现自己的。

简而言之,当另一个只需要一些调整以适应时,不要重新发明轮子。

于 2008-09-15T11:05:56.730 回答
19

程序员喜欢构建自己的票务系统,因为看过并使用过数十个系统,他们对它了如指掌。这样他们就可以留在舒适区。

这就像检查一家新餐厅:它可能会有所回报,但也有风险。最好再次订购披萨。

还有一个关于决策的重要事实:做某事总是有两个理由:一个好的理由和正确的理由。我们做出决定(“建立我们自己的”),然后证明它的合理性(“我们需要完全控制”)。大多数人甚至没有意识到他们真正的动机。

要改变他们的想法,你必须攻击真正的原因,而不是理由。

于 2008-09-15T11:12:32.597 回答
14

不是在这里发明的综合症!

建立自己的错误跟踪器?为什么不构建自己的邮件客户端、项目管理工具等。

正如Omer van Kloeten在其他地方所说,现在付款或以后付款。

于 2008-09-15T11:16:09.607 回答
12

还有第三种选择,既不购买也不建造。那里有很多免费的好东西。例如:

将自己的错误跟踪器用于学习以外的任何用途都不是很好地利用时间。

其他链接:

于 2008-09-15T12:14:55.537 回答
10

我只想说这是钱的问题 - 购买你知道对你有好处的成品(有时甚至不购买,如果它是免费的)比必须自己开发一个更好。这是一个简单的现在付款与以后付款的游戏。

于 2008-09-15T11:03:35.783 回答
8

首先,反对支持建立自己的论点:

想在一些内部构建的网络框架方面“吃我们自己的狗粮”

这当然提出了为什么要构建自己的 Web 框架的问题。就像那里有许多有价值的免费错误跟踪器一样,也有许多有价值的框架。我想知道您的开发人员是否有明确的优先事项?谁在做让你的公司真正赚钱的工作?

好的,如果他们必须构建一个框架,让它从构建您的企业用来赚钱的实际软件的过程中有机地发展。

需要一些高度专业化的报告,或者以某种据称独特的方式调整某些功能的能力

正如其他人所说,抓住众多优秀的开源跟踪器之一并对其进行调整。

相信构建一个bug跟踪系统并不难

好吧,我在短短几周内就编写了我的BugTracker.NET的第一个版本,从没有 C# 知识开始。但是现在,6 年又几千小时后,仍然有一大堆未完成的功能请求,所以这完全取决于您希望错误跟踪系统做什么。多少电子邮件集成、源代码控制集成、权限、工作流、时间跟踪、进度估计等。错误跟踪器可以是一个主要的、主要的应用程序。

您可以使用哪些论据来支持购买现有的错误跟踪系统?

不需要购买。太多好的开源软件:TracMantis_Bug_Tracker、我自己的 BugTracker.NET 等等。

特别是,哪些功能听起来很简单,但实施起来却很困难,或者哪些功能既困难又重要,但经常被忽视?

如果您只是为自己创建它,那么您可以走很多捷径,因为您可以硬连线。如果您要在许多不同的场景中为许多不同的用户构建它,那么很难支持可配置性。可配置的工作流程、自定义字段和权限。

我认为一个好的bug 跟踪器必须具备的两个功能,即FogBugz和 BugTracker.NET 都具有,是 1) 集成传入和传出电子邮件,以便关于 bug 的整个对话与 bug 一起存在,而不是在单独的电子邮件中线程,以及 2) 只需单击几下即可将屏幕截图转换为错误帖子的实用程序。

于 2008-09-27T04:35:31.743 回答
6

对我来说最基本的论点是时间损失。我怀疑它可以在不到一两个月的时间内完成。为什么要花时间在有这么多好的错误跟踪系统可用的时候?给我一个你必须调整并且不容易获得的功能的例子。

我认为一个好的错误跟踪系统必须反映您的开发过程。一个非常定制的开发过程本质上对公司/团队不利。大多数敏捷实践偏爱Scrum或这类东西,大多数错误跟踪系统都符合这样的建议和方法。不要太官僚主义。

于 2008-09-15T11:03:25.537 回答
5

最重要的是,在您的错误跟踪器完成之前,您将在哪里提交错误?

不过实话说。工具已经存在,无需重新发明轮子。修改跟踪工具以添加某些特定功能是一回事(我之前修改过Trac)......重写一个只是愚蠢的。

您可以指出的最重要的事情是,如果他们只想添加几个专门的报告,则不需要从头开始的解决方案。此外,“你的自制解决方案”最重要的地方是内部工具。如果它可以按您的需要完成工作,谁会在乎您在内部使用什么?

于 2008-09-15T11:13:12.843 回答
5

错误跟踪系统可能是初级开发人员开始的一个很好的项目。这是一个相当简单的系统,您可以使用它来训练他们的编码约定等。让初级开发人员构建这样一个系统相对便宜,而且他们可以在客户看不到的东西上犯错误。

如果它是垃圾,你可以把它扔掉,但你可以给他们一种感觉,如果使用它,那里的工作已经对公司很重要。你不能让初级开发人员能够体验这样一个项目将带来的整个生命周期和所有知识转移的机会。

于 2008-09-15T11:35:34.210 回答
5

我们在这里做到了这一点。我们在 10 多年前写了第一个。然后我们将其升级为使用网络服务,更多地作为学习技术的一种方式。我们最初这样做的主要原因是我们想要一个错误跟踪系统,该系统还可以生成版本历史报告和一些我们在商业产品中找不到的其他功能。

我们现在再次关注错误跟踪系统,并且正在认真考虑迁移到 Mantis 并使用 Mantis Connect 添加我们自己的其他自定义功能。滚动我们自己的系统所付出的努力太大了。

我想我们也应该看看 FogBugz :-)

于 2008-09-15T12:14:39.327 回答
4

作为一名从事已经很重要(或最不重要)任务的程序员,不应该让自己偏离尝试开发市场上已经可用的东西(开源或商业)。

您现在将尝试创建一个错误跟踪系统来跟踪您用来跟踪核心开发中的错误的错误跟踪系统。

首先: 1. 选择你的 bug 系统将运行的平台(Java、PHP、Windows、Linux 等) 2. 尝试在平台上找到可用的开源工具(通过开源,我指的是商业和免费工具)您选择了 3. 花最少的时间尝试根据您的需要进行定制。如果可能的话,不要浪费时间在定制上

对于企业开发团队,我们开始使用JIRA。我们想要一些额外的报告、SSO 登录等。JIRA 能够做到这一点,我们可以使用已经可用的插件对其进行扩展。由于代码是付费支持的一部分,我们只花了最少的时间编写用于登录的自定义插件。

于 2008-09-15T11:28:56.207 回答
3

建立在其他人所说的基础上,而不仅仅是下载免费/开源的。如何下载它,然后完全根据自己的需要进行修改?我知道我过去曾被要求这样做。我安装了 Bugzilla,然后对其进行了修改以支持回归测试和测试报告(这是很多年前的事了)。

不要重新发明轮子,除非你确信你可以制造一个更圆的轮子。

于 2008-09-15T12:17:46.887 回答
2

我想说最大的绊脚石之一是对数据模型/工作流程的苦恼。我预计这将需要很长时间,并且涉及许多关于在某些情况下应该如何处理错误、真正构成错误等的争论。如果你只是推出一个预建系统,大多数人将学习如何使用它并充分利用它,无论哪些决定已经确定。选择一些开源的东西,如果需要的话,你可以随时调整它——这比从头开始自己动手要快得多

于 2008-09-15T11:07:46.307 回答
2

在这一点上,如果在错误跟踪/票务方面没有一个大的新方向,它只会重新发明轮子。一般来说,这似乎是其他人的想法。

于 2008-09-15T11:14:24.527 回答
2

您的讨论将从构成错误的内容开始,然后演变为要应用的工作流程,并以关于如何管理软件工程项目的大规模争论结束。你真的想要那个吗?:-) 不,没想到 - 去买一个!

于 2008-09-15T11:20:49.800 回答
2

大多数开发人员认为他们拥有一些其他人没有的独特能力,因此他们可以创建一个以某种方式独特的系统。

其中 99% 是错误的。

贵公司拥有 1% 的员工的可能性有多大?

于 2008-09-15T13:26:34.897 回答
2

我一直在这场辩论的双方,所以让我在这里面对一点点。

当我年轻的时候,我推动建立我们自己的错误跟踪系统。我只是强调了所有现成的东西不能做的事情,我让管理层去做。他们选择了谁来领导团队?我!这将是我第一次有机会成为团队领导,并在从设计到工具再到人员的方方面面都有发言权。我很激动。所以我的建议是检查推动这个项目的人的动机。

现在我年纪大了,又面临同样的问题,我决定选择 FogBugz。它完成了我们所需的 99%,成本基本上为 0。此外,Joel 会向您发送个人电子邮件,让您感觉特别。最后,这不是问题吗,您的开发人员认为这会让他们变得特别?

于 2008-10-08T11:54:16.027 回答
1

每个软件开发人员都希望构建自己的错误跟踪系统。这是因为我们显然可以改进已有的东西,因为我们是领域专家。

这几乎肯定不值得(就开发人员的时间而言)。只需购买JIRA

如果您的错误跟踪系统需要额外的报告,您可以添加这些报告,即使您必须通过直接访问底层数据库来完成。

于 2008-09-15T11:46:23.607 回答
1

问题是你的公司付钱给你做什么?是编写只有你会使用的软件吗?显然不是。因此,您可以证明构建错误跟踪系统的时间和费用合理的唯一方法是,它的成本是否低于使用免费错误跟踪系统的相关成本。

很可能在某些情况下这是有道理的。您是否需要与现有系统集成?(时间跟踪、估计、需求、QA、自动化测试)?您的组织是否有一些与 SOX 合规性相关的独特要求,这些要求需要难以捕获的特定数据元素?

您是否处于一个极度官僚主义的环境中,导致项目之间出现大量“停机时间”?

如果这些类型的问题的答案是肯定的——那么无论如何“购买”与构建的争论都会说构建。

于 2008-09-15T11:59:47.833 回答
1

因为Trac存在。

而且因为您必须培训新员工使用您的定制软件,因为他们可能有其他系统的经验,您可以在这些系统上构建而不是丢弃。

于 2008-09-15T12:19:45.650 回答
1

因为除非您打算出售它,否则它不是计费时间甚至非常有用。

有非常好的错误跟踪系统可用,例如FogBugz

于 2008-09-15T12:33:46.550 回答
1

如果“需要一些高度专业化的报告,或者以某种据称独特的方式调整某些功能的能力”,那么最好和最便宜的方法是与现有错误跟踪系统的开发人员交谈。付钱让他们将该功能放入他们的应用程序中,让全世界都可以使用它。与其重新发明轮子,不如付钱给轮子制造商,让他们安装形状像弹簧的辐条。

否则,如果试图展示一个框架,一切都很好。只需确保放入相关的免责声明即可。

对于那些认为错误跟踪系统构建不难的人,请严格遵循瀑布 SDLC。预先了解所有要求。这肯定会帮助他们理解复杂性。这些人通常说搜索引擎并不难构建。只是一个文本框、一个“搜索”按钮和一个“我感觉很幸运”按钮,而“我感觉很幸运”按钮可以在第 2 阶段完成。

于 2008-09-15T12:46:44.197 回答
1

我在一家初创公司工作了几年,我们从开源工具GNATS开始,并在此基础上构建了我们自己精心设计的错误跟踪系统。争论是我们将避免在商业系统上花费大量资金,并且我们将获得一个完全适合我们需求的错误跟踪系统。

当然,结果比预期的要困难得多,并且对开发人员来说是一个很大的分心 - 除了我们的代码之外,他们还必须维护错误跟踪系统。这是导致我们公司倒闭的因素之一。

于 2008-09-15T13:32:44.053 回答
1

按原样使用一些开源软件。肯定有错误,您将需要尚不存在或正在等待错误修复的内容。它一直在发生。:)

如果您扩展/自定义一个开源版本,那么您必须维护它。现在,应该帮助您测试赚钱应用程序的应用程序将成为支持的负担。

于 2008-09-15T13:33:29.230 回答
1

我认为人们编写自己的错误跟踪系统的原因(根据我的经验)是,

  1. 他们不想为他们认为相对容易构建的系统付费。
  2. 程序员自我
  3. 对现有系统提供的体验和解决方案普遍不满意。
  4. 他们将其作为产品出售:)

对我来说,大多数错误跟踪器失败的最大原因是它们没有提供最佳的用户体验,并且在没有针对可用性进行优化的情况下,使用你使用很多的系统可能会非常痛苦。

我认为另一个原因与几乎我们每个人(程序员)在某个时候构建自己的自定义 CMS 或 CMS 框架的原因相同(有罪)。只因为你可以!

于 2008-10-30T10:58:32.803 回答
1

我同意所有不这样做的理由。我们尝试了一段时间来使用那里的东西,最终还是自己写了。为什么?主要是因为他们中的大多数都太麻烦了,除了技术人员之外,其他人都无法参与。我们甚至尝试过大本营(当然,它不是为此而设计的,并且在这方面失败了)。

我们还提出了一些对我们的客户非常有效的独特功能:一个“报告错误”按钮,我们用一行 javascript 将其编写成代码。它允许我们的客户打开一个小窗口,快速记录信息并提交到数据库。

但是,编码肯定要花很多时间。变成了一个BIG宠物项目;很多周末时间。

如果你想看看:http ://www.archerfishonline.com

希望得到一些反馈。

于 2008-11-21T16:26:47.927 回答
1

我们已经这样做了......几次。我们建造自己的唯一原因是因为它是五年前的事,而且没有很多好的替代品。但现在有很多替代品。我们在构建自己的工具时学到的主要内容是,您将花费大量时间来处理它。那是你可以为你的时间计费的时候了。作为一家小企业,每月支付一两个计费小时即可轻松收回的月费比花费所有时间自己滚动更有意义。当然,你必须做出一些让步,但从长远来看,你会过得更好。

至于我们,我们决定将我们的应用程序提供给其他开发人员。在http://www.myintervals.com上查看

于 2009-01-02T23:07:12.217 回答
0

我同意这里的大多数人。当有许多工具(甚至是免费的)可用时,重建某些东西是没有用的。如果您想自定义任何东西,大多数免费工具都会为您提供代码,并使用它。

如果你做新的开发,你不应该只为自己做。

于 2008-09-15T12:35:46.640 回答
0

假设明天(明年),如果他们决定为公司的所有错误跟踪系统引入一个流行的开源/商业工具,该工具如何能够将其所有错误票导出到另一个工具?

只要确实需要自定义错误跟踪系统,并且回答了此类问题,我就不会打扰太多。

于 2008-10-07T19:49:51.280 回答
0

已经有这么多伟大的了,为什么要浪费时间重新发明轮子呢?

只需使用FogBugz

于 2008-10-07T19:56:47.410 回答
0

不要为了“吃自己的狗粮”而编写自己的软件。你只是在创造更多的工作,而你可能会以更少的时间和金钱购买做同样事情(并且更好)的软件。

于 2008-10-23T02:57:15.000 回答
0

我不认为构建内部跟踪系统相对容易构建,而且肯定不会匹配付费或开源解决方案。大多数时候,我会追求“程序员的自我”,或者只是拥有一个确实不能使用第三方软件并且必须构建几乎所有使用的软件的 IT 部门。

有一次我在一家拥有自己内部版本控制系统的电信公司工作,这很糟糕,但它让整个团队都忙得不可开交……

于 2008-10-30T11:26:58.360 回答
0

告诉他们,那太好了,公司可以暂时节省一些钱,并且很乐意在您从事这个无薪休假期间贡献开发工具。任何希望休年假来从事该项目的人都可以这样做。

于 2009-03-20T02:25:12.827 回答
0

我已经建立了自己的错误跟踪系统。我也想:“这有多难,它只是一个错误跟踪系统” ERR - 错误* - 花了六个月的时间编写它。

我自己烤的主要原因是为了得到我想要的。另一个原因是作为一个爱好项目。

我想说这是唯一有理由建立自己的项目是作为一个爱好项目。任何公司都不应该花时间去做这件事。

顺便说一下,我的软件叫做Bugweb

于 2010-06-05T04:34:46.460 回答