我應該和團隊負責人一起提出這個問題嗎？

不。僅有幾年經驗的最初級成員不應向團隊領導抱怨最高級成員的代碼質量。

讓團隊領導來處理它-絕對不可能告訴他們他們還不知道的事情。隨著時間的流逝，他們容忍它的原因（或者甚至鼓勵以權衡取捨以加快產品上市時間）可能會變得更加明顯。和團隊領導者）不適合您的質量偏好，您可能需要在其他地方尋找。

也就是說，即使是初級成員也可以以身作則。確保您的工作是一流的，質量是無可非議的。確保您按時完成所有任務。確保在需要的地方幫助他人。也許其他人會注意到並希望這樣做。 p>

稍後，當您在小組中成為本地代碼質量專家後，便可以進行流程更改。也許您可以在那時提出領導代碼審查，或者幫助完善和執行小組的編碼標準。

您正在開發業務代碼，因此除了（實際上，不僅僅是）開發人員之外，您還需要像業務人員一樣思考。隨著您獲得更高的資歷，這種思維水平通常會提高。要說服人們開始遵循它，您需要一個比這更令人信服的理由：

我認為不應出現在我們主要分支上的東西

您需要數據來備份您的索賠。您當然可以去找老闆並建議採用所有閃亮的材料（儘管是初級產品），但準備回答這個問題，“這樣做會給項目帶來什麼好處？”

模糊的語句，例如“它使代碼更具可讀性/可維護性/可測試性等”。 （或者更糟糕的是，“如此推薦”）並不能說服任何人改變他們經過實踐檢驗的方法。

請記住，您上級的“可憐”代碼已經完成了工作年齡。 “完成工作”是企業中最重要的事情。告訴人們只有通過您的“意見”來完成工作的更好的方法不會說服他們冒險。

我當然會鼓勵您推動團隊採用閃亮的方法資料，但準備投入所需的精力來收集數據以支持您的主張。

作為另一個提示，我希望您在說服前輩時不要使用本文中所使用的語氣。 “哈哈，你們真爛，我會教你如何做的”絕對不會奏效，“我有一個改善X的建議，我認為這些就是它會使我們受益的原因。您怎麼看？”更有可能被接受。

我在以前的公司中確實經歷過。結束得不好。

我們兩個都在編寫代碼，這位資深同事非常熱衷於復制和粘貼編程。 （“記住，這沒有問題。”）遵循相同的思想模板，相同的代碼塊在代碼庫中分散了大約50次。我可以忍受，儘管我不是很喜歡。通過 try ... catch 進行空檢查並進行空異常處理很常見。一段時間後，我開始重構這些東西，並被告知我妨礙了工作，因為在更改之後，他不再能夠依靠舊的結構“從他的記憶中”進行編程。儘管修復的質量和消除的許多錯誤的質量，但我還是被告知“我損壞了代碼”，因為在業務中，沒人關心次要的代碼問題，唯一的標準是在最短的時間內完成工作並獲得滿意的客戶。使用代碼導致我不滿意，而且我也錯過了不能足夠快地“複製粘貼”的截止日期，因為我感到自己不想成為我期望的那樣“快速而直接的程序員”。最終，我離開了公司，找到了另一家在我認為是該領域標准上達到我期望的公司。它們通常非常高效，對細節的關注度不高。如果您不喜歡這種方法，請考慮是留在公司還是離開公司。

在這種情況下，我認為您無能為力。與您的團隊一起對高級成員提出質量問題會導致很多尷尬的時刻和對話。 （除非存在一個重大錯誤，否則由於該錯誤根本不會運行代碼）。否則，您可能會被認為是對自己有較高評價（或對他人沒有評價）的人。 。

我的建議是，盡力將代碼保持在所需的質量，並讓其他人執行自己的工作。同樣，您可以不時地因果地談論代碼質量，而無需將矛頭指向任何特定的人。在某些時候，人們會注意到您的努力，他們將檢查所有修訂歷史。他們會為此識別您的。此外，您有時可能會在團隊中處於相對較高的位置，可以“要求”團隊提供更好的代碼質量。

在這一點上，我認為您應該付出額外的努力，並儘自己最大的努力保持代碼質量，並向所有人表明您對使用乾淨的代碼很感興趣！

首先，您的同事可能知道他在做什麼，並且有這樣做的理由。例如，如果您要進行敏捷開發並每周向客戶展示原型，那麼這可能是一個完全合法的策略，即盡快實施盡可能多的功能，以便客戶/用戶可以看到設計並給出其觀點。 ，然後在您知道您對需求達成一致後，再擔心邊緣情況，錯誤情況和代碼質量。

其次，您的同事可能是一個善於了解全局的人並且不善於遵循這些小細節。我參與過多個項目，這些人具有遠見卓識並設定方向，為項目的成功做出了巨大的貢獻（儘管這樣的人常常最終自己不編寫任何代碼）。在這種情況下，需要其他人對細節痴迷。他們可能（也可能不會）認識到自己的描述，特別是如果您以積極的方式向他們展示。嘗試在不造成犯罪的情況下，找出他們對自己的長處和短處的評估（因此，在需要隊友幫助的地方）是否與您的評估相吻合。具有明顯的表現，而不是沉迷於“您認為應該編寫好的代碼的方式”。避免主觀批評（沒有兩個程序員在良好風格的所有方面都達成共識。）並專注於您有正當利益的代碼領域。編寫失敗的測試用例，並針對它們記錄錯誤。將註釋或TODO添加到代碼中，例如“需要在此處處理I / O故障”。

目前我們沒有專門的代碼審查，並且我目前不希望我爭取他們。

是的，這就是您的要求需要（即使您認為不能）。

除常規代碼審查外，其他任何措施都無法解決這些問題。

如果您的團隊足夠大，請找其他人每週進行一次代碼審查。您只需要兩個人即可上手。當僱用新開發人員時，請他們加入。代碼審查實際上是入門的一種好方法。當然，這並不能解決您眼前的問題，但是假設您能夠找到願意參加的另一位隊友，那麼很容易獲得團隊領導的許可就可以開始比賽了。

除非您已經有大量的團隊成員參與（可能需要數年時間，但最終您必須從某個地方開始，否則就不要指望其他現有的開發人員加入）。永遠不會開始）。

並且請確保盡可能高效且無判斷地幫助運行這些代碼審閱。即使團隊負責人願意提供幫助，也不要指望他像您那樣徹底地研究該主題並儘可能有效地領導那些代碼審查，因為這基本上是您嘗試的想法。

同樣，這不能解決您的直接問題。您想改進他的代碼，而不僅僅是您自己的代碼。不幸的是，這樣的新習慣不會一夜之間出現。他們需要時間來發展。

關於《蒙面俠》的帖子：

關於需要數據來備份有關空檢查，吞嚥錯誤，錯誤的類名等的聲明。代碼完整這本書包含了備份此類聲明所需的所有數據。另外，您可以使用當前現有的分析包在代碼庫中跟踪其中的某些內容。例如，即使缺少關鍵信息，您也可以計算應用程序無提示失敗的次數。

但是我建議您不要浪費任何時間。與試圖跟踪該錯誤的後果相比，解決該錯誤要簡單得多。而且由於開發人員的自我意識很強，因此數據無論如何也不會改變主意。您的團隊領導也是如此。即使他在原則上同意您的意見，他也必須權衡良好編碼實踐的好處和與您的特定隊友不斷爭論的缺點。

您說您嚴格遵守代碼質量，但是您沒有責任，因此從公司的角度來看這無關緊要。

重要的是公司的立場關於代碼質量。

如果有嚴格的公司政策，您可以使用它來與同事進行任何討論，但是嘗試去找主管會產生很多衝突，因此最好避免普遍的風格問題不會導致災難。

如果對此沒有嚴格的公司政策，我什至會考慮（與您的同事或主管一起）提出的唯一問題是

首先聯繫您的同事。不要告訴他事情的發展方式（因為您不應該以為自己了解得更多，而且沒有更快的方法可以使某人防禦。） 詢問，他會按照自己的方式做事，並回答一個論點，以解決可能存在的問題（也許他有充分的理由以他的方式做事）。

如果這不起作用，您可以考慮與您的主管一起提出來。

別指責或什至完全不提及另一位團隊成員-只要提出以下任何一項問題並指向代碼庫中的一個或兩個示例，並繼續使用上述相同的謙虛方法。

您的主管可能會檢查或要求您檢查誰編寫了代碼（如果可能），並且可能會導致您的主管與所述同事解決此問題。但是所有這些都將由您的主管決定。是的，這可能會導致您的同事認為您“把他拉出來了”，所以後果自負。

來自經驗豐富的程序員，應該完全避免您說的所有事情，但在“我們要死了！”中，這些都不是必須的。嚴重性。忽略的異常或缺少空檢查可能造成災難性的後果，但是有時它們在功能上也不必要或有意省略。類的命名完全不會影響我所知道的任何語言的執行（儘管存在反射），因此，比上述可能會在運行時引起問題的問題要輕得多，而且通常也完全基於觀點。

因此，我認為將所有這三項設置為大致相同的嚴重程度會傷害您的論點。

但是您當然可以拒絕在不符合您標準的環境中工作並將所有樣式問題升級為威脅生命的嚴重問題。

機構強制性代碼審查。

您不只是要求這種政策轉變而處於政治立場，但您可以將其建議給團隊的其他成員並獲得他們的支持。一旦您的絕大部分同意，請與較大的團體一起提出。這是您應該執行這些操作的重要原因： https://www.atlassian.com/agile/code-reviews

我們的辦公室做到了這一點，我很喜歡。 / p>

儘管代碼質量很重要，但需要將其納入管理層的期望和團隊成員的技能水平的範圍內。希望在這方面有所改善是一件好事，但要專注於問題，而不僅僅是症狀。

您所建議的一切都是有原因的。用戶是否由於缺少需要調試的空檢查而出錯？每個程序員都應該知道，越早發現這些漏洞，他們越容易修復。他們。最好在代碼評審或某種過程中讓每一行代碼都受到關注。如果您沒有執行團隊認為最好的解決方案，就會遇到麻煩。如果允許一個程序員按自己的方式做事，那麼這些都不起作用。

在某些時候，很明顯，這個人的代碼比其他人創建的代碼引起的問題更多。由團隊來解決性能不佳的問題。希望每個人都可以在這些問題上達成共識，以尋求更好的代碼。

這是一個可以教育的時刻

我認為，如果您將團隊領導定位為學習的機會，那麼可以接近團隊領導。

告訴潛在客戶您有關代碼一致性的信息，並希望確保您遵循正確的標準。您是否應該寫出您認為適當的代碼質量水平的代碼？還是您應該做更多類似高級開發人員的事情？

通過這種方式提出問題，可以避免對抗，但要確保團隊負責人意識到這一問題。

P.S。我建議您不要急於求助，請準備好讓它下降。

聽起來這不是高級同事的問題。如果有機會，人類通常會選擇阻力最小的路徑。您的問題是，過程並沒有執行您認為必要的質量標準。

請讓我平靜地接受我無法改變的事物，勇於改變我所能做的事情，以及了解差異的智慧。對這個過程有任何影響的位置。你能改變他們還是不能改變他們？

我基本上是在一次偶然的對話（或幾次對話）中嘗試收集信息，以弄清他們過去所做的事情以及他們的反對意見遵循您建議的做法。僅僅從這件事上，您就可能會感覺到可能會影響的事情。

---

您可能直接影響的事情會問更多高級團隊成員對您的代碼進行非正式的代碼審查。請記住，您是一個初級人員，因此您毫無用處-讓團隊中的高層人員檢查您的工作肯定會減少您引入的錯誤數量，並有助於您學習*。我認為您不太可能無法讓一個人同意這一點。

這樣做，不僅會使您對自己的代碼更有信心（即使您沒有這樣做）同事的代碼），但也許您會開始營造一種氛圍，在這種氛圍中，代碼審查被視為流程的重要組成部分。

*我很有趣。

沒人喜歡這樣的雜貨店櫃員。

您擔心自己的代碼，很快您的同事會認為您是該產品的所有者。

我遇到了類似的困境，我是高級開發人員，而同齡人則是初級人員，其中許多人對質量不感興趣。 >

根據我的經驗，代碼樣式確實很難實施，並且總是導致許多徒勞的討論。這是一個主觀問題，有些人對此有很強烈的意見。如果您真的很在意它，則應該說服您的團隊實施一個自動化的構建系統（例如：Jenkins），並在其上添加自動化的源代碼驗證。如果未刪除代碼，則構建會變成紅色，並且將不被接受。

我應該和團隊負責人一起提出這個問題嗎？

是。

但是，在這樣做之前，請先閱讀並確保您提出正確的要求“ this ”。

的確，作為初級成員，這不是您所說的“其他開發人員正在編寫不良代碼”的地方。但是，您認為可接受的質量代碼與其他團隊成員認為可接受的代碼顯然存在差異。 那可以和您的團隊負責人討論。這樣，與別人的過錯無關，而更多的是尋找從此處繼續的好方法。這可能意味著您的團隊負責人告訴您可以放寬編碼標準。這可能意味著您最終找到了正確的中間立場。

無論哪種方式，由於人們所遵循的代碼標準不同，您都會感到不舒服，因此這應該是您所討論的。

目前我們還沒有專門的代碼審查，而且我目前還沒有看到我

確實，您不能按 push 進行代碼審查。但是，您可以建議使用代碼審查。甚至可能是他們認識到可以通過“新鮮的一雙眼睛”帶來什麼進步，並且使用專用的代碼審查可能就是這樣。

另一種不引起任何不利影響的方法是傾斜解決問題，這是團隊發展的過程之一。識別代碼庫中過去觀察到的一些錯誤，這些錯誤會在引起麻煩之前就遵守編譯器警告或其他工具。然後，您可以將其帶給團隊負責人甚至整個團隊，並建議將這些檢查中的相關警告類型轉化為構建/測試過程中的錯誤。沒有人喜歡在編寫並繼續編寫代碼後才需要重新編寫代碼。您可以通過這種簡便的方法來確保第一次就一切都正確，並避免出現可能的錯誤報告。

隨著時間的推移，您可以挖掘檢查人員可能擁有的更多錯誤類別。

另一個好處是，這種方法還避免了花費大量精力來解決對代碼的抱怨，這些抱怨始終與您的特定應用無關緊要。從錯誤的意義上講，警告可能不是誤報，但在沒有改變的意義上，警告可能是誤報。

這個詞是根本原因分析。如果您可以證明這些提交是一個或多個主要錯誤的根源，請在團隊會議或缺陷審查會議上作為一個小組討論這些提交，以提高對這些技術的負面影響的認識。如果不是這種情況，您還可以通過電子郵件將摘要發送給團隊，並請某人提供解釋，這樣至少您可以改善文檔。

參考

• 使用模式（pdf）改進軟件檢查過程

• SEI Personal軟件過程：自我完善