不build立你自己的错误跟踪系统的原因
现在好几次，我都遇到了一个团队的计划，他们想要build立自己的bug跟踪系统 – 不是作为一个产品，而是作为一个内部工具。
我所听到的赞同的论据通常是：
- 想要根据一些内部build立的networking框架来“吃我们自己的狗粮”
- 需要一些高度专业化的报告，或以某种独特的方式调整某些function的能力
- 相信build立一个bug跟踪系统并不困难
你可以使用什么参数来支持购买现有的错误跟踪系统？ 特别是声音容易，难以实现，还是困难重要，但往往被忽视？
首先，看看这些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 我们从这些数字中学到了什么？ 我们了解到，构build另一个Bug跟踪器是浪费资源的好方法！
所以这里是我build立你自己的内部错误跟踪系统的原因：
- 你需要中和所有的Bozocoders十年或两年。
- 你需要花一些钱来避免明年的预算削减。
否则不要。
我想要解决这个问题。 为什么你要build立你自己的？
如果你需要一些额外的领域，去现有的包可以修改。
特别报道？ 点击数据库，并使其成为可能。
相信这并不难？ 试试吧。 详细说明，看看function列表和小时数增长。 然后在列表完成之后，尝试find一个可以修改的现有软件包，然后再实现自己的软件包。
总之，当另外一个人需要调整一下时，不要重新发明轮子。
程序员喜欢build立自己的票务系统，因为他们已经看到并使用了数十个，他们知道这一切。 这样他们可以留在舒适的区域。
这就像检查一家新餐厅：这可能是有益的，但它有风险。 最好再点一次披萨。
还有一个很大的决策埋在这里的事实：总是有两个理由去做：一个是好的，一个是正确的。 我们做出决定（“build立自己的”），然后certificate它（“我们需要完全控制”）。 大多数人甚至没有意识到自己的真正动机。
要改变主意，你必须去攻击真正的原因，而不是理由。
这里没有发明综合征！
build立你自己的错误跟踪器？ 为什么不build立自己的邮件客户端，项目pipe理工具等
正如Omer van Kloeten在其他地方所说的那样 ，现在支付或者稍后支付。
还有第三种select，既不买也不build。 那里有一堆好的免费的。 例如：
- Bugzilla的
- TRAC
除了学习之外，将自己的错误跟踪器用于其他任何用途都不是很好的使用时间。
其他链接：
- 三个免费的错误跟踪工具
- 问题跟踪系统的比较
我只想说这是一个金钱问题 – 买一个你知道对你有好处的成品（有时候甚至不买，如果它是免费的）总比自己去开发一个好。 这是一个简单的现在 支付与以后 支付的游戏。
首先，反对赞成build立自己的论点：
想要根据一些内部build立的networking框架来“吃我们自己的狗粮”
当然，这就提出了为什么要构build自己的Web框架的问题。 就像那里有许多有价值的免费bug跟踪器一样，还有许多有价值的框架。 我想知道你的开发者是否有优先权？ 谁在做让你公司真正赚钱的工作？
好吧，如果他们必须build立一个框架，让它从build立你的企业用于赚钱的实际软件的过程中有机地演变而来。
需要一些高度专业化的报告，或以某种独特的方式调整某些function的能力
正如其他人所说，抓住许多优秀的开源追踪器之一，并调整它。
相信build立一个bug跟踪系统并不困难
好吧，我在几个星期内写了我的BugTracker.NET的第一个版本，从没有以前的C＃知识开始。 但是现在，6年以及几千个小时之后，仍然有大量的未完成的function请求，所以这一切都取决于你想要一个错误跟踪系统。 多less电子邮件集成，源代码控制集成，权限，工作stream程，时间跟踪，进度估算等。错误跟踪器可以是主要的主要应用程序。
你可以使用什么参数来支持购买现有的错误跟踪系统？
不需要购买。有很多很好的开源软件： Trac ， Mantis_Bug_Tracker ，我自己的BugTracker.NET，等等。
特别是声音容易，难以实现，还是困难重要，但往往被忽视？
如果你只是为自己创造它，那么你可以采取很多快捷方式，因为你可以硬线的东西。 如果你正在为很多不同的用户构build它，在很多不同的场景下，那么对可configuration性的支持是很难的。 可configuration的工作stream程，自定义字段和权限。
我认为BugBugz和BugTracker.NET都有一个好的 bug追踪器必须具备的两个function是：1）整合传入和传出的电子邮件，这样整个关于错误的对话就可以在错误中生存，而不是在单独的电子邮件中线程，和2）一个实用工具，只需点击几下，即可将屏幕截图转换为错误信息。
对我来说最基本的理由是时间损失。 我怀疑这可能在不到一个月或两个月内完成。 为什么花时间有很多好的bug跟踪系统？ 给我一个function的例子，你必须调整，并不容易获得。
我认为一个好的错误跟踪系统必须反映你的开发过程。 一个非常自定义的开发过程对于一个公司/团队来说本质上是坏的。 大多数敏捷实践都支持Scrum或这些types的东西，大多数bug跟踪系统都符合这些build议和方法。 不要太官僚化。
错误跟踪系统可能是一个很好的项目，启动初级开发人员。 这是一个相当简单的系统，你可以用你的编码习惯等等来训练它们。 让初级开发者build立这样的系统相对便宜，他们可以在客户看不到的东西上犯错误。
如果它是垃圾，你可以把它扔掉，但是如果它被使用的话，你可以给他们一个对公司工作已经很重要的感觉。 对于初级开发人员来说，不能把经验花费在一个完整的生命周期中，并且这个项目将带来的所有知识转移的机会。
我们在这里做了。 我们写了十多年前的第一本。 然后，我们将其升级为使用Web服务，更多的是作为学习技术的一种方式。 我们之所以这样做的主要原因是我们想要一个缺陷跟踪系统，它也生成了版本历史报告和一些我们在商业产品中找不到的其他function。
我们现在正在重新研究bug跟踪系统，并正在认真考虑迁移到螳螂，并使用Mantis Connect来添加我们自己的其他自定义function。 滚动我们自己的系统的努力量太大了。
我想我们也应该看看FogBugz 🙂
最重要的是，在完成之前，你会在哪里提交错误跟踪器的错误？
不过实话说。 工具已经存在，没有必要重新发明轮子。 修改跟踪工具来添加某些特定的function是一回事（我之前修改过Trac ），重写一个只是愚蠢的。
你可以指出的最重要的事情是，如果他们想要做的只是添加一些专门的报告，它不需要一个解决scheme。 而且，最后的地方“你的自制解决scheme”重要的是内部工具。 谁在乎你在内部使用什么，如果它在你需要的时候完成工作？
作为一个已经是关键（或者最不重要）任务的程序员，不应该让自己偏离开发市场上已有的东西（开源或商业）。
现在，您将尝试创build一个缺陷跟踪系统，以跟踪用于跟踪核心开发中错误的缺陷跟踪系统。
首先：1.select您的bug系统将运行的平台（Java，PHP，Windows，Linux等）2.尝试在平台上find可用的开源工具（开源，我的意思是商业和免费工具）你select了3.花最less的时间去尝试定制你的需要。 如果可能的话，不要浪费时间进行定制
对于一个企业开发团队，我们开始使用JIRA 。 我们想要一些额外的报告，SSOlogin等JIRA是有能力的，我们可以扩展它使用已经可用的插件。 由于代码被赋予了付费支持的一部分，我们只花最less的时间编写自定义login插件。
基于别人的说法，而不只是下载一个免费/开源的。 如何下载它，然后完全根据自己的需要进行修改？ 我知道我过去一直被要求这样做。 我安装了Bugzilla，然后对其进行了修改，以支持回归testing和testing报告（这是很多年前的事情）。
除非你确信你可以build造一个圆形的车轮，否则不要重新发明车轮。
我会说最大的绊脚石之一就是在数据模型/工作stream程上苦苦挣扎。 我预测这将需要很长时间，并且涉及许多争论，在某些情况下会发生什么错误，真正构成错误的是什么等。与其花费数月时间来回争论，如果您只是推出一个预制系统，大多数人都会学习如何使用它，并做到最好，不pipe哪个决定已经修好。 select一些开放源码的东西，如果需要的话，你可以随时调整它 – 这将比从头开始自己动手更快。
在这一点上，没有一个新的bug追踪/票务新方向，它只是重新发明车轮。 一般来说，这似乎是所有人都认为的。
您的讨论将从构成错误的问题开始，并演变成应用的工作stream程，并最终就如何pipe理软件工程项目进行大规模争论。 你真的想要吗？ :-)不，不要以为 – 去买一个！
大多数开发人员认为他们有一些独一无二的力量，因此他们可以创build一个独特的系统。
其中99％是错误的。
贵公司有1％的员工有什么机会？
我一直在这个辩论的两边，所以让我在这里面一点点。
当我年轻时，我推动build立我们自己的错误跟踪系统。 我只是强调了现成的东西不能做的所有事情，我得到了pipe理层的帮助。 他们选谁来领导这个团队？ 我！ 这将是我第一次成为团队负责人，并且从devise到工具到人员都有发言权。 我很激动。 所以我的build议是检查推动这个项目的人的动机。
现在我年纪大了，再次面对同样的问题，我只是决定和FogBugz一起去。 它占我们所需要的99％，成本基本上是0.另外，Joel会给你寄个人电子邮件，让你感觉特别。 而最终，这不是问题，你的开发人员认为这会使他们变得特别吗？
每个软件开发者都想build立自己的bug跟踪系统。 因为我们是领域专家，所以我们显然可以改进已经存在的内容。
这几乎肯定不值得（在开发人员时间方面）。 只要购买JIRA 。
如果你需要额外的bug追踪系统报告，你可以添加这些报告，即使你必须直接访问底层数据库。
问题是你公司付钱给你做什么？ 是否只写软件才会使用？ 很明显不是。 因此，build立bug跟踪系统的时间和费用的唯一方法就是花费less于使用免费bug跟踪系统的成本。
有可能的情况下，这是有道理的。 你需要整合现有的系统吗？ （时间跟踪，估算，要求，QA，自动化testing）？ 你们组织中是否有一些与SOX合规性相关的独特要求，要求特定的数据元素很难被捕获？
你是否处于一个非常优秀的环境中，导致项目之间的重大“停顿”？
如果对这些types的问题的答案是肯定的，那么通过所有的方式来说，“购买”与“构build”的争论就是build立。
如果“需要一些高度专业化的报告，或者以某种独特的方式来调整某些function”，那么最好和最便宜的方法就是与现有缺陷跟踪系统的开发者进行交stream。 支付他们把这个function放在他们的应用程序中，让它可用于世界。 而不是重新发明车轮，只需支付车轮制造商像辐射形状像弹簧。
否则，如果试图展示一个框架，它的一切都很好。 只要确保input相关的免责声明。
对于那些相信臭虫追踪系统的人来说不难构build，严格遵循瀑布SDLC。 获得所有的要求。 这一定会帮助他们理解复杂性。 这些人通常都是说一个search引擎不是很难构build的。 只是一个文本框，一个“search”button和一个“我感觉幸运”的button，“我感觉幸运”button可以在第二阶段完成。
按原样使用一些开源软件 。 确定有错误，你将需要什么还没有或正在等待一个错误修复。 它总是发生。 🙂
如果您扩展/定制开源版本，那么您必须维护它。 现在想要帮助您testing赚钱应用程序的应用程序将成为支持的一个负担。
我认为人们编写自己的错误跟踪系统的原因（以我的经验）
- 他们不想为他们认为相对容易构build的系统付费。
- 程序员自我
- 普遍不满现有系统提供的经验和解决scheme。
- 他们把它作为产品出售:)
对我来说，大多数错误跟踪器失败的最大原因是它们没有提供最佳的用户体验，而且在使用LOT的系统上工作时，可能会非常痛苦。
我认为另外一个原因与我们为什么几乎每个人（程序员）都在某个时候（有罪感）都构build了自己的定制CMS或CMS框架的原因是一样的。 只因为你可以！
我同意所有的理由不。 我们尝试了一段时间来使用那里的东西，并且无论如何写了我们自己的东西。 为什么？ 主要是因为他们中的大多数人太麻烦，除了技术人员之外，谁也不能参与其中。 我们甚至试过基地营（当然，这不是为此而devise的，在这方面失败了）。
我们还想出了一些与客户合作的独特function：“报告错误”button，我们用一行javascript脚本编写代码。 它允许我们的客户打开一个小窗口，快速记下信息并提交给数据库。
但是，编码确实花了很多时间。 成为一个大宠物项目; 很多周末时间。
如果你想看看： http : //www.archerfishonline.com
会喜欢一些反馈。
我们已经做了几次… 我们build立自己的唯一原因是因为五年前，没有太多好的select。 但现在有很多替代品。 我们在构build自己的工具时学到的主要内容是，您将花费大量的时间来处理它。 那是时候你可以为你的时间计费了。 作为一个小企业，作为一个小企业，付出一个或两个计费小时很容易收回的月费，比花费所有的时间来滚动自己的费用更有意义。 当然，你必须做出一些让步，但从长远来看，你会好得多。
至于我们，我们决定让我们的应用程序可供其他开发人员使用。 在http://www.myintervals.com查看;
因为Trac存在。
而且，由于您必须在定制软件上培训新员工，因为他们可能有其他系统的经验，而您可以在其他系统上使用，而不是丢弃。
因为除非你打算出售它，否则它不是可计费的时间，甚至是非常有用的。
有完美的错误跟踪系统可用，例如， FogBugz 。
我在一家创业公司工作了好几年，在那里我们开始使用GNATS ，这是一个开源工具，并且基本上build立了我们自己的精心devise的bug跟踪系统。 我们的观点是，我们将避免在商业系统上花费大量资金，并且会得到一个完全符合我们需求的错误跟踪系统。
当然，结果比预期的要难得多，对于开发者来说也是一个很大的分心 – 除了我们的代码之外，他们还必须维护bug跟踪系统。 这是我们公司灭亡的原因之一。
不要自己写软件，以便“吃自己的狗粮”。 你只是创造更多的工作，当你可能购买软件，花费更less的时间和金钱做同样的事情（更好）。
告诉他们， 这太棒了，公司可以花一些时间来节省一些钱，并且很乐意在这个无偿的休假期间贡献开发工具。 任何想要休年假的人都可以自由地这样做。
