除非您已毫無疑問地證明該錯誤在編譯器工具鏈中，否則您應該假設這是您的錯誤。

• 如果是工具鏈中的錯誤，則需要報告它，在線尋求幫助和解決方法，並找到解決方法。解決它。分析這種情況，並提供一個可能的解決方案列表，這些解決方案比您的用戶現在所體驗的要好。也許您可以擁有一個沒有並發的版本。這可能比隨機崩潰更好。向主管報告所有這些選項，並報告您尚不知道原始問題何時得到解決。

• 可能是，您無法證明這是您工具中的錯誤鏈。所以你還在找。告訴主管，您仍在調試。詢問他是否有最後期限，最好放棄您正在做的事情並改用其他計劃。列出上述所有選項。

通常來說，您的報告越高，人們對細節的興趣就越小。您的工具是您的工具。您負責選擇可以完成工作的工具。您的工具故障將被視為您的故障。這似乎是不公平的，但是請嘗試從另一個角度看待它：假設您僱用了一個工匠，他告訴您他將在星期五完成維修工作。星期五到了，他告訴你他無法完成工作，因為他的一種工具壞了。您是否會以為藉口？他的工具是他的職責，對不對？

只要您的報告交給技術人員，請提及工具存在的問題並提出替代解決方案。如果價格上漲，不要責怪工具。那隻會被視為藉口。只需提出替代解決方案即可。

您已經嘗試過書中的所有解決方案（調試器，Google，論壇等），但仍然無法解決它。

沒有沒錯您尚未與任何高級團隊成員交談。您沒有從團隊領導那裡獲得任何幫助。您尚未考慮過以下事實：如果您無法重現該錯誤，則有更多經驗的人可以重現該錯誤並幫助您調試它。

所以

軟件開發人員：您如何告訴老闆/客戶軟件錯誤是您無法完成項目的一部分的原因？

只是不這樣做。那不是真正的藉口。如果是軟件錯誤所致，請與您的雇主討論那個。您不能告訴他們我無法快速上傳1 GB的文件，因為辦公室撥號速度很慢。相反，您應該告訴他們讓您完成工作所需的連接速度，然後執行此操作。完成工作：）

如果一個團隊成員來找我並告訴我，這個錯誤我似乎無法解決，並且很難復制，我將不願幫助他們，或者至少給他們時間。另一方面，如果他們來找我，不，那不能解決，因為此工具使它弄亂了，我真的認為這是la腳的藉口。

如果我們無法獨自解決所有問題，但是如果我們不尋求團隊或高層的幫助，而只是輕描淡寫的話，那也不好。致力於解決問題比完善更重要。很多時候，我們認為無可辯駁的事情對其他人來說是小菜一碟。

您告訴老闆，

我正在嘗試解決問題，但我不能，請嘗試。我已經嘗試過我能想到的所有方法（調試器，Google，論壇等），但仍然無法解決它。也許該錯誤在每次運行時都會隨機消失，並且不可能與我使用並發技術相關。因此，我得出的結論是，該錯誤僅在我無法複製或隔離的某些運行時條件下才會顯現。

這就是說：告訴老闆真相。就我個人而言，我認為任何人都應該花一天多的時間來做某件事，而不要與團隊中的其他人（老闆或同事）交談，並給予他們提供有用的見解或建議的機會。理想情況下，時間要比這少得多，而且我認為有些人會設置一個較小的硬限制（實際上，成對編程的一個原則是，您應該永遠花費零時間自己呆在某個東西上）。

其中，“沒有可能與我對並發技術的使用有關的錯誤”是一個大膽的主張，老闆（或指派更高級的技術來解決您無法處理的問題）可能是其中的要求充分的證據。因此，值得預先組裝此證明，因為由於幾項不同的調查，您很可能已得出結論。您不希望它出現在“我有預感，這不是並發性”或“我已經拒絕了使用並發性的可能性，因為我非常出色，我從未犯過錯誤”。除了這種說法的大膽之處，我認為您所說的內容與眾不同或值得引起關注。

然後，您的老闆將負責從能夠更好地理解或解決問題的人員那里分配更多時間。正如其他人所說，額外的人甚至不一定需要比你更好，只要換個新面孔即可。您的老闆或團隊可能還決定，由於問題是斷斷續續的，因此需要在更廣泛的環境和數據上進行更精確的日誌記錄（或其他檢測），以期發現錯誤發生的次數比實際情況多。能夠獨自開發環境。最壞的情況是，如果錯誤不在您公司的代碼中而是在某種程度上依賴於您，則需要證明這一點，並且需要讓第三方盡可能多地重現該錯誤，以便他們可以對其進行修復。並提供更新。

如果您沒有老闆，那麼客戶會有所不同。您嘗試過的細節對他們沒有用。如果您是個體經營的客戶合同承辦商，沒有老闆，又無法完成您承包的項目，那麼在大多數情況下，您不能僅僅要求他們幫助您解決問題。您需要告訴他們有延遲。但是您將不得不自己解決或解決該問題，或者找到其他可以解決的人。

非常簡單-告訴他們：

這是一個隨機錯誤，確實很難重現，我花了x倍的時間。現在，

• 您是否要我花更多時間嘗試重現它，這可能需要x的時間，或者您根本不知道需要多長時間？ ？

• 研究更重要的內容，並在以後再使用（以防出現更多信息）。

保持誠實，不要過分推;；這不是你的錯。我曾經和您有相同的感受，但現在我保持簡單。可能發生的最壞情況是，他們會解僱您，也許您會找到更好的工作...保持積極。

要成為一個快樂的開發人員，您必須無所畏懼。

第一個規則：如果存在錯誤，那是因為您做錯了什麼。問題是：您在做什麼錯？如果您使自己確信問題出在其他地方，則不會發現問題。

第二條規則：向另一個軟件開發人員解釋該問題。您會驚訝地發現，不得不解釋問題的簡單事實多久會引起您的注意，並且您自己找到解決方案。在有經驗的開發人員中，通常是開始解釋問題，然後在中途停止開發，因為他們找到了解決方案。

第三條規則：向另一個軟件開發人員解釋該問題。如果您有一個_{不想發現自己的錯誤的潛意識限制，因為這意味著承認您犯了一個錯誤，另一個開發人員就沒有這個問題，並且通常可以輕鬆地找到問題你錯過了。 （這並不意味著您很愚蠢-它可以雙向運行）。}

第四條規則：如果周圍沒有其他顯影劑，請使用紙板編程器。只是一個人的硬紙板切口，您就可以向那個硬紙板程序員解釋問題。您會看到，在第二種情況下，其他開發人員實際上並沒有採取任何措施來幫助您，他們只需要在那兒。因此，您最好向紙板程序員解釋該問題。

該錯誤僅在某些運行時條件下才會顯現，到目前為止，您仍無法複製或隔離該錯誤。

..到目前為止。

升級並尋求幫助。最終，所有錯誤都可以通過“當我本應擁有Y時擁有X。X來自何處？”的鏈來追溯。特別是如果它仍在發生。一次過的怪異事件可能不會留下足夠的證據，但是，如果正在發生錯誤，那麼您只需要捕獲周圍的更多數據即可告訴您發生了什麼情況。代碼生成；特定C ++上的GCC coredump； ARM上的MSVC2008結構化異常處理）。它們非常罕見，在每種情況下我都找到一個測試用例，證明該工具存在問題，而不僅僅是聲稱它必須存在，因為我無法在代碼中找到錯誤

那些是最難的錯誤。當您最終實現該錯誤時，通常比修復它困難。有時，您認為是環境的實際上只是一系列尚未確定的事件。開發人員將測試他們期望該程序的使用方式，並且用戶將執行您從未想到的工作。有時，只有在生產負載時才會出現錯誤。

我不知道您的環境，但是您有一個全局異常處理程序來報告錯誤詳細信息和調用堆棧嗎？那就是我們所做的。讓用戶看到難看的錯誤，以便他們可以告訴您。 “很抱歉您遇到了錯誤。請向技術支持報告以下內容，以便我們解決問題。”如果應用程序已連接到數據庫，則將錯誤寫入數據庫。您是否預先編寫了用於處理和報告錯誤/異常的軟件？

我現在有一個序列化錯誤，該錯誤僅在400次運行中發生1次（並且我沒有得到調用堆棧）。我很確定這是框架而不是我的程序，但是我無法證明它，但這仍然是我的問題。幸運的是，只需重啟程序即可。這是我們要修復的已知錯誤，但決定隨該錯誤一起發布。

老闆和客戶不同。

老闆：描述錯誤及其影響。僅影響某些功能還是整個程序受到影響。目前，我無法重現該錯誤。在無法重現該錯誤之前，我無法修復它。在這一點上，我懷疑該錯誤是環境方面的。到目前為止你做了什麼。您打算做什麼。你需要幫助嗎。除非您能證明，否則不要告訴老闆您確定該錯誤與您使用並發技術無關。

客戶：
目前，我們（向客戶說我們如此）感覺像一個團隊正在努力）有一個已知的錯誤。影響為X。這是一個優先級錯誤，我們正在積極進行處理，但目前尚無定案日期。

除非您需要他們的幫助才能複制，否則請勿與客戶進行複制。

如果是報告此錯誤的客戶端，則可以進行更詳細的介紹。

我已經處理了幾次。大多數情況下，它是您的錯誤，您可以並且應該予以解決。
即使不是，多數時候您也可以並且應該能夠通過重寫一小部分代碼來解決該問題。
在極少數情況下似乎不可能的事情，團隊中的其他人也許可以做到（特別是如果您是團隊中較低級的成員之一）。

極少見的情況：1）問題不是由您的代碼錯誤引起的； 2）您可以提供可驗證的證據，證明這種情況； 3）您無法重寫代碼來解決此問題，那麼現在該通知您了您的管理人員認為，如果不切換工具集，庫，發生任何故障，就無法完成他們想要的事情，這將是一項重大投資，也許最好放棄暴露問題的要求，直到找到另一個解決方案為止。 br />
但是在這個行業的20年中，以及作為學生和業餘愛好者的幾年之前，我只遇到過三思而後行。 br />這並不是說我從未遇到過編譯器，庫或工具中的錯誤。但是幾十年來，我只遇到過一次或兩次遇到的錯誤，那就是如果沒有比更換另一套工具的成本更高的投資，我們就無法解決該錯誤。

承認您很沮喪，請其他人也看一下（並儘早這樣做），並向這些人提供您已經做過的文檔和研究，這樣他們就不必一遍又一遍了。
這是您作為團隊成員的責任。

錯誤是一個障礙。聽起來不像是“它就是這樣”，所以需要解決該bug。

如果您看不到自己在該bug上取得了進步，而又不能想到其他事情，您需要找出下一個選項來控制該錯誤。這可能意味著外部專業知識，但更可能是內部專業知識。

作為“高級軟件開發人員”，我半定期（即大約一年一次）必須找出一個真正的錯誤漏洞，最終裁決歸結為“代碼生成錯誤”。然後，需要將錯誤隔離為一個合理的獨立示例，並與編譯器作者聯繫。取決於您的編譯器，這可能需要一些非廉價的支持程序成員，才能被允許報告您所購買的軟件的錯誤（當然，您也可以在酒吧聊天開發人員，並為她拖一個USB驅動器因為她的管理層沒有註意：開發人員很少看到不了解bug的意義。）

如果您用光了工具和/或智慧，要么需要獲得新的工具或智慧，要么您需要專注於變通辦法，以確保無論出於何種原因都不會出現該錯誤。

作為一名員工，您有責任在負責任的公司上花費公司資源，包括但不限於自己的工作時間合理地期望返回值的方式。

該錯誤僅在您無法複製或隔離的某些運行時條件下才會出現。

通常，系統會以系統的方式運行。 系統在我們看來都是隨機。是的，如果我們無法修復/重現該錯誤，那將真的很痛苦。通常，並非所有的錯誤都需要代碼修復。即使只是簡單的配置更改也可以修復該錯誤。

因此，我們不能以隨機的方式處理隨機可複制的錯誤。我們必須遵循系統的方法來修復該隨機錯誤。 / em>

記下重現/修復該bug所遵循的所有方案/方法是什麼。請問一下自己還有什麼錯過或尚未嘗試的東西，也可以嘗試一下。如果一切失敗，請向您的同行/前輩尋求幫助。

您告訴要舉報對象的人是什麼？

顯示您的努力。

作為軟件開發人員，您不能簡單地說我無法修復此錯誤。

由於您已經系統地處理了此錯誤，因此可以向老闆展示您的努力。

如果您涵蓋了10種可能的方法中的9種，那麼其他人可能會建議您嘗試第10種方法。 （如果您以系統的方式處理並記錄了所有情況。）

因此，您節省了時間，也節省了其他人尋找此錯誤以修復該錯誤的時間，或者至少它將有助於立即找出問題的根本原因。

• 如果它與IDE有關，那麼它就不會成為無法修復的錯誤。或找到替代方法
• ，如果它與編程語言相關，則與上述相同，或者您可以告訴您的主管，他會理解，因為他知道該語言及其局限性。例如JS是JS，在使用它之前，您必須先了解其缺陷。他們願意提供幫助，即使不嘗試進行分叉，尋找分叉或其他選擇。如果它是封閉源，則找到替代方法。一般而言，所有庫都可以替換，除了極少數庫（例如僅由製造商維護的硬件庫）。
• 如果是要使用的軟件，請切換該軟件，例如JDBC驅動程序發佈在GPL，我們需要GNU許可證並且找不到其他驅動程序，我們開始切換到Postgeres，即使要花數十年的時間，也沒有任何藉口，如果有其他軟件必須使用它並報告原因
• 如果該錯誤與某些第三方API限制有關，那麼您無能為力，請您在stackoverflow上尋求幫助，如果它們不能幫助您，請告訴您的客戶。一位客戶曾經要求我從公共Instagram標籤中獲取圖像，我在SO上要求。一旦確定instagram不允許，我就給他發了一封電子郵件，並給他鏈接了我的問題，並附帶了instagram網站上的屏幕截圖，無法採取任何措施，只能向客戶證明。
• 如果它與錯誤有關，那麼我沒有提到它是如此重要且難以修復，並且沒有大學學院可以為您提供幫助，然後詢問，那麼您將獲得如此多的支持，並且stackoverflow無法解決它，您可以使用問題來支持您聲稱此錯誤無法解決的說法。