建立自己的漏洞跟踪系统不可取的原因

我认为人们编写自己的错误跟踪系统（根据我的经验）的原因有：

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

对我来说，大多数错误跟踪器失败的最大原因是它们没有提供最佳用户体验，当你使用一个未经优化的系统时，这可能会非常痛苦。

我认为另一个原因与我们中几乎每个人（程序员）在某个时候都建立自己的定制CMS或CMS框架的原因相同（有罪）。只是因为你可以！

每个软件开发者都想建立自己的Bug跟踪系统。这是因为我们可以显然地改进现有的内容，因为我们是领域专家。
从开发人员时间的角度来看，这几乎肯定不值得。只需购买JIRA即可。
如果您需要额外的Bug跟踪系统报告，即使必须通过直接访问基础数据库来实现，也可以添加这些报告。

问题是你的公司雇佣你做什么？是为了编写只有你自己使用的软件吗？显然不是。因此，你能够证明建立一个缺陷跟踪系统的时间和费用是合理的，唯一的方法是它的成本低于使用甚至免费的缺陷跟踪系统所涉及的成本。
这可能在某些情况下是有道理的。你需要与现有系统集成吗？（时间跟踪、估算、需求、QA、自动化测试）？你的组织中是否有一些与SOX合规性相关的独特要求，需要捕获特定的数据元素？
你是否处于极度官僚主义的环境中，导致项目之间存在重大的“停机时间”？
如果这些问题的答案是肯定的，那么毫无疑问，“购买”与“构建”的争论会说“构建”。

因为 Trac 的存在。
而且，当您可能需要在其他系统上建立的经验基础上培训新员工时，您会希望保留您定制软件的优势，而不是将其抛弃。

因为这不是计费时间，除非你打算出售它，否则它甚至没有什么用处。

有一些完全可以胜任的缺陷跟踪系统可供使用，例如FogBugz。

如果需要一些高度专业化的报告或者以某种独特的方式调整某些功能，最好、最便宜的方法是与现有缺陷跟踪系统的开发人员交谈。付钱让他们将该功能放入其应用程序中，并向全世界提供。与其重新发明轮子，不如付钱让轮子制造商安装弹簧形状的辐条。
否则，如果试图展示一个框架，那就没问题了。只需确保加入相关的免责声明即可。
对于那些认为缺陷跟踪系统不难建立的人，请严格遵循瀑布式软件开发生命周期。首先确定所有要求。这肯定会帮助他们理解复杂性。这些通常是那些说搜索引擎并不难建立的人。只需要一个文本框、一个“搜索”按钮和一个“我感觉幸运”按钮，而“我感觉幸运”按钮可以在第二阶段完成。

我曾在一家创业公司工作了几年，在那里我们起初使用了一个名为 GNATS 的开源工具，并在其基础上建立了自己的复杂缺陷跟踪系统。我们认为这样可以避免花费大量资金购买商业系统，并且能够得到完全适合我们需求的缺陷跟踪系统。

当然，情况远比预期的要困难得多，这也让开发人员分心——他们不得不除了编写代码外，还要维护缺陷跟踪系统。这是导致我们公司瓦解的因素之一。

直接使用一些开源软件。 当然，这些软件中可能存在着一些漏洞，你可能需要一些还未被修复的功能或者等待修复的漏洞。这种情况经常发生。 :)

如果你对开源软件进行扩展/定制，那么你必须自己维护它。现在，原本应该帮助你测试赚钱应用程序的应用程序将成为你支持的负担。

我自己搭建了一个Bug跟踪系统。最初我也以为：“有多难呢，只是个Bug跟踪系统而已” 错 - 错误* - 花了六个月的时间来编码。

我自己搭建的主要原因是为了让它完全符合我的想法。另一个原因是作为一个爱好项目。

我认为唯一正当的时候是当它作为一个爱好项目时才可以自己搭建。任何公司都不应该浪费时间去做这个。

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

假设明天（明年），如果他们决定引入一种流行的开源/商业工具作为公司内所有缺陷跟踪系统，那么这个工具如何能够将其所有缺陷票据导出到其他工具？
只要确实有一个定制的缺陷跟踪系统的真正需求，并且这样的问题得到了解答，我就不会过于担心。