Reasons not to build your own bug tracking system现在，我几次遇到了一个团队的计划，这些团队想要构建自己的错误跟踪系统-不是作为产品，而是作为内部工具。 我经常听到的论点通常是：
您可以使用哪些参数来支持购买现有的错误跟踪系统？ 特别是，哪些功能听起来容易但难以实现，或者既困难又重要却经常被忽视？ 首先，查看以下Ohloh指标：
我们从这些数字中学到什么？我们了解到，构建"另一个Bug跟踪器"是浪费资源的好方法！ 因此，这就是我构建自己的内部错误跟踪系统的原因： 否则不要。
我想解决这个问题。为什么要在地球上建造自己的建筑？ 相信这并不困难吗？然后尝试。对其进行配置，然后查看功能列表和使用时间的增长。然后，在列表完成之后，尝试在实现自己的软件包之前找到一个可以修改的现有软件包。 简而言之，当另一个车轮只需要进行一些调整才能适合时，请不要重新发明车轮。 程序员喜欢构建自己的票务系统，因为看到并使用了许多票务系统，他们就知道了一切。这样，他们可以留在舒适区。 这就像去一家新餐厅一样：可能会有所收获，但是却有风险。最好再次订购披萨。 还有一个重要的事实，那就是要做决策：总有两个理由做某事：一个好的决定和一个正确的决定。我们做出一个决定("建立我们自己的")，然后证明其合理性("我们需要完全控制")。大多数人甚至都不知道自己的真正动机。 要改变主意，您必须攻击真正的原因，而不是辩解。 这里不是发明综合征！ 构建自己的错误跟踪器？为什么不构建自己的邮件客户端，项目管理工具等。 正如Omer van Kloeten在其他地方所说，现在付款或以后付款。
还有第三种选择，既不购买也不构建。有成堆的好免费的在那里。
滚动自己的错误跟踪器进行除学习以外的任何用途都不是浪费时间。 其他连结：
我只是说这是一个金钱问题-购买您知道对自己有利的成品(有时甚至免费购买甚至不买)比必须自己开发一个成品要好。这是一个简单的现在付款与以后付款的游戏。 首先，反对赞成建立自己的论点：
当然，这提出了一个问题，为什么要构建自己的Web框架。就像那里有许多有价值的免费错误跟踪程序一样，也有许多有价值的框架。我想知道您的开发人员是否优先考虑他们？谁在做使您公司赚钱的工作？ 好的，如果他们必须构建一个框架，则让它从构建企业用来赚钱的实际软件的过程中有机地演变。
正如其他人所说，抓住许多优秀的开源跟踪器之一并对其进行调整。
好吧，我在短短几周内就编写了BugTracker.NET的第一个版本，开始时没有任何C＃知识。但是现在，六年又一千小时后，仍然有大量未完成的功能请求，因此这完全取决于您希望错误跟踪系统执行的操作。多少电子邮件集成，源代码控制集成，权限，工作流，时间跟踪，计划估计等。错误跟踪器可以是主要的主要应用程序。
不需要购买。有很多好的开源软件：Trac，Mantis_Bug_Tracker，我自己的BugTracker.NET等。
如果您只是为自己创建它，那么您可以采取许多捷径，因为您可以硬连线。如果要在许多不同的情况下为许多不同的用户构建它，那么对可配置性的支持就很难。可配置的工作流程，自定义字段和权限。 我认为FogBugz和BugTracker.NET都必须具有良好的bug跟踪器的两个功能：1)集成传入和传出的电子邮件，以便整个有关bug的对话都与bug一起存在，而不是放在单独的电子邮件中线程，以及2)只需单击几下即可将屏幕截图转换为错误发布的实用程序。 对我来说，最基本的论点是时间损失。我怀疑它会在不到一两个月的时间内完成。为什么有很多好的错误跟踪系统可用，为什么要花时间？给我举一个您需要调整且不易使用的功能的示例。 我认为一个好的错误跟踪系统必须能够反映您的开发过程。非常定制的开发过程对公司/团队固有地不利。大多数敏捷实践都喜欢Scrum或此类事物，并且大多数错误跟踪系统都符合此类建议和方法。不要对此太官僚主义。 最重要的是，在完成之前，您将在哪里向bug跟踪器提交bug？ 不过实话说。这些工具已经存在，无需重新发明轮子。修改跟踪工具以添加某些特定功能是一回事(我之前修改过Trac)...重写其中一项只是愚蠢的。 您可以指出的最重要的一点是，如果他们只想添加几个专门的报告，则不需要完全解决方案。此外，"自制解决方案"最重要的地方是内部工具。谁在乎您在内部使用的内容，是否可以根据需要完成任务？ 错误跟踪系统可能是一个入门的初级开发人员的好项目。这是一个相当简单的系统，您可以使用它按照您的编码约定等对它们进行训练。让初级开发人员构建这样的系统相对便宜，并且他们可能会在客户看不到的地方犯错。 如果是垃圾，您可以将其丢弃，但是您可以给他们一种感觉，那就是如果使用它，对公司已经很重要的工作。对于初级开发人员而言，您不能为此付出任何代价，因为他们能够体验到整个项目的整个生命周期以及该项目将带来的知识转让的所有机会。 我们已经在这里完成了。我们十年前写了第一本。然后，我们将其升级为使用Web服务，这更多地是一种学习该技术的方式。我们最初这样做的主要原因是我们需要一个错误跟踪系统，该系统还可以生成版本历史记录报告和一些其他在商业产品中找不到的功能。 我们现在再次在考虑错误跟踪系统，并正在认真考虑迁移到Mantis并使用Mantis Connect添加我们自己的其他自定义功能。滚动我们自己的系统需要付出很大的努力。 我想我们也应该看看FogBugz :-) 作为一名从事已经很关键(或者至少很重要)的任务的程序员，不应让自己偏离尝试开发市场(开源或商业)中已有的东西的机会。 现在，您将尝试创建一个错误跟踪系统，以跟踪用于跟踪核心开发中的错误的错误跟踪系统。
第一： 对于企业开发团队，我们开始使用JIRA。我们需要一些额外的报告，SSO登录等。JIRA能够做到这一点，我们可以使用已经可用的插件对其进行扩展。由于代码已获得付费支持的一部分，因此我们仅花费很少的时间来编写用于登录的自定义插件。 建立在别人所说的基础上，而不是仅仅下载免费/开源的内容。如何下载它，然后完全根据自己的需要进行修改？我知道过去需要这样做。我安装了Bugzilla，然后对其进行了修改，以支持回归测试和测试报告(这是很多年前)。 除非您确信可以制造出更圆的轮子，否则不要重新发明轮子。 我一直在这场辩论的双方，所以让我在这里面对两个。 年轻的时候，我努力建立自己的错误跟踪系统。我只是强调了现成的东西无法做到的所有事情，我让管理层去做。他们选了谁来领导团队？我！这将是我成为团队领导者并在从设计到工具再到人员的各个方面发表意见的第一个机会。我很激动。因此，我的建议是检查推动该项目的人们的动机。 现在我年纪大了，再次遇到相同的问题，所以我决定选择FogBugz。它可以满足我们99％的需求，费用基本上为0。此外，Joel会向您发送个人电子邮件，让您感到特别。最后，这不是问题吗，您的开发人员认为这将使它们变得特别吗？ 在这一点上，如果在错误跟踪/票务方面没有新的大方向，那就只是重新发明轮子了。一般而言，这似乎是其他所有人的想法。 我想说，最大的绊脚石之一是困扰数据模型/工作流程。我预计这将花费很长时间，并且涉及在某些情况下应该对错误进行处理，真正构成错误的原因等诸多争论。如果您只是想推出一个错误，则不要花数月的时间来回讨论预先构建的系统，无论已经决定什么决定，大多数人都会学习如何使用它并充分利用它。选择开源的东西，如果需要的话，以后随时可以对其进行调整-这比从头开始制作自己的东西要快得多。 大多数开发人员认为他们拥有其他人无法拥有的某些独特能力，因此他们可以以某种方式创建一个独特的系统。 其中99％是错的。 您的公司有1％的员工机会是什么？ 您的讨论将从构成漏洞的原因开始，演变为要应用的工作流程，最后以关于如何管理软件工程项目的大量争论为结尾。你真的想要那个吗？ :-)不，不要想-去买一个！ 因为这不是可计费的时间，甚至不是非常有用的时间，除非您打算出售它。 有完善的错误跟踪系统，例如FogBugz。 每个软件开发人员都希望构建自己的错误跟踪系统。这是因为我们是领域专家，因此我们显然可以改善已有的内容。 几乎可以肯定，这笔钱不值得(就开发人员时间而言)。只需购买JIRA。 如果您的错误跟踪系统需要其他报告，则可以添加这些报告，即使您必须直接访问基础数据库也可以添加报告。 问题是您的公司付给您的费用是多少？是编写只供您使用的软件吗？明显不是。因此，唯一可以证明构建错误跟踪系统的时间和费用的方法是，其成本是否低于使用免费的错误跟踪系统所产生的成本。 在某些情况下，这很有意义。您需要与现有系统集成吗？ (时间跟踪，估计，需求，质量保证，自动化测试)？您在组织中是否有一些与SOX法规遵从相关的独特要求，这些要求需要难以捕获的特定数据元素？ 您是否处于极度美轮美environment的环境中，从而导致项目之间的大量"停机时间"？ 如果对这些类型的问题的回答是"是"，那么"买"与"构建"论点一定会说"构建"。 因为Trac存在。 并且，因为当新员工很可能具有其他可以构建而不是抛弃的系统的经验时，就必须对他们进行定制软件的培训。 如果"需要一些高度专业化的报告，或者需要以所谓的独特方式调整某些功能"，那么做到这一点的最佳和最便宜的方法就是与现有错误跟踪系统的开发人员进行交流。付钱给他们将该功能放入其应用程序，使其在世界范围内可用。无需重新设计车轮，只需付钱给车轮制造商来安装形状像弹簧的辐条。 否则，如果试图展示一个框架，那么一切都很好。只要确保输入相关的免责声明即可。 对于相信错误跟踪系统并不难构建的人们，请严格遵循瀑布式SDLC。预先获取所有要求。这肯定会帮助他们了解复杂性。这些人通常都是同一个人，他们说搜索引擎的构建并不难。可以在阶段2中完成一个文本框，一个"搜索"按钮和一个"我感到幸运"按钮，以及"我感到幸运"按钮。 我在一家初创公司工作了几年，在那里我们开始使用开源工具GNATS，并从本质上构建了我们自己精心设计的错误跟踪系统。他们的论点是，我们将避免在商业系统上花费很多钱，而我们将获得一个完全符合我们需求的错误跟踪系统。 当然，事实证明这比预期的要困难得多，并且对开发人员来说是一个很大的干扰-除了我们的代码外，他们还必须维护错误跟踪系统。这是导致我们公司倒闭的因素之一。
照原样使用一些开源软件。 如果扩展/自定义开源版本，则必须对其进行维护。现在，可以帮助您测试赚钱应用程序的应用程序将成为支持的负担。 我认为人们(根据我的经验)编写自己的错误跟踪系统的原因是， 对我来说，大多数Bug跟踪器失败的最大原因是，它们没有提供最佳的用户体验，并且在未针对可用性进行优化的情况下，使用使用LOT的系统可能会非常痛苦。 我认为另一个原因与为什么我们每个人(程序员)几乎都在某个时候建立自己的自定义CMS或CMS框架(有罪)相同。只是因为可以！ 我同意所有不同意的理由。我们尝试了一段时间以使用那里的内容，并且无论如何都要编写自己的内容。为什么？主要是因为他们中的大多数人太累了，无法吸引技术人员以外的任何人。我们甚至尝试了基地营(当然，基地营不是为此而设计的，并且在这方面失败了)。 我们还提出了一些与客户合作的独特功能："报告错误"按钮，我们使用一行JavaScript编写了脚本代码。它使我们的客户可以打开一个小窗口，快速输入信息并提交到数据库。 但是，编写代码肯定要花很多时间。成为一个大型宠物项目；很多周末时间。 如果您想检查一下：http://www.archerfishonline.com 希望得到一些反馈。 我们已经做了几次。我们建立自己的唯一原因是因为它是五年前的事，没有很多好的替代品。但是现在有很多替代方案。在构建自己的工具时，我们学到的主要知识是，您将花费大量时间来使用它。那是时候了，您可能需要为您的时间计费。作为一家小型企业，支付月费比花所有时间自己动手做更有意义，您可以轻松地用一个或两个可计费小时来偿还月费。当然，您必须做出一些让步，但从长远来看，您会变得更好。 对于我们来说，我们决定将我们的应用程序提供给其他开发人员。在http://www.myintervals.com上查看 我建立了自己的错误跟踪系统。我也想过："这有多难，它只是一个错误跟踪系统" ERR-WRONG *-花了六个月的时间来编写它。 我自己烘焙的主要原因是要完全按照我的要求获得它。另一个原因是作为一个爱好项目。 我想说的是，唯一可以证明的是建立自己的项目是作为一项业余项目。任何公司都不应花时间去做。 顺便说一下，我的软件叫做Bugweb。 假设明天(下一年)，如果他们决定为公司中的ALL bug跟踪系统引入流行的开源/商业工具，那么该工具将如何将其所有bug票证导出到其他工具？ 只要确实需要自定义错误跟踪系统，并且可以回答此类问题，我就不会太在意。 已经有那么多伟大的人了，为什么要浪费时间重新发明轮子呢？ 只需使用FogBugz。 不要仅仅编写自己的软件，那样您就可以"吃自己的狗食"。当您可能会花更少的时间和金钱购买可以做同样(更好)功能的软件时，您将创造更多的工作。 我不认为构建内部跟踪系统相对容易构建，并且肯定不会与付费或开源解决方案匹配。大多数时候，我会去"程序员自我"，或者只是拥有一个IT部门，它实际上不能使用第三方软件，而实际上必须构建所使用的每一个软件。 当我在一家拥有自己的内部版本控制系统的电信公司工作时，这简直糟透了，但它却使整个团队忙碌起来... 告诉他们，太好了，该公司可以节省一些时间，并且很高兴在您进行无薪休假的同时提供开发工具。任何希望休年假来从事该项目工作的人都可以这样做。
我同意这里的大多数人。当有许多可用的工具(甚至免费)时，重建某些东西是没有用的。 如果您进行新的开发，则不应该只为自己做。 |
