讓我們從後退大約兩個步驟開始：

如果您的團隊陷入僵局，以至於只有一個人可以按照您描述的方式前進，那麼您的團隊就運作不正常。一個人不可能比一群才華橫溢的專業人士那麼“出色”。那裡有嚴重的錯誤。您或者在組織上存在限制他們技能的問題，或者您沒有自己認為的才能。這是您必鬚麵對的主要問題。

但是也存在著如何管理此人的才能的問題。為了爭辯，我同意他在某種程度上比您團隊中的其他任何人都更加熟練和有見地。如果是這樣，那麼您就需要選擇團隊中最有情感的人，並指派他們“隔離”這個人。

首先，最重要的是，不要再稱他為“雨人”-如果您引用了達斯汀·霍夫曼的電影，那麼這種引用帶來了很多麻煩，無論是正面還是負面的。它在您的心中和您的員工的心中“潛入洞”。此人可能有精神健康問題。那並不意味著你就不能小看他。您不會看不起截肢者或癱瘓者，所以要給這個人同樣的尊重。如果您想尊重人才，那麼也要尊重這個人。

第二，找到一種整合他的方法。讓他變得聰明，但是當需要進行代碼審查時，請提供“絕緣子”註釋並根據需要進行重命名，並向才華橫溢的員工清楚地解釋：“您的工作非常出色。我們要做的只是一些手工操作為了將其集成到我們的流程中，以便我們的初級開發人員可以使用。在這裡，史蒂夫（Steve）將幫助實現這一目標，並將'雜物'擋在腳下。”在您不知不覺中，史蒂夫將比其他任何人都了解更多，並希望提高您整個團隊的技能水平。

最後-在這一切進行之後，仔細評估一下您的“老”團隊。那裡不對勁。即使是一個才華橫溢的程序員，也沒有太多的“房間”可以使您的團隊發生如此巨大的變化。

您是否嘗試過問他如何使代碼審查對他更容忍？使用上面列出的示例，如果他們更像這樣呢？

• 僱員A-這個變量X，我想如果是TotalSalesThisWeek，對於每個人來說可能會更清楚。可以重命名嗎？

• 員工B-[提出問題，直到他們理解代碼並掌握丟失的信息為止]。對我來說，可以添加評論總結一下，供下一個閱讀它的人嗎？

• 員工A-我用X標記了您的簽到位置，以便我們知道它在哪裡屬於。如果您記得對其進行標記，那麼簽入後將看不到編輯內容。

我看到的這些模式是，你們都在問他寧願開放式”在以某種方式批評他的工作後解決此類問題。雖然我不認識會為此而哭泣的人，但我確實知道會被激怒的人。例如，告訴我我的代碼令人困惑，這會讓我感到尷尬，並要求我提供評論以解釋它實際上可能是可笑的-如果解釋很長，不作為註釋，是嗎？

通常，我堅持認為以不符合小組標準的方式進行工作的人應該是解決問題的人。但是在這種情況下，我認為讓其他人提出/要求進行更改將更加實用。隨著時間的流逝，他可能會選擇調整自己的工作來阻止此類請求，或者可能不會。

但是，這可能是當前的安排實際上對每個人都有效。他有些沮喪，有時會回家，但是如果他重命名變量，添加註釋並在第二天回來時簽入簽入標籤，那麼您的代碼基礎就很乾淨，團隊的其他人也接受了聳聳肩，你沒有什麼要修復的。如果您的代碼庫不是很乾淨，我建議讓代碼審閱者提供一種很好的解決方法，看看這是否完全可以減輕情緒壓力。

用戶墊子的杯子在評論中碰到了一個關鍵的想法：

[...]要不具個性（算上“您員工A & B的評論中的“和”是“您的”）[...]

這是您的電話，它是否值得付出努力，但如果此人是看起來確實有價值，那麼我認為這將是非常值得的&，它將使每個人的經歷都更加愉快。您甚至可以通過這種方式從此人那裡獲得更多的生產時間。

示例

之前：為什麼將這個變量命名為“ that”？

之後：為什麼將這個變量命名為“ that”？

之前：您可以在註釋中詳細說明發生了什麼嗎？

之後：我們將從註釋中詳細說明發生的事情。

我已經看到（作為此答案）提到的團隊動態，他的回答，您的回答以及提到的“ You”和“ Rainman”的其他動態...

我還沒有發現看到提到過：公司編碼標準

這些問題/答案在哪裡屬於編碼標準範圍？命名約定，註釋代碼，標記...聽起來都應該被編入標準中。

如果沒有標準，則歸結為“他說，她說”和個人喜好。 “應該有這個名字...應該有一個註釋...應該用這樣的標籤”-所有基於當前運行它的人的個人喜好。程序員，我敢打賭他堅持最佳實踐，最新方法等。“乾淨編碼”的一部分涉及使所有內容可讀，可理解，自我描述等。

您將獲得整個團隊/公司應遵循的標準。無論是包含製表符還是空格，SemVer還是其他內容... 20種控制大寫字母約定的方法。

我認為創建一套標准或採用一套標準對於您的堆棧，例如 C＃編碼標準-可以緩解大多數“我認為您應該...”的問題，並將其移至“這不符合我們記錄的工作方式”。 （即使現實已經是每個人都已經以相同的方式進行了操作，並且“我認為你應該...”僅僅是感知）正在執行AWESOME，但請按照以下步驟操作。”

我第一次審查代碼時，發現它是一種非常不愉快的經歷。我是一個“陷入困境”團隊的成員-我們所有人相處融洽，互相尊重對方的能力，並在一定程度上社交。但是，當我的代碼受到審查時，我感到自己受到了攻擊。公平地說，我是一支非常年輕的團隊的第一個“受害者”，所以我們所有人都必須積累經驗。事後看來，這都是建設性的和有益的。

我的觀點是，您必須有點同情心，才能真正知道如何接收您的反饋，並牢記傳遞反饋。在您的情況下，所討論的人似乎比大多數人更敏感，因此您只需要更加註意自己的講話即可。

提出建設性批評時的經驗法則是不要忘記對正面發表評論。另外，您也不想看起來像在攻擊那個人。沒有人喜歡讓別人挑出自己為創造而自豪的東西的所有缺陷。請注意使用“但是”一詞，以及如何將可能開始成為​​正面的聲音變成批評。始終以積極的態度結束也是一個好主意，重複讚美也無濟於事。

在調整他已提交審查的工作而不是告訴他進行更改時甚至問他是否可以，或者像 團隊 中那樣用“也許我們可以...”來表達你，他，他以及其他所有人。你們都在一個團隊中，為共同的目標而共同努力。也許他只需要輕輕地提醒一下，儘管他個人完成任務，但與其他所有人一樣，團隊對所有個人努力的結果負有責任，因此每個人都希望使最終結果達到最佳狀態。

示例：

“您像往常一樣做得很好。可以幫助我們更好地理解一些細節嗎？這個名為X的變量-表示（...）對嗎？考慮到這一點，我們可以命名為（。 。）代替嗎？這部分代碼-如果我們有註釋來解釋（...），將對我們有幫助。我們可以在此提交中添加標籤嗎？再次，這是很棒的工作。“

戒備他

如果這個人是你最好的人之一，那麼你需要給他一些迴旋餘地，讓他按照自己想要的方式工作。如果他正在做的事情與您的工作框架背道而馳，請解決這些問題。

很明顯，他具有特殊的人格特質，因此您需要與其合作而不是反對。如果您能找出引起他爆發的原因並儘力避免這些觸發因素，那麼所有人的情況都會好得多。

P.S。即使在您現在匿名發佈時也稱他為“ Rainman”（我認為您純粹是為這個問題創建一個新的SE帳戶）（我認為）確實不合適。

我想知道，這裡是否存在問題？

有時候，我們將我們認為他人的異常行為解釋為需要解決的問題。不一定是這樣。例如，我的一個朋友有一個妻子哭得很頻繁（按男性標準哭泣-即每月一次或兩次？）。他告訴我，每次發生這種情況時，他都會感到不舒服，並試圖想出讓她平靜下來的方法。這包括（a）分心； （b）將杯子裝滿一半； （c）告誡； （d）承擔責備和逃避的責任，在有限的時間內不可避免地會出現“心情不好”。一段時間後，這一切開始激怒了他的妻子，她終於對這種情況進行了心理分析，並詢問他是否認為哭泣是需要解決的問題。

為什麼人們哭時確實是個問題，不是嗎？我們從小就知道哭泣是回應的“最後手段”。因此，當達到此閾值時，我們認為某物質已出錯，無法無人值守，我們急於對其進行修復。

現在開始踢球：結果（不一定）。對他的妻子來說，哭泣是一種絕對健康且正常的應對策略，可以解決各種問題。換句話說，從她的角度來看，這是她的正常處理某些壓力或悲傷的方式，這種方式時不時地發生，並且只是生活的一部分。相反，如果她把所有東西都放進去，讓它建造起來，它可能會演變成更嚴重的心理問題（例如抑鬱症）。基本上，她完全把劇本交給了他。事實證明，他比她要付出更大的努力。

如果您有興趣，現在當我朋友的妻子哭泣時，他的默認設置是讓她在照顧自己的生意的同時放一點時間，然後（在她完成之後）詢問他是否可以做些什麼來幫助您，或者如果她想分享，那麼（如果願意）只需在沒有任何提示或解決任何問題的情況下收聽一下，除非她特別要求。通常只需要5分鐘的時間，然後他們繼續制定週末計劃或其他計劃。避免了非危機。

是否可能是情緒反應是Rainman釋放心理壓力的最佳策略，如果不允許以他知道的最好方式釋放這種壓力，那可能

故事的寓意是，我們經常根據自己對世界的理解來對他人進行假設，並根據這些假設採取行動，而無需首先檢驗它們的有效性。這個故事的寓意是否適用於這種情況？您是法官，但我想與您分享有關Rainman的一些信息。也許情感上的發瘋只是他處理溫和的建設性反饋的方式，這不是對您或您的團隊的判斷，也不是要解決的問題。如果這是一個很小的可能性，我建議非常簡短地一對一非正式地問他（非常有禮貌），您注意到他在會議中的某些討論中顯得有些分階段，並且似乎需要時間來恢復。

只需將其作為觀察結果，並詢問這是您還是團隊需要關注的問題。如果確實有必要或希望從他的角度進行降級，請讓他調整您的看法並提出降低這種情況的策略。請確保在這場對話中讚不絕口。

我懷疑讓他指導如何處理這種情況可能是最好的方法，而不是一味地認為這是一個要解決的問題並一頭又一頭地嘗試一種策略（可能導致一些實際問題的解決）道路上），而實際上，最好還是不去管它。解決問題有時是解決問題的唯一正確方法。在我們以行動為導向的企業文化中，我們通常不將無為作為一種選擇，但有時它比其他任何方法都有效。

最後一個想法。如果80％的“情感回應”行為與Rainman參加代碼審查會議有關，那麼是否可以讓他決定是否願意參加或以其他方式就代碼進行溝通？也許他比直接面對面要好得多，可以通過即時消息，通過電子郵件或在與您進行一對一的“跟進”會議（與您分享與他有關的代碼審查的結果）方面獲得反饋，面對格式？某些人在特定的通信方式方面存在障礙，這些障礙會逐漸消失，並在其他方式中不再成為問題（例如，您的好友總是更喜歡打電話而不是通過電子郵件發送電子郵件，反之亦然）。也許值得一試-只要與他在一起很酷，並且不會讓他感到單身或孤立，當然...再次，讓他來指導，你應該會好的。祝你好運！

更改代碼審查方式

隨著團隊的全球化和軟件開發速度的提高，面對面的代碼審查已成為一種過時的做法。在批准更改後，無需親自檢查代碼，而是收回工具中的每個分支。

1。使用允許內聯註釋的代碼查看工具

從生理上講，這將完成DoritoStyle的回答。它從討論中刪除了人。您現在正在討論“代碼”，而不是“編碼者的工作”。

github.com和gitlab都內置了代碼審查工具。

如果該開發人員已經對開源工具或快速發展的軟件開發公司到期，那麼他們可能會熟悉此工作流程。

2。增加代碼審查的頻率

“當某件事情很痛苦時，減少油漆的方法就是多而不是少做”。

聽起來您正在開會開會進行代碼審查。代碼審查應該很小，並且每次功能分支準備合併到母版時都要進行代碼審查。如果開發人員每天準備將多個功能分支合併到“主”分支，則意味著每天應該有多個小代碼接收。僅當使用代碼檢查工具時，這才可以擴展。

3。在合併分支到master之前先檢查代碼

從描述中不清楚在管道中何時進行代碼檢查。

代碼審查的目的是確保被接受之前的質量。已被合併的代碼在心理上是“完整的”，任何批評都為時已晚。

如果您繼續親自進行代碼審查：

• 並排坐著，而不是坐在桌子上
• 只有1人進行審查一次編寫代碼，代碼審閱不是小組審閱
• 過度交流進行代碼審閱的原因

讓我們確保該程序員清楚地意識到，關於代碼實例的問題不是對其智力或編碼能力的攻擊。

很多有才華的人的確有潛在的情緒問題，其中很多人沒有被診斷出某種東西或被錯誤地診斷出。

我本人患有阿斯伯格綜合症（DSM-5自閉症譜系障礙... ugh）（應理解為人際交往能力不強，在社交暗示等方面有些困難），有時我可能會嚴重誤解一種情況，因此，與其他人的期望相比，我的反應將是...... off。

現在，這聽起來不像是程序員的案例，但是肯定聽起來像是一個潛在的問題，還有可能是“每個人都贏”的綜合症。我開玩笑。

這並不是需要使您的團隊處於情感狀態的情況，而聽起來像是由於缺乏缺乏而只需要一點點的情況。更好的術語是“團隊合作”。我認為他需要知道他是團隊的一員，而不僅僅是一些編碼專家。

您的工作是最大化團隊所做的有用工作，同時以不逃避的方式對待他們。如果您設法創建一個愉快的工作場所，那就更好了。

似乎您知道，對於這名員工來說，他所做的工作勝過他的性格缺陷。面對他的所有問題，您寧願讓他加入您的團隊。

因此，在完成代碼審閱後，讓某人既是大人又是成年人，並且在出現諸如註釋不足或未正確標記的東西之類的事情時，該人會做筆記並在以後進行修正審查-這樣您的開發人員就可以繼續做更多的工作。

有人提到“公共汽車因素”-如果您有一個人為兩個人工作而只付一分錢，那麼這個人並不是不可替代的。他很容易被替換，只需僱用兩個人來代替他，支付兩倍的費用。

當我剛開始在目前的公司工作時，我也被視為這個人，因為我的故事因成為新人而被解雇了。

當我開始工作時，與一個對挑剔的事情超級挑剔的人一起工作-主要是語法評論和少量的風格選擇（在編碼標準之內），他也反對我做任何不同於他的事情或使用他未曾見過的事情之前。問題是，雖然他和我有相同的工作年限（當時為11年），但他全都在這家公司的一個項目中工作，而我的工作則是在許多其他公司擔任高級和領導職位，所以他很庇護/並沒有真正看到外界。他在每次CR期間對他的要求也不一致，因此即使我嘗試以他的方式做到這一點，也無法取悅此人。

無論如何，他和另一個傢伙並沒有真正相處好吧（另一個人說他試圖避免與這個人一起工作），而我所做的工作彌合了這兩個人之間的鴻溝。

問題是，人們絕對要求我做他們做事的方式想要精確的細節級別，但他們彼此不同意，即使不提出解決方案，他們也會反對我。

那持續了大約6個月，我對管理層的所有抱怨都反映在我身上很差，什麼都沒有改變。我們的老闆回來了，並澄清說我不是在那個人的帶領下工作，所以也不會下屬。

當我能夠加入另一個團隊時，情況最終改變了。

我已經有4年了，而且一切都很好。

我從來沒有在專業環境中受到過如此惡劣的對待，並且真的很難弄清楚如何處理它，因為這對我來說是一種新的體驗，而管理層也無濟於事。

也許應該與您的人交談並嘗試找出他們的POV是什麼？也許您的“老朋友”正在成為自負的混蛋？

像Rainman這樣的人需要一個結構化和組織化的框架，這就是為什麼像他這樣的人通常會表現出重複的行為以及極端的秩序。如果他是一個真正的Rainman，即使他的辦公桌看起來很糟糕或者他的代碼總是具有相同的美感，您也會看到每張紙總是放在同一地方。

因此，要與他建立良好的關係，您必須尊重秩序，保持明確的規則，並儘量減少對話。不要浪費時間折磨他，說“你為什麼給這個變量命名為” that”？”，而是製定一條規則為變量命名，然後給他說“這是命名規則”。

我不確定您是否有問題。您的明星很激動，但您說他第二天來就可以了。您似乎說他的生產力水平很高，我想他並沒有崩潰。您還說團隊的其他成員都接受他的行為。您並不是說即將到來的威脅。如果是這樣，我將投票支持“她走得穩定”。人們各不相同。讓它們變化。除非明確證明有乾擾，否則請勿干預。行為超出您預期的人並不是乾預的理由。高生產力的人從來都不是平常的。

我確實有一些擔憂。你是怎麼得到這顆星的？你知道他為什麼離職嗎？如果他在那裡遇到問題，那可能是如何與您一起預防的線索。其次，仔細查看您的團隊。一顆新星通常具有破壞性，需要付出一定的努力才能舒緩起伏的自我。您似乎暗示著，沒有人會討厭一個新人，因為他解決了閱讀代碼的副作用，從而解決了很多問題。如果我是您的長期團隊中的一員，我會感到被鞭打，可能會有意識或無意識地嘗試給新星打沙袋。在代碼審查中選擇愚蠢的東西可能是做到這一點的一種方法。我希望您已盡力確保所有這些都沒有發生。

我的經驗是，新星比中級開發人員對團隊生產力的負面影響更大。星星通常會照顧自己。這是團隊中的其他成員需要周到的照顧。

我認為，僅在以下情況下，代碼審閱者的建議才應具有約束力：

• 已發現錯誤。任何開發人員都可能會遇到錯誤，並且要說聲謝意，包括大多數敏感的人在內。
• 開發人員沒有總體經驗，也沒有代碼經驗（第一個月，如果代碼真的非常複雜，則需要更多時間）。
• 您沒有描述您希望如何編寫代碼的正確文檔。

在其他情況下，最好將審閱者建議設為可選。進一步的事件取決於開發人員的個性，但是無論如何，許多事件都會應用合理的建議。如果有人系統地偏離上述指南文件，則必須在會議期間討論此類事情（包括討論該指南多少合理以及為什麼）。如果開發人員不應用修補程序，則審閱者可以應用修補程序-這是一種有效的方法，可以說服該指南易於遵循並且必須得到遵守。在某些情況下，審閱者以這種方式可能會發現事情實施方式有所不同的原因（當前版本看起來更具可讀性？“正確的方法”導致無法測試的代碼？某些事情完全不可能？）。

強力遊戲，

從這裡開始，操作項目將是：

• 限制對以下內容的強制性修復：

• 使所有其他建議為可選。

• 編寫文檔，說明代碼的外觀喜歡並確保所有人都知道在哪裡可以找到它。

這應該使不喜歡代碼審查的人的生活更加輕鬆。代碼審查是很大的壓力，在大多數職業中都沒有發現（老師或醫生真的不喜歡您去比較兩者時），並且重要的是不要拉扯到超過人性所能承受的範圍。 >

我將不解決一個事實，即一名員工可以超越整個團隊。我只會解決在代碼審查過程中，雨人（或團隊中的任何一個成員）會發脾氣的問題。

有些人的思維速度比其他人快。有一些方法更適合某些人，而不是不同的人。有些人以一種“他們的”方法來解決問題時會很快，但是當該方法（有一點不同）時就完全迷失了。

我研究了應用物理，等離子體物理和薄膜生長。現在，我在機械工程學院工作。有時，我同事的態度和習慣使我發瘋（通常是他們在使用什麼工具以及如何使用它們）；有時，我會讓他們發瘋（通常是不提及我發現很明顯的重要信息，或者爭論發現的事情，而我們從一開始就希望擁有同樣的東西）。換句話說，有時似乎我們來自不同的宇宙……

您問過您的雨人，“為什麼要命名變量那個”的哪一部分？問題讓他們煩惱嗎？這個問題在他們的愚蠢程度上太愚蠢了嗎？嘲笑他們的工作流程嗎？問題的語氣是否使他們感到不舒服？

為自己列出一系列任務：

1. 意識到，這是一個問題。檢查
2. 命名問題原因。等待中...
3. 找出問題的原因。
4. 找出防止問題發生或阻止問題升級的方法。
5. 創建適當的規則並堅持執行。
6. 與整個團隊討論這些規則
ol>

不要不要嘗試解決無需問雨人或不參與解決方案。 不推斷他們的情緒，反應等。不嘗試解決他們的背後問題。 不要嘗試將任何東西藏在地毯下。

---

也許，有一個團隊成員因雨人的工作和行為而瘋狂，並且還沒有爆炸。被告知的事情是無法言傳的。嘗試在所有成員之間找到折衷方案。

• 問題1：您在我們的代碼審查會議上發現什麼錯誤？
• 問題2：您認為可以改善代碼的什麼？ -review會話？
• 第三季度：您喜歡在代碼-review會話中做什麼？

我將以與處理其他任何性能問題相同的方式進行處理。向您解釋您發現了一種行為，並詢問如何為員工提供支持。

嘗試更多地圍繞幫助和協助而不是紀律性來措辭。

我知道您有時在工作中會感到沮喪。我們可以做些什麼來幫助你？我們可以採用任何流程或機制來支持您嗎？

雨人做得很好。至少可以說，他的舉止是不合常規的，我很高興您和團隊評估了情況，並決定考慮好與壞。

讓他在您的環境中感到安全，找出是什麼讓他打勾，以及如果他在公司裡感到高興和舒適，那麼他跳船的機會就很小。

我在這裡假設您和團隊了解他的特質並具有對他們採取了活生生的態度。

您也許可以向他建議更好的方法來應對讓他不高興的事情，但他是否聽是另一回事。我通常建議其他人不要讓事情動搖，特別是如果我知道他們的頭是情緒的大雜燴，只是在我打開水龍頭的那一刻等著倒出來。令人驚訝的是，大多數人告訴自己“我不會讓我難過，因為讓自己不高興並不值得”時，他們不會生氣。向他建議應對壓力源的方法，這些方法可能對他更有效，同時最大程度地減少了對每個人理智的負面影響。並保持建議的友好，樂於助人和非侵入性。