不构建自己的错误跟踪系统的原因[关闭]
https://stackoverflow.com/questions/62153
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
现在我已经多次遇到一个团队的计划，他们想要构建自己的错误跟踪系统 - 不是作为产品，而是作为内部工具。
我听到的赞成的论点通常是这样的：
- 想要通过一些内部构建的网络框架“吃我们自己的狗粮”
- 需要一些高度专业化的报告，或者能够以某种据称独特的方式调整某些功能
- 相信构建一个错误跟踪系统并不困难
您可以使用什么论据来支持购买现有的错误跟踪系统？特别是，哪些功能听起来很容易但实际上很难实现，或者是困难但重要但经常被忽视？
解决方案
首先，看看这些 奥洛 指标：
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 是浪费资源的好方法！
以下是我构建自己的内部错误跟踪系统的原因：
- 你需要在一两年内消灭所有的 bozocoder。
- 你需要存一些钱以避免明年的预算减少。
否则不要。
其他提示
我想扭转这个问题。你到底为什么要自己建造？
如果您需要一些额外的字段，请使用可以修改的现有包。
特别报告？进入数据库并进行创建。
相信这并不困难吗？那就试试吧。对其进行规范，并查看功能列表和时间的增长。然后，在列表完成后，尝试找到一个可以修改的现有包，然后再实现自己的包。
简而言之，当另一个轮子只需要一些调整来适应时，不要重新发明轮子。
程序员喜欢构建自己的票务系统，因为在看过并使用过数十个票务系统后，他们对它了如指掌。这样他们就可以留在舒适区。
这就像去一家新餐厅一样：这可能会带来回报，但也存在风险。最好再点披萨。
其中还隐藏着一个重要的决策事实：做某事总是有两个原因：一个好的和正确的。我们做出决定（“建立我们自己的”），然后证明它的合理性（“我们需要完全控制”）。大多数人甚至不知道自己的真正动机。
要改变他们的想法，你必须攻击 真实的 原因，而不是理由。
还有第三种选择，既不购买也不建造。那里有很多好的免费软件。例如：
除了学习之外，自行开发错误跟踪器并不是一种很好的时间利用方式。
其他链接：
我只想说这是一个钱的问题 - 购买一个你知道对你有好处的成品（有时甚至不购买如果它是免费的）比必须自己开发一个要好。这是一个简单的游戏 现在付款 与 以后支付.
首先，反对支持构建自己的论点：
想要通过一些内部构建的网络框架“吃我们自己的狗粮”
这当然提出了一个问题：为什么要构建自己的 Web 框架。就像有许多有价值的免费错误跟踪器一样，也有许多有价值的框架。我想知道你们的开发人员是否有明确的优先事项？谁在做让你的公司真正赚钱的工作？
好吧，如果他们必须构建一个框架，那就让它从构建您的企业用来赚钱的实际软件的过程中有机地发展。
需要一些高度专业化的报告，或者能够以某种据称独特的方式调整某些功能
正如其他人所说，抓住众多优秀的开源跟踪器之一并对其进行调整。
相信构建一个错误跟踪系统并不困难
好吧，我写了我的第一个版本 BugTracker.NET 在短短几周内，从没有任何 C# 知识开始。但现在，六年零几千小时过去了，仍然有一大堆未完成的功能请求，所以这一切都取决于您希望错误跟踪系统做什么。有多少电子邮件集成、源代码控制集成、权限、工作流程、时间跟踪、进度估计等。错误跟踪器可以是一个非常非常重要的应用程序。
您可以使用什么论据来支持购买现有的错误跟踪系统？
不需要买。好的开源的太多了： 特拉克, Mantis_Bug_Tracker, ，我自己的 BugTracker.NET，仅举几例。
特别是，哪些功能听起来很容易但实际上很难实现，或者是困难但重要但经常被忽视？
如果您只是为自己创建它，那么您可以采取很多捷径，因为您可以对事物进行硬连接。如果您要在许多不同的场景中为许多不同的用户构建它，那么对可配置性的支持就很困难。可配置的工作流程、自定义字段和权限。
我认为有两个特点 好的 错误跟踪器必须具备，两者 雾虫 BugTracker.NET 具有以下功能：1) 集成传入和传出电子邮件，以便有关错误的整个对话与错误一起存在，而不是在单独的电子邮件线程中，以及 2) 用于将屏幕截图转换为错误帖子的实用程序只需点击几下。
对我来说最基本的论点是时间损失。我怀疑它能否在不到一两个月的时间内完成。既然有这么多好的错误跟踪系统可用，为什么要花时间呢？请举一个您必须调整且不易获得的功能的示例。
我认为一个好的错误跟踪系统必须反映您的开发过程。非常定制的开发流程对于公司/团队来说本质上是不好的。大多数敏捷实践都青睐 Scrum 或这类事情，大多数错误跟踪系统都符合此类建议和方法。不要对此过于官僚化。
对于初级开发人员来说，错误跟踪系统可能是一个很棒的项目。这是一个相当简单的系统，您可以用它来训练他们的编码约定等。让初级开发人员构建这样的系统相对便宜，而且他们可能会在客户看不到的事情上犯错误。
如果它是垃圾，你可以把它扔掉，但如果使用它，你可以给他们一种工作已经对公司很重要的感觉。您不能为初级开发人员付出成本，让其体验整个生命周期以及此类项目带来的所有知识转移机会。
我们在这里已经做到了这一点。我们十多年前写了第一个。然后我们将其升级为使用网络服务，更多地作为学习技术的一种方式。我们最初这样做的主要原因是我们想要一个错误跟踪系统，该系统还可以生成版本历史报告和一些我们在商业产品中找不到的其他功能。
我们现在正在再次考虑错误跟踪系统，并正在认真考虑迁移到 Mantis 并使用 Mantis Connect 添加我们自己的其他自定义功能。推出我们自己的系统所付出的努力实在是太大了。
我想我们也应该看看 FogBugz :-)
最重要的是，在错误跟踪器完成之前，您将在哪里提交错误？
不过实话说。工具已经存在，不需要重新发明轮子。修改跟踪工具以添加某些特定功能是一回事（我已经修改了 特拉克 前）...重写一个只是愚蠢的。
您可以指出的最重要的事情是，如果他们想要做的只是添加几个专门的报告，则不需要从头开始的解决方案。此外，“您的自制解决方案”最后一个重要的地方是内部工具。如果你内部使用的东西能按你的需要完成工作，谁会在乎你在内部使用什么？
作为一名从事已经很关键（或者最不重要）的任务的程序员，不应该让自己因为尝试开发市场上已经存在的东西（开源或商业）而偏离。
现在，您将尝试创建一个错误跟踪系统来跟踪用于跟踪核心开发中的错误的错误跟踪系统。
第一的：1.选择您的错误系统将运行的平台（Java，PHP，Windows，Linux等）2。尝试在您选择的平台上找到可用的开源工具（通过开源，我的意思是商业和免费工具）。花最少的时间尝试根据您的需求进行定制。如果可能的话，根本不要浪费时间进行定制
对于企业开发团队，我们开始使用 吉拉. 。我们想要一些额外的报告、SSO 登录等。JIRA 能够做到这一点，我们可以使用现有的插件来扩展它。由于代码是付费支持的一部分，因此我们只花了很少的时间来编写用于登录的自定义插件。
以其他人所说的为基础，而不仅仅是下载免费/开源的。下载它，然后根据自己的需要完全修改它怎么样？我知道我过去曾被要求这样做。我安装了 Bugzilla，然后对其进行了修改以支持回归测试和测试报告（这是很多年前的事了）。
除非您确信自己可以制造出更圆的轮子，否则不要重新发明轮子。
我想说最大的障碍之一是数据模型/工作流程的痛苦。我预测这将需要一个 长的 时间并涉及许多关于在某些情况下错误应该发生什么、真正构成错误等的争论。如果您只是推出一个预先构建的系统，那么大多数人都会学习如何使用它并充分利用它，而不是花费数月的时间来来回回地争论，无论已经确定了什么决定。选择开源的东西，如果需要的话，你可以随时调整它——那就是 很多 比从头开始自己动手更快。
在这一点上，如果没有错误跟踪/票务方面的重大新方向，那就只是重新发明轮子。一般来说，这似乎是其他人的想法。
您的讨论将从什么构成错误开始，然后发展到应用什么工作流程，最后以关于如何管理软件工程项目的大量争论结束。你真的想要那个吗？:-) 不，没想到 - 去买一个吧！
大多数开发人员认为他们拥有一些其他人没有的独特能力，因此他们可以创建一个在某种程度上独一无二的系统。
99%的人都错了。
贵公司拥有 1% 员工的可能性有多大？
我一直站在这场辩论的正反两方，所以让我在这里扮演一个两面派的角色。
当我年轻的时候，我推动建立我们自己的错误跟踪系统。我只是强调了所有现成的东西无法做到的事情，并且我让管理层去做。他们选择谁来领导团队？我！这将是我第一次有机会成为团队领导，并在从设计到工具到人员的各个方面拥有发言权。我很兴奋。所以我的建议是检查推动这个项目的人的动机。
现在我长大了，再次面临同样的问题，我决定选择 FogBugz。它可以满足我们99%的需求，而且成本基本为0。此外，乔尔还会向您发送私人电子邮件，让您感觉很特别。最后，这不是问题吗？您的开发人员认为这会让他们变得特别吗？
每个软件开发人员都希望构建自己的错误跟踪系统。这是因为我们可以 明显地 由于我们是领域专家，因此可以改进已有的内容。
几乎可以肯定，这不值得付出成本（就开发人员的时间而言）。就买 吉拉.
如果您的错误跟踪系统需要额外的报告，您可以添加这些报告，即使您必须通过直接访问底层数据库来完成此操作。
问题是你的公司付钱给你做什么？是编写只有你会使用的软件吗？很明显不是。因此，证明构建错误跟踪系统的时间和费用合理的唯一方法是，它的成本是否低于使用免费错误跟踪系统的相关成本。
在某些情况下，这很可能是有意义的。您需要与现有系统集成吗？（时间跟踪、估算、需求、质量保证、自动化测试）？您的组织中是否有一些与 SOX 合规性相关的独特要求，需要难以捕获的特定数据元素？
您是否处于一个极其官僚的环境中，导致项目之间出现严重的“停机时间”？
如果这些类型的问题的答案是肯定的，那么无论如何，“购买”与构建的争论都会说构建。
如果“需要一些高度专业化的报告，或者以某种据称独特的方式调整某些功能的能力”，最好和最便宜的方法是与现有错误跟踪系统的开发人员交谈。付钱给他们，让他们将该功能放入他们的应用程序中，让全世界都可以使用。与其重新发明车轮，只需付钱给车轮制造商，让他们安装弹簧形状的辐条即可。
否则，如果尝试展示一个框架，那一切都很好。只需确保添加相关免责声明即可。
对于那些认为错误跟踪系统并不难构建的人来说，请严格遵循瀑布SDLC。预先写下所有要求。这肯定会帮助他们理解复杂性。这些人通常都说搜索引擎的构建并不难。只需一个文本框、一个“搜索”按钮和一个“我感觉很幸运”按钮，“我感觉很幸运”按钮可以在第二阶段完成。
按原样使用一些开源软件。肯定存在错误，并且您将需要尚不存在或正在等待错误修复的内容。这种事一直在发生。:)
如果您扩展/定制开源版本，那么您必须维护它。现在该应用程序应该可以帮助您进行测试 赚钱的应用程序 将成为支撑的负担。
我认为人们编写自己的错误跟踪系统的原因（根据我的经验）是，
- 他们不想为他们认为相对容易构建的系统付费。
- 程序员自我
- 对现有系统提供的体验和解决方案普遍不满意。
- 他们将其作为产品出售:)
对我来说，大多数错误跟踪器失败的最大原因是它们没有提供最佳的用户体验，并且当您经常使用的系统未针对可用性进行优化时，使用该系统可能会非常痛苦。
我认为另一个原因与为什么我们几乎每个人（程序员）都在某个时候构建了自己的定制 CMS 或 CMS 框架（有罪）是一样的。只因为你可以！
我同意所有不这样做的理由。我们尝试了一段时间使用现有的东西，但最终还是编写了我们自己的。为什么？主要是因为它们中的大多数都太麻烦，除了技术人员之外无法与任何人合作。我们甚至尝试过 Basecamp（当然，它不是为此设计的，并且在这方面失败了）。
我们还提出了一些对我们的客户非常有用的独特功能：一个“报告错误”按钮，我们用一行 JavaScript 将其编写为代码。它允许我们的客户打开一个小窗口，快速记下信息并提交到数据库。
但是，编码确实花费了很多时间；成为一个大的宠物项目；周末时间很多。
如果你想查看一下： http://www.archerfishonline.com
希望得到一些反馈。
我们已经做到了这一点...几次。我们建立自己的唯一原因是因为那是五年前，没有太多好的替代方案。但现在有很多选择。我们在构建自己的工具时学到的主要内容是，您将花费大量时间来处理它。这就是你可以为你的时间计费的时间。作为一家小型企业，支付月费更有意义，您可以轻松地通过一两个计费小时收回费用，而不是花费所有时间自己进行操作。当然，你必须做出一些让步，但从长远来看，你的处境会好得多。
对于我们来说，我们决定将我们的应用程序提供给其他开发人员。检查一下： http://www.myintervals.com
因为 特拉克 存在。
因为您必须对新员工进行定制软件培训，而他们可能拥有其他系统的经验，您可以在这些系统上进行构建而不是丢弃。
因为这不是计费时间，甚至非常有用，除非您打算出售它。
有非常好的错误跟踪系统可用，例如， 雾虫.
我在一家初创公司工作了几年，我们从 蚊虫, ，一个开源工具，本质上是在它的基础上构建了我们自己的精心设计的错误跟踪系统。争论的焦点是，我们将避免在商业系统上花费大量资金，并且我们将获得完全适合我们需求的错误跟踪系统。
当然，事实证明这比预期要困难得多，并且对开发人员来说是一个很大的干扰 - 除了我们的代码之外，他们还必须维护错误跟踪系统。这是导致我们公司消亡的因素之一。
不要仅仅为了“吃自己的狗粮”而编写自己的软件。您只是在创造更多的工作，而您可能可以花更少的时间和金钱购买做同样事情（而且更好）的软件。
告诉他们， 太好了，公司可以暂时节省一些钱，并且很乐意在您享受无薪休假期间贡献开发工具。任何希望休年假来参与该项目的人都可以自由这样做。
