然後，當我進入源代碼來了解問題出在哪裡時，我通常會發現他是誰寫的那段特定的代碼（由於git commit歷史記錄），但由於它不是立即的，我不能為自己辯護。

這裡有兩種方法。如果該策略是“由誰來解決此問題，請修復此問題”，那麼您只需後退：

我已經研究了此問題，但似乎在 x 這不是我編寫的代碼。 Alex，我相信您是這裡的原始作者-您可以看看嗎？

每次都這樣做。如果它經常發生，那麼亞歷克斯便開始因自己的錯誤而責備他人而獲得聲譽。

或者，如果這是一個反復出現的問題（聽起來像是這樣），您會因此感到自己受到負面評價，因此您無需立即做出反應。您需要在每次發生這種情況時記錄下來，然後將其記錄給您的經理： 。我們都是人，我當然不是在聲稱要編寫完美的代碼，但是在過去（幾週）中，我將問題a，b，c和d強調為我的責任，儘管它們是由我的代碼引起的從來沒有動過。這似乎是一個持續的問題。你能說一個字嗎？

這裡有太多的功能失調的行為，如果公司的其他成員不知道開發公司應該如何工作，將很難修復它們。

1. 您的同事不應該怪你。據我了解，他不是您的上司，因此不應允許他這樣做，您的上司應勸阻這種行為。

2. 您的項目負責人對誰不感興趣實際編碼的錯誤。他可以向團隊報告發現的錯誤，然後管理如何解決它們。但是他不應該聽您的同事指責您，甚至不喜歡它。隊友互相指責是公司健康狀況不佳的跡象，應該對此予以皺眉。那是誰做的錯誤。而不浪費時間去找誰。

大聲說出來！

你的同事讓你看起來不好的唯一原因是因為你允許他這樣做。他在您的經理面前提出要求，而不是挑戰他的要求，您只是無所事事。這需要停止。下次他在您的經理面前將您的錯誤歸咎於您時，您需要講類似這樣的錯誤：

您確定這是我的錯嗎？我不記得在項目的那部分工作了。讓我們來看一下git的歷史記錄，以確保確定。

然後，您應該確保都進行查找（最好是在您的經理在場的情況下）以確認或拒絕他的主張。如果經理不能在場，則需要跟進經理並提出調查結果，並複制同事。同事需要了解，您將不再允許他不經調查就指責您的bug。

我通常發現他寫了這段特定的代碼（感謝git commit歷史記錄），但是由於它不是中間語言，所以我無法用一個詞來捍衛自己

：您選擇的 Source Control 系統（git / tfs）

俗話說的不好聽。如果您因未做的更改而受到指責，那麼您應該可以說“ 好吧，讓我們看看歷史”，並清楚地證明是誰對更改做出了哪些更改導致該錯誤的代碼。坐在您的經理那裡，顯示歷史記錄並清楚地解釋這是問題的原因，並且這應該是討論的結尾。

作為開發人員，我們的文檔最多部分是源代碼控制。如果在這種情況下我們不能依靠它，我不確定您能做什麼。我會說，儘管根據我多年的經驗，使用源代碼作為我的辯護，我是對的，它總是可行的。

這種方法還可以使您應對沒有與任何人對抗的問題。您甚至不必說出名稱，就可以說我明確表明的變更集導致了此問題。

如果您不能使用源代碼控制系統來保護自己在這種情況下，我不確定該怎麼辦。

在幾乎任何情況下，無論開發人員與否，某種類型的文檔 ​​strong>都是您的朋友。

整rick。這裡的關鍵角色是項目負責人及其對您的印象。

如果項目負責人善於閱讀人和事，那麼他們會注意到，您會為每個錯誤負責，這不太可能真正。另一方面，如果他們不善於閱讀情況，那麼您可能無能為力。在這兩種情況下，如果您就此問題大聲疾呼，他們都會對您不利。

最好的選擇是讓他們盡可能地溫和地意識到。當您與他們一對一交談時選擇一個低壓力的時刻，並提出問題（例如在績效評估期間）。我會說些類似的話：

““您是否注意到X會在漏洞升級時傾向於怪我？我只是想確保您知道它不是？通常，在修復錯誤時，我通常會發現我寫代碼的時間大約是Y％。我不認為這是個大問題，但想確保您不會出錯對我的工作有印象。”

避免按此問題。只要您的主管知道，您就希望盡可能少地關注它。

準備好幾個示例可能是值得的，但是除非您的項目負責，否則我不會引起注意要求例子。

一個選擇是在下次他怪您時提出最近的幾件事。像這樣說：“您確定這是我的代碼嗎？最近幾次您說的，原來是您的錯誤。也許我們應該在指責之前獲得修訂歷史。”

過去曾被錯誤地責備您，並且您認為他在下次再次責備您之前應該進行檢查。

問項目負責人

問題是您發現您的同事將您的錯誤歸咎於您。您的項目負責人就是聽到的人。您如何讓項目負責人知道這一點？安排一次私人會議並詢問該怎麼辦。您想知道

1. 這件事嗎？是誰以某種方式跟踪了導致特定錯誤的原因？
2. 當初始報告與實際情況不同時，您是否要報告？
3. 您一般應該如何處理？
ol>

您應該至少拿三個示例，這些示例本來是您報告的錯誤，但實際上是您同事的錯誤。這些應該是清楚的例子。如果可以說是您的錯誤，則不應包含它。

通過詢問而不是報告，您可以消除一些麻煩。您不會給項目負責人更多的工作。您只是在尋求有關操作的指導。

您的項目負責人比您更了解您公司的文化和程序。您可能什麼都不擔心。否則這可能很重要。我們不知道，因為我們不知道您的公司。只有公司裡的人可以告訴您，最自然的人是您的項目負責人。

另一個問題是您不知道為什麼您的同事將這些錯誤歸咎於您。不安全嗎？不喜歡處理錯誤？還有嗎下次發生這種情況時，您發現自己和同事在一起時，可以告訴同事您找到了該錯誤，並且該錯誤已在您同事的代碼中。出於興趣，請隨便說一下。例如，“嘿，您知道您說的是我造成的錯誤，原來是在您的代碼中。您是否只想讓我修復它？”響應可能很有啟發性。但是歸根結底，管理更高級的同事不是您的工作。這就是為什麼您有一個項目負責人，擔心這種事情的原因。

如果您的項目負責人對您的問題持否定態度，您可以隨時開始尋找其他工作。但是您的項目負責人應該給您有關如何處理此工作的反饋。如果項目負責人告訴您只是忽略它，則忽略它。如果您的項目負責人要求您將其記錄下來，則將其記錄下來。如果您的項目負責人告訴您與人力資源部門對話，請與人力資源部門對話。這就是為什麼您有一個項目負責人，以便在不確定該怎麼做時為您提供指導。

這裡有2個問題：

1. 您有一個有毒的同事。這些是破壞團隊的人。如果您將來發現自己和這種人一起加入團隊，請更換團隊或公司。但是真正的問題是：

2. 您有一個笨拙的經理/項目負責人。主管Pointy Haird Boss（PHB）應該注意，Toxic Tom甚至在任何人都沒有機會查看代碼之前，就一直在指責和指責。他們應該對自己進行思考：“ Toxic Tom不可能分析迅速找到該錯誤的代碼...我只是告訴他們！”

ol>

這實際上是一個更大的問題，並且是盡快離開那裡的一個很好的理由。老闆會成敗你的事業。一個好的老闆會認識到您的有效工作，並利用它來推動你們倆。糟糕的老闆會無視你的血液，辛勞，眼淚和汗水，讓你在低谷的同齡人中流連忘返。

如果你有更多的信心和經驗，可以指導這三個人去做。成為更好的員工。但是，他們在該公司一起工作的事實告訴您您需要了解的所有信息。您在一家低質量的公司工作。幾乎所有會僱用您的人都不會變差，很有可能他們至少會變得更好。不斷跳來跳去，直到找到一個可以工作的好老闆。其他任何事情都會浪費您的生命。

tl; dr：如果這些人真的有改變的能力，他們早就應該離開了。這是一個避免閃避的警告信號。

跟進，因為這對我來說很近，我覺得當前的答案並不涵蓋軟件開發的最重要方面。

這也許不是您喜歡的答案，但是根據我的專業經驗，這將有很長的路要走。

代碼審查不僅是出於代碼質量的考慮，也是共同的責任，如果您在合併之前檢查彼此的代碼然後，您就應該共同負責這些錯誤。帆船中也採用了相同的策略，一個人操縱所有東西，另一人檢查它。這樣一來，如果發生任何錯誤，那麼兩個人都只能責備自己，因為如果錯誤地操縱了該錯誤，則負責審閱該錯誤的人現在應該負責。

任何團隊中部署的對bug負個人責任的任何策略都將不利於團隊文化和團隊內部信任都是發生在這裡的事情。

如何在“責備”會議期間為自己辯護

在這些會議上為自己辯護！通過指出直到您和您的同事坐下來並仔細跟踪錯誤的根源，來重定向怪罪的過程（這是有毒的），無法確定是什麼原因造成的（眾所周知，對錯誤原因的第一次猜測幾乎總是錯誤的）。確保立即與您的同事並在那裡安排後續的故障排除會議-某些影響（讓您稱呼您的同事“約翰”）為：

“約翰，讓我們一起解決問題；今天下午為您服務嗎？”

這縮短了責備過程，從而使沒有人受到責備，這使您和約翰看起來都更好。您顯示出專業的成熟度，並且他表明他是團隊合作者，並且願意停止下結論。

為什麼採用這種方法？

1. 它可以防止您採取不必要的措施。
2. 表明您是一個了解良好軟件流程的團隊合作者。
3. 它使團隊重新集中精力，避免責怪他人（這是有毒的）要找到並修復錯誤。
ol>

如果您的同事一直在與您爭論或說謊，請重複一遍，即您需要坐下來仔細閱讀代碼以確保並確保推送進行故障排除會議。如果失敗，請與您的老闆私下坐下。

請勿在“責備”會議中將您的同事扔在公共汽車下。 如果您需要與同事一起解決同事的有害行為，請私下。

這種方法的外觀如下：

您的同事：

Alex寫下了該錯誤！

您：

稍等片刻。我們需要坐下來仔細閱讀代碼，仔細跟踪錯誤的發生位置和原因，然後才能確定錯誤的發生位置。我們尚不知道這些細節。

您的同事：

是的。該錯誤與組件Foo有關。它不再起作用。您上次使用Foo還是寫了Foo，所以寫了bug。

您：

這不是那麼簡單。組件是相互關聯的，雖然問題是在Foo中顯示，但這並不一定意味著 bug在Foo中。它很可能在 Bar 中。我們已經發現過去有很多次這種情況（對錯誤的第一次猜測通常幾乎總是錯誤的），這就是為什麼我們必須對這些錯誤和其他錯誤進行認真的排查很重要，以便我們明智地度過自己的時間。讓我們一起經歷一下，找出錯誤所在。您今天下午有空嗎？

您的同事： （喃喃自語）

當然。 / p>

您應該與同事面對面，並與經理討論此問題。

向同事詢問30分鐘讓他/她知道您有一些反饋意見，可以分享他們在一起工作的方式，並歡迎他們為您提供任何反饋意見。

對話中，直接與您的同事分享您的看法並解釋您的感受。如果您有具體的示例，請包括2-3個（但並不會列出每種情況，

與您的同事討論後，請您的經理大約1個小時，以非正式的方式討論您在工作中的感覺以及

在對話中，再次明確和直接地介紹您的經歷-無需輕描淡寫怎麼了。誠實，透明。

讓您的經理複習一些示例，並就如何更好地與同事合作向您提供建議。您的經理應自行決定

最後，您的同事可能會感到尷尬，並且可能不滿意您離開他/她。但是，您描述的行為是不可接受的。鑑於這種行為持續存在-您應進行干預並邀請您的經理進行干預。

您的組織中的質量檢查流程如何？是否指派人來確保項目交付給客戶之前沒有錯誤。你們兩個開發人員是否分配了時間來執行基本測試和錯誤修復？

此外，團隊是否維護列出項目規範的適當文檔以及由誰負責哪個模塊？

自從您提到這是一家小公司，很可能該公司可能沒有資源或時間專門用於質量保證/測試團隊。另外，您可能沒有正確記錄開發人員之間的規格和模塊劃分。

您可以通過建議項目負責人讓您分配一些時間進行質量檢查和錯誤修復來解決這種情況。這樣可以確保交付給客戶的交付不存在簡單的問題。

為防止遭受錯誤的指責，請首先準備一份列出項目規格的文檔。嘗試將兩個開發人員之間的各個模塊隔離開，以便你們兩個都可以獨立工作。在與項目負責人和其他開發人員達成協議的同時進行此操作。主動自己動手起草本文檔的第一版（即使您需要花一些時間來做）。準備好初始版本將使您的同事更願意討論。

一旦您將各個模塊隔離開來，並且項目負責人也同意，您將不會因為同事的工作而受到指責。

將適當的源代碼控制實踐集成到您的工作流程中。使用它，你們兩個都可以選擇處理項目的獨立副本（分支），僅在測試每個作品之後才合併。一開始可能需要一定的學習曲線，但是值得付出努力。 Git是業界首選的版本控制，並具有強大的功能來支持多開發人員團隊。

承擔此拖累工作的責任。一開始可能需要做很多工作，但是好處是多方面的。

1. 所提供軟件的輸出質量將得到改善。

2. 這將代表該公司對客戶很好。

3. 團隊將從整體上提高技能，並有信心處理更複雜的工作。

4. 您將成長為獲得更多技能和信心的專業人士。

5. 好的輸出和更少的衝突會導致一個積極而富有成效的整體環境。

ol>

---

我假設沒有人在團隊中試圖不公正地責怪其他人。只是沒有一個像樣的流程，團隊成員可以用他們現在可以想到的任何理由消除工作中的任何問題。

作為對這個問題的輔助回答-我同意“為你自己說話”的一般建議，但是您應該小心確保問題確實存在於您同事的代碼中。

您有大量的工作時間，而我的經驗（無論是我自己還是與我一起工作的初級開發人員）都存在一種趨勢，即無法將缺陷追溯到問題的最終根源，而是解決問題的根源。問題，而不是根本原因。

您真的想避免在這裡來回指責，因此請確保您找到了最終問題所在。