現在有好幾次我一直在面對來自一個團隊的計劃，他們想要建立他們自己的錯誤跟蹤系統 - 不是作爲產品，而是作爲內部工具。不建立你自己的錯誤跟蹤系統的原因
我在favous聽到的論據通常是沿着線：
您可以使用哪些參數支持購買現有的錯誤跟蹤系統？特別是，哪些功能聽起來容易，但很難實現，或者困難重要但常常被忽略？
首先，看看這些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
什麼是我們從這些數字學習？我們瞭解到，構建另一個Bug跟蹤器是浪費資源的好方法！
因此，這裏有我的理由來構建自己的內部bug跟蹤系統：
否則不要。
對我來說最基本的理由是時間的流失。我懷疑它可能在不到一個月或兩個月內完成。爲什麼花時間在有很多好的錯誤跟蹤系統可用的時候呢？給我一個你不得不調整的功能的例子。
我認爲一個好的錯誤跟蹤系統必須反映你的開發過程。一個非常自定義的開發過程對於公司/團隊來說本質上是不利的。大多數敏捷實踐都支持Scrum或這些類型的事情，並且大多數錯誤跟蹤系統都符合這些建議和方法。不要爲此過分官僚主義。
我只想說這是一個金錢問題 - 買一個你知道對你有好處的成品（有時甚至在沒有免費的情況下甚至不買）比不得不自己去開發一個好。這是一個簡單的遊戲現在支付與以後支付。
由於_free software_不存在... – alternative 2011-07-24 14:40:01
並不是說它不存在，但通常當您在使用免費軟件的公司工作時，您會想要購買支持包，除非您想要開始修復它自己的錯誤（即稍後支付）。 – 2011-07-25 06:07:58
我想改變這個問題。爲什麼你想要建立你自己的？
如果您需要一些額外的字段，請使用可修改的現有程序包。
特別報道？點擊數據庫並設置好。
相信這並不困難？試試吧。詳細說明，並查看功能列表和小時數增長。然後在列表完成後，嘗試查找可以在實現自己的程序之前修改的現有程序包。
總之，當另一個人只需要調整一下就不要重新發明輪子。
我想說最大的絆腳石之一將是痛苦的數據模型/工作流程。我預測這將需要一段時間，並且涉及許多爭論，說明在某些情況下會發生什麼錯誤，真正構成錯誤的是什麼等。與其花費數月時間來回爭論，如果你只是滾動出於預先建立的系統，大多數人將學習如何使用它並充分利用它，而不管什麼決定已經修復。選擇一些開源的，你可以隨時調整它，如果需要的話 - 這將是多比自己從頭開始更快。
程序員喜歡建立他們自己的票務系統，因爲他們看到並使用了數十人，他們知道這件事的一切。這樣他們可以留在舒適區。
這就像檢查一家新餐廳：它可能是有益的，但它帶有風險。最好再點一次披薩。
還有一個很大的決策埋在這裏的事實：做事總是有兩個理由：一個好的，一個是正確的。我們做出決定（「建立自己的」），然後證明它（「我們需要完全控制」）。大多數人甚至沒有意識到他們的真正動機。
要改變主意，你必須攻擊真實的原因，而不是理由。
最重要的是，在完成之前，您會在哪裏提交錯誤跟蹤器的錯誤？
但嚴重。這些工具已經存在，不需要重新發明輪子。修改跟蹤工具以添加某些特定功能是一回事（我之前修改了Trac）......重寫一個只是愚蠢的。
您可以指出的最重要的事情是，如果他們想要做的只是添加一些專門的報告，它不需要一個解決方案。此外，最後的地方「你的自制解決方案」重要的是內部工具。誰在乎你在內部使用什麼，如果它能在你需要的時候完成工作？
在這一點上，沒有一個新的bug追蹤/票務新方向，它只會重新發明車輪。一般來說，這似乎是其他人認爲的。
你問的是修辭，但這*是我在很多地方看到的主要原因。錯誤跟蹤器在內部正是因爲它需要*集成*與其他所有內部的東西，通常在一個單一的整體應用程序與不良的開發實踐。 – bignose 2009-04-28 07:03:38
也有集成產品。然後是「中間件」的概念。我堅持我的回答。 – 2009-04-28 10:02:11
您的討論將從引發錯誤的問題開始，並演變爲應用的工作流程，並最終就如何管理軟件工程項目發起一場大規模的爭論。你真的想要嗎？ :-)不，沒想到 - 去買一個！
作爲一個從事已經非常關鍵（或最不重要）任務的程序員，不應該讓自己偏離嘗試開發市場上已有的東西（開源或商業）。
現在，您將嘗試創建一個缺陷跟蹤系統，以跟蹤用於跟蹤核心開發中錯誤的缺陷跟蹤系統。
第一： 1.選擇您的錯誤系統將在（Java，PHP，在Windows，Linux等） 2.嘗試尋找開源工具可用（開源運行平臺，我的意思是商業和免費工具）在您選擇的平臺上 3.花費最少的時間嘗試根據您的需求進行定製。如果可能的話，不要浪費時間進行定製
對於企業開發團隊，我們開始使用JIRA。我們想要一些額外的報告，SSO登錄等。JIRA有能力，我們可以使用已有的插件擴展它。由於代碼被賦予了付費支持的一部分，我們只花最少的時間編寫自定義登錄插件。
+1「用於創建一個缺陷跟蹤系統，跟蹤用於跟蹤核心開發中的錯誤的缺陷跟蹤系統。」 LOL – Dubs 2010-01-20 21:04:42
錯誤跟蹤系統可以是一個很好的項目，以啓動初級開發人員。這是一個相當簡單的系統，您可以使用它來根據您的編碼慣例等進行培訓。讓初級開發人員建立這樣一個系統相對便宜，他們可以在客戶看不到的東西上犯錯。
如果它是垃圾，你可以扔掉它，但你可以給他們一個感覺，如果它被使用的話，那些工作對公司來說已經很重要。對於初級開發人員來說，不能讓一個開發人員能夠體驗整個生命週期的成本，以及這樣的項目將帶來的所有知識轉移機會。
每個軟件開發人員都希望構建自己的bug跟蹤系統。這是因爲我們可以顯然改善已經存在的內容，因爲我們是域專家。
這幾乎肯定不值得花費（在開發人員時間方面）。只需購買JIRA。
如果您需要額外的錯誤跟蹤系統報告，您可以添加這些報告，即使您必須通過直接訪問底層數據庫來完成。
問題是你公司付錢給你做什麼？是否要編寫只有你會使用的軟件？很明顯不是。因此，建立錯誤跟蹤系統的時間和費用的唯一方法就是，它的成本低於使用免費錯誤跟蹤系統相關的成本。
有很好的情況下，這是有道理的。你需要與現有系統集成嗎？ （時間跟蹤，估算，需求，質量保證，自動化測試）？您的組織中是否有一些與SOX合規性相關的獨特要求，這些合規性要求特定的數據元素難以捕獲？
您是否處於一個非常好的環境中，導致項目之間出現重大「停機」？
如果對這些類型的問題的答案是肯定的 - 那麼無論如何，「購買」與構建爭論都會說構建。
我們已經在這裏完成了。我們寫了10多年前的第一本。然後，我們將其升級爲使用Web服務，更多的是作爲學習技術的一種方式。我們之所以這樣做的主要原因是我們需要一個缺陷跟蹤系統，該系統還生成了版本歷史報告以及我們在商業產品中找不到的其他一些功能。
我們現在正在研究bug跟蹤系統，並正在認真考慮遷移到Mantis並使用Mantis Connect來添加我們自己的其他自定義功能。滾動我們自己的系統的努力量太大了。
我想我們也應該看的FogBugz :-)
還有第三種選擇，既不買也不建。那裏有一堆好的免費的。 例如：
滾動你自己的bug跟蹤系統比學習其他任何用途沒有很好的利用時間。
其他鏈接：
免費是，但恕我直言，既不bugzilla也不trac是好 – 2008-10-07 20:11:44
建立在別人已經說過，而不只是下載一個免費/開源之一。如何下載它，然後完全根據自己的需要進行修改？我知道我過去一直被要求這樣做。我安裝了Bugzilla，然後對其進行了修改，以支持迴歸測試和測試報告（這是多年前的）。
除非您確信自己可以建造一個圓形車輪，否則不要重新發明車輪。
因爲Trac存在。
而且，由於您必須在定製軟件上培訓新員工，因爲他們可能在其他系統上有經驗，而您可以在其他系統上進行構建而不是丟棄。
因爲這不是收費時間，甚至非常有用，除非你打算出售它。
有完美的錯誤跟蹤系統可用，例如FogBugz。
值得注意的是，FogBugz是最初寫入內部，因爲他們不想買一個。不是說你錯了，而是有趣的是，我們試圖避免的事情是如何產生的。FogBugz – 2008-10-07 19:47:05
我同意這裏的大多數人。當有很多工具（甚至免費）可用時重建某些東西是沒有用的。 如果你想定製任何東西，大部分的免費工具都會給你代碼，並與之一起玩。
如果你做了新的開發，你不應該只爲自己做。
如果「需要一些高度專業化的報告，或者以某種被稱爲獨特的方式調整某些功能的能力」，那麼最好也是最便宜的方法就是與現有缺陷跟蹤系統的開發人員進行交流。支付他們把這個功能放到他們的應用程序中，讓它可用於全世界。不要重新發明車輪，只需支付車輪製造商放入形狀像彈簧的輻條即可。
否則，如果試圖展示一個框架，它的一切都很好。只要確保輸入相關免責聲明即可。
對於相信臭蟲追蹤系統的人不難構建，嚴格遵循瀑布SDLC。首先獲得所有要求。這肯定會幫助他們理解複雜性。這些人通常都是那些說搜索引擎不難構建的人。只需一個文本框，一個「搜索」按鈕和一個「我感覺幸運」的按鈕，並且「我感覺幸運」按鈕可以在階段2中完成。
大多數開發人員認爲他們有一些獨特的沒有其他人擁有的權力，因此他們可以創建一個獨特的系統。
99％是錯誤的。
貴公司擁有員工1％的機會是多少？
我在一家創業公司工作了幾年，我們從GNATS開始，這是一個開源工具，它基本上構建了我們自己的詳細錯誤跟蹤系統。我們的觀點是，我們會避免在商業系統上投入大量資金，並且我們會得到一個完全符合我們需求的錯誤跟蹤系統。
當然，結果比預期的要難得多，對於開發者來說是一個很大的分心 - 除了我們的代碼之外，他們還必須維護bug跟蹤系統。這是我們公司滅亡的原因之一。
使用一些開源軟件，原因是。 確定存在錯誤，並且您將需要什麼尚未存在或正在等待修復錯誤。它總是發生。 :)
如果您擴展/定製開源版本，那麼您必須對其進行維護。現在假設幫助您測試賺錢應用程序的應用程序將成爲支持的負擔。
爲什麼你需要維護對開源軟件的擴展？只要與上游開發者分享它，如果它真的有用，其他人就會發現一個癢癢的問題。 – 2008-10-23 03:07:56
首先，對有利於建立的論點自己：
在一些內部構建Web框架方面婉婷「吃我們自己的狗食」
這當然提高了問題爲什麼要構建自己的Web框架。就像有許多有價值的免費bug跟蹤器一樣，還有許多有價值的框架。我想知道你的開發人員是否優先考慮他們的優先級誰在做讓你公司真正賺錢的工作？好的，如果他們必須構建一個框架，讓它從構建您的企業用於賺錢的實際軟件的過程中有機地發展而來。
孤男寡女一些高度專業化的報告，或調整一些功能在一些據稱獨特的方式
正如其他人所說，抓住許多優秀的開源追蹤器之一，並調整它的能力。
認爲這是不難建立一個bug跟蹤系統
嗯，我寫我的BugTracker.NET在短短的幾個星期的第一個版本，從之前沒有C＃的知識。但是現在，6年以及幾千小時後，仍然有一大堆未完成的功能請求，所以這一切都取決於你想要一個錯誤跟蹤系統。多少電子郵件集成，源代碼控制集成，權限，工作流程，時間跟蹤，進度估算等。錯誤跟蹤器可以是主要的主要應用程序。
您可以使用哪些參數來支持購買現有的錯誤跟蹤系統？
不需要buy.Too許多優秀的開源的：Trac，Mantis_Bug_Tracker，我自己BugTracker.NET，僅舉幾例。
特別是，哪些功能很容易實現，但很難實現，或者很難且很重要，但卻經常被忽略？
如果你只是爲自己創建它，那麼你可以採取很多快捷方式，因爲你可以硬連線的東西。如果你正在爲許多不同的用戶構建它，在很多不同的場景中，那麼對可配置性的支持是很難的。可配置的工作流程，自定義字段和權限。
我認爲，一個良好的 bug跟蹤系統必須具備兩個特點，這兩個FogBugz和BugTracker.NET有，是1）傳入和傳出的電子郵件的整合，因此關於臭蟲整個對話與生活的bug而不是在一個單獨的電子郵件線程中，以及2）只需幾次點擊即可將屏幕截圖轉換爲bug帖子的實用程序。
假設明天（明年），如果他們決定爲公司的所有錯誤跟蹤系統引入一個流行的開源/商業工具，該工具將如何將其所有錯誤導出導出到其他工具？
只要真正需要定製錯誤跟蹤系統，並且回答了這些問題，我就不會打擾太多。
那裏已經有很多好東西了，爲什麼浪費時間重新發明輪子呢？
只需使用FogBugz。
我一直在這個辯論的雙方，所以讓我在這裏面對一點點兩個。
當我年輕時，我推動建立我們自己的錯誤跟蹤系統。我只強調了現成的東西無法做到的所有事情，並且我得到了管理層的幫助。他們選擇誰來領導團隊？我！這將是我第一次成爲團隊負責人，並且在設計，工具和人員等各方面都有發言權。我很激動。所以我的建議是檢查推動這個項目的人的動機。
既然我年紀大了，又面臨同樣的問題，我只是決定和FogBugz一起去。它佔我們需要的99％，成本基本上是0.另外，喬爾會給你發送個人電子郵件，讓你感覺特別。最後，這不是問題，你的開發人員認爲這會使它們變得特別嗎？
不要編寫自己的軟件，以便您可以「吃自己的狗糧」。你只是在創造更多的工作，當你可能購買軟件，花費更少的時間和金錢來做同樣的事情（更好）。
我認爲人們之所以寫自己的bug跟蹤系統（在我的經驗）是，
對我來說，爲什麼大多數bug跟蹤失敗的是，他們並沒有提供最佳的用戶體驗，它可以是非常痛苦的一個系統工作的最大原因，你如果沒有針對可用性進行優化，請使用LOT。
我認爲其他原因與爲什麼幾乎我們每個人（程序員）都在某個時候（有罪感）一起構建了自己的自定義CMS或CMS框架的原因相同。只因爲你可以！
我不認爲構建內部跟蹤系統相對容易構建，當然它不會與付費或開源解決方案相匹配。大多數時候我會選擇「程序員自我」，或者只是讓IT部門真正無法使用第三方軟件，並且必須逐字地構建所使用的每一個軟件。
一旦我曾在一家電信公司，有自己的自己內部的版本控制系統，這是非常糟糕的，但它保持了整個團隊忙碌......
我同意所有的原因不要。我們嘗試了一段時間來使用那裏的東西，並且無論如何都寫了我們自己的東西。爲什麼？主要是因爲他們中的大多數人太麻煩，除了技術人員之外，沒有人蔘與其中。我們甚至嘗試了basecamp（當然，這不是爲此設計的，在這方面失敗了）。
我們還想出了一些與我們的客戶合作的獨特功能：「報告錯誤」按鈕，我們用一行javascript腳本編寫代碼。它允許我們的客戶打開一個小窗口，快速記下信息並提交給數據庫。
但是，它肯定需要很多小時才能編碼;成爲一個BIG寵物項目;很多週末時間。
如果你想看看：http://www.archerfishonline.com
很想一些反饋。
我們已經完成了這個...幾次。我們建立自己的唯一原因是因爲它是五年前，並沒有很多好的選擇。但現在有很多替代品。我們在構建自己的工具時學到的主要內容是，您將花費大量時間來處理它。那是時候你可以爲你的時間計費了。作爲一個小企業，作爲一個小企業來說，更有意義的是支付你可以輕鬆收回一個或兩個計費小時的月費，而不是花費所有時間來滾動你自己的費用。當然，你必須做出一些讓步，但從長遠來看，你會好得多。
至於我們，我們決定讓我們的應用程序可供其他開發人員使用。瞧瞧吧http://www.myintervals.com
告訴他們，這是偉大的，公司可以做節省一些錢了一會兒，會很高興，而你在這個無薪休假的工作做出貢獻的開發工具。任何想要休年假的人都可以免費參加這個項目。
我已經構建了自己的錯誤跟蹤系統。我也想：「它有多難，這只是一個錯誤跟蹤系統」錯誤 - 錯誤* - 它花了六個月的時間來編碼。
我烘烤自己的主要原因是爲了得到它正是我想要的。另一個原因是作爲一個業餘愛好項目。
我想說的是，如果它是一個業餘愛好項目，那麼建立自己的唯一理由就是合理。沒有公司應該花時間去做。
順便說一句，我的軟件叫Bugweb。
不敢相信Redmine有這麼多行代碼..我認爲它是Ruby。 – kizzx2 2010-11-10 16:45:44