很明顯，批評您的長者不是一個好主意，應該避免。初中生也很不好。

要記住的一件事是，鬆散的編碼實踐並不一定會導致編譯後的代碼變差。因此，如果有效，那麼有效，並且伙計們知道如何維護自己的代碼。人們可以並且確實會為自己的代碼庫部分辯護。

您可以（並且應該）做的是在自己的代碼部分中保持最佳的編碼實踐。當其他團隊成員在代碼庫中看到此內容時，或者您正在通過示例進行交談時，請允許其表示自己。

如果您需要處理其他人已經在代碼庫中工作的部分繼續，您在遵循它時遇到了問題，那麼請務必讓開發人員仔細討論相關部分，以便您可以快速完成此編碼任務。

您不必指出糟糕的編碼其他人的做法-照顧好自己，希望其他人注意並接受您的工作。

應該對所有代碼 進行同行評審（但是我在很多從未發生過的地方工作過）。乾淨多乾淨？應該有編碼標準和指南；要求他們。關於你應該多麼“挑剔”；這取決於正在審查的代碼。有些人喜歡讓他們指出空白行和間距。其他人更喜歡您發現潛在的問題。

不要因為小三而閉上嘴，但要特別注意突出的內容。這裡的目標不是責怪遊戲，而是作為一個團隊共同改善代碼庫。嘗試提出改進建議。該代碼可能不是“錯誤的”，但通常可以改進一些東西，除了個人編碼樣式。

除了其他答案外，還有幾點：

接受作為初級的您並不了解所有內容 :-)可能有風格的原因

• ，避免對工作代碼進行不必要的更改（保持差異可管理，避免引入不必要的錯誤，&c）。

• 保留相關代碼，以便可以一起查看。 （如果只是用簡短的功能掩蓋了複雜性，就沒有好處。）

• 避免細微的語言或性能問題。

• 匹配其他代碼的樣式。 （不要低估代碼庫中一致性的價值；它可以使代碼更易於閱讀，理解和維護，減少開發人員之間的衝突，並避免細微的錯誤。）

這就是說，您所做的更改也很可能值得做出！

• 大多數開發人員都很平庸（即使我們都認為自己是很好。）。

• 以前的開發人員可能很著急，沒有時間考慮重構。

• 以前的開發人員可能對乾淨的代碼沒有足夠的關注，或者沒有看到如何改進它。

根據我的經驗，每個代碼庫都可以得到改進 >。即使在我已經編寫和工作了很多次的代碼上，我也經常發現以前錯過的改進！

關於如何處理它，我建議：

• 不要批評您的其他開發人員，或者要表現得比他們更了解。即使您這樣做，也不會贏得您的朋友-良好的工作關係也很重要。無論如何，建議改進，但以建設性的方式，不要怪罪。並接受他們可能不同意的想法。

• 首先對重要同事進行重大更改。如果存在上述任何原因，最好在 造成大量損壞之前先了解一下！

• 不要僅僅為了代碼而重寫代碼。。原始作者可以親自處理；而您希望被視為與他們 合作，而不是反對他們。 （請記住，對您而言似乎明顯的改進可能對他們而言看起來很不相同。。）此外，每次更改都會帶來風險；一個不錯的測試套件&c可以減少這種情況，但是更改不是免費的，保守可以節省很多麻煩。

• 相反，在進行過程中進行改進 strong>：修復錯誤或添加功能時，請改進已經在使用的代碼。這樣，就更容易計算所花費的時間，並且不需要任何額外的測試&c。最終，質量會提高。

• 最後，請接受雖然很重要，但提高代碼質量只是幾個優先事項之一。是有限的，並且總會有妥協。不幸的是，但這是事實。

您很在乎代碼質量！太多的開發人員沒有。但是，請嘗試以對團隊和代碼庫都有益的高效方式使用您的關注點。在某種程度上，我仍然會這樣做！但是我也看到自己的代碼無意義地被更改，或者被那些我不同意優先級或者只是誤解了代碼的人弄糟了。而且我一直在為使用不一致的代碼庫而苦苦掙扎格式，命名，組織和样式。最終，如果代碼庫可以很好地協同工作，並且開發人員可以一起工作，那么生活會好很多。）

別掛在大三/大三上。沒有人是一個完美的開發人員，每個人-無論頭銜如何-都有改進的機會。

也就是說，考慮環境非常重要。如果您要挑選出當前並不重要或不重要的舊工作，然後告訴他們為什麼質量不好，那就不好了。另一方面，如果您正在與該人員一起進行代碼審查，並查看當前正在使用的代碼，則您會有更好的機會。歸根結底，您需要了解，雇主並不是天生就追求完美，而是在尋找具有一定可持續性水平的功能。當然，某個功能可能是可重寫的一種無需花費過多秒鐘即可幫助您理解它的方式。但這對於特定項目可能不值得。

此外，請考慮批評具有負面含義。沒有人喜歡批評。代替

這是錯誤的

或

這可能更好

您可能想嘗試，

您能向我解釋此功能嗎？

還是

您能告訴我為什麼這樣做嗎？

這些開放式問題可以讓其他開發人員通過他們的代碼和思考過程進行交流，這可能會使您意識到有正當的理由去做他們所做的事情。或者，這可能會使他們意識到這樣做可能更乾淨/更好。或者，它可以為您提供建議改進的環境。歸根結底，您已經提出了自己的觀點，並且與只是因為批評而感到冷落相比，保持關係的機會更大。

30年的軟件開發專業人員在這裡。也許我收集到的一些見解可能會對您有所幫助。

1. 不要在您睡覺的地方睡覺。每個人都認為其他人的代碼很爛。這對於閱讀任何難以理解的代碼是很自然的反應。為此，除非您有充分的理由（例如：告訴老闆為什麼功能更改要比預算更長的時間）只會打勾您必須與之合作的人 / em>，並讓其他所有人與您一起工作，不知道您在看代碼時是否要對他們的代碼說同樣討厭的話。
2. 以適當的態度來考慮他人代碼的問題是您可能是錯誤的。您可能缺少了什麼，對吧？我努力做到這一點，並且仍然對事實如此頻繁而煩惱。人類是不完美的，容易混淆，您也是人類。
3. 請高級人士參加。向其他人（例如：Cubemates）顯示您遇到問題的代碼。通常，這將導致經歷過戰爭的某人對它的所作所為做出解釋，並解釋其原因，或者達成協議並承認其劣勢。在極端的情況下，甚至是憤怒，來自比您自己更充分地投資於代碼庫的人，並且管理層會聽取他們的意見。無論哪種結果，對您來說都是一個巨大的勝利。
4. 如果您必須抱怨，請抱怨行為，而不是人們。並不是說“弗雷德的代碼”天生就是cr腳的。令人討厭的是，此位在大約7個屏幕屏幕上相互嵌套了3個lambda聲明。這樣的事情需要被禁止。我們可以更改樣式指南以禁止這樣做嗎？確實，必須要比這更好。我們不能有15個相互作用的類，它們都用相同的五個詞（其中兩個是“模型”和“視圖”）進行排列命名。另外，任何長於約1000行的源文件都應分成較小的類。這條1500行長的例程應該永遠不會發生。 ^{* sup>這花費了我們大量時間進行修改和跟踪錯誤。我應該和誰談談如何在樣式指南中獲得這些東西？}

您可以批評代碼，而無需批評開發人員。我的猜測是，他們希望做得更好，並歡迎同事的謹慎評論，並表示歡迎。匆匆忙忙，有點草率是正常的-提醒可以解決這個問題。

如果您已經從事開發工作5年以上，那麼初級/高級劃分不會有太多幫助意識，除非您的工作場所真的採取了激進的分層措施，否則您最好不要考慮它是一個障礙。完成後，您可能會說“哦，好的，是的，我現在看到了。哦，嘿！您介意我重寫它，使它更易於維護嗎？這將有助於我更好地理解它，並在以後供其他人使用。 “

以這種方式表示，您正在獲得建議並尋求幫助-不是執行代碼批判-而是得到相同的結果。很多人會回答“哦，很酷，謝謝，太好了。下次我會盡量保持整潔。”

這可以為以後的類似交互創建上下文。

根據情況和與您一起工作的人進行調整。

如果您發現同事們沒有空缺，那很不幸，但是有時候就是這樣。根據定義，他們越專業（高級與否），他們就會越開放。

值得付出努力。

我認為我的主要建議是假設這些人確實想提高自己的代碼質量（這是代碼質量問題）。但是您對踩腳的擔憂始終是正確的，應該得到考慮。

此外，支持整個團隊的進步也是您工作的一部分。

您是否會在會議中穿上這套衣服-與其他開發人員以1：1的比例穿著？還是只是因為大三而閉嘴，等到你足夠高的時候再等待批評？

我會“閉嘴”，但不是因為你不是“高級”足夠”，但因為您不是他們的經理，評論他們的編碼風格也不是您的工作。

在這裡，我的意思是僅在您提到的情況下才“閉嘴”。您可以在非正式討論中隨意談論您的更乾淨的編碼風格及其好處，而並不意味著他人沒有按照您的意願做。

另一種方法，取決於您的團隊文化是什麼，您可以要求經理允許您進行“技術講座”或“午餐&學習”之類的會議，在此您可以學習一些新的編碼思想你有。通常，團隊會舉行這些會議，每個人都可以交談，而不論他們的資歷如何。可能是您的高級開發人員可以學到什麼，或者是誰知道可以教給他們一些他們為什麼要做的事情！

不過，您對待這個想法的方法是只提及您所做的事情，而不是一口氣教別人關於他們應該做什麼的-1次會議。

就像其他人在幾個好的答案中所說的那樣，有一些建設性的方法可以與其他人一起提出問題-問為什麼像他們一樣寫代碼，而不是批判性的。

我想提供另一個潛在的解決方案：如果您的團隊不對代碼進行單元測試，那麼您應該成為代碼的擁護者。開始將單元測試添加到您自己的代碼中，並說明它的價值。由於經理討厭錯誤，因此他們應該希望可以改進代碼庫的測試和可測試性。單元測試（正確完成時）自然會迫使每個人開始編寫更小，更整潔的函數。您最終將獲得既乾淨又經過測試的代碼。

不要等到您擁有高級職稱才能評論其他人的代碼。我的經驗是，標題與反饋的方式無關緊要。

問，長輩是否可以分享有關代碼的反饋，或者是否願意將其表示為詢問有關代碼的問題。

嘗試盡可能具體，並儘可能解釋它對您的影響。 “我發現這種方法很難讀，因為它很長，並且做兩件事。”或“我對這個方法名稱感到困惑，因為它說X，但是該方法確實是Y”比“您編寫不良代碼”更容易被任何開發人員接受

您可能還會問是什麼原因對於特定的編碼選擇（通常我經常發現“錯誤代碼”實際上是有原因的。）

這種反饋應該足夠無禮，並且如果開發人員把它做好，可能會有一個進行後續討論的機會。 “羅伯特·馬丁建議用這個來命名，您怎麼看？”

但是，開發人員也有可能不同意您或您最喜歡的作者，並且不太在乎您的意見。只要確保您對開發人員的精力，就不會因為冗長而產生積極的影響。

從廣義上講，“清理代碼”是很好的，但不是標準的。標準是公司的風格指南。無論您在某本書中或在某處學習什麼，您都將進入一個組織，並且情況會有所不同，他們會有自己的“經驗法則”。

如果沒有樣式指南，那麼通常，代碼庫基本上會適應代碼審查人員的偏愛或技術領先者所維護的東西。

我不會假裝了解您所處的情況中的每個變量，也不會主張這些事情是適當的。但是，它們確實會影響代碼質量：

有時，有很大的壓力要求更快地推送代碼。由於它具有競爭優勢，因此要盡快將其投放市場，實際上，這可能是更可取的。馬丁·福勒（Martin Fowler）在他的重構書中談到了這一點。

您並不總是擁有理想。理想可能為時已晚。但是，您可以做的就是每次您都在可以進行一些小的更改時，都應該做。

廣義上講，如果我對此有一個建議諸如此類的事情：總的來說，總是倡導最乾淨的方法來做某事。但是，切勿在代碼中留下自我。您的工作是解決問題，而您認為自己的代碼“不干淨”的想法是您將自我投入代碼中。學會保持中立，並了解事物並非總是像看起來那樣。

我認為您應該接近它們嗎？否。我認為，從廣義上講，您應該倡導“清潔代碼”嗎？我當然是了。但是變革很少是從底層開始的，要先擔任領導/高級職位，然後倡導“清潔代碼”政策。

簡單地告訴人們他們的代碼不干淨，不會做很多事情。而且它完全忽略了代碼的上下文。有時，軟件開發的社會學意義遠超出人們的想像。上下文就是一切。

要有效地引起對代碼質量的擔憂，必須建立高質量代碼的定義。其次，代碼審查是一種以建設性方式提出這些問題的理想環境。

樣式指南

您的部門是否有代碼樣式指南？如果沒有，那麼同行的代碼不清晰或不一致也就不足為奇了。您可能想與主管一起提出缺乏代碼標準的問題。強調一致性樣式如何通過減少上下文切換開銷來提高可維護性。如果您的主管看到了這一價值，那麼開發這些標準可能對您有益，因為它對您而言似乎很重要。

代碼審查

理想情況下，利益相關者，同伴，主管將有機會在結構化的代碼審查過程中提供反饋。這比預訂一對一會議更為可取，因為它提供了一個更開放的論壇來提供反饋，並且不太可能得到防禦性的回應。您可能還想與您的主管一起提出這一點，強調這是您一個學習例如為什麼同行以某種方式編寫方法的機會。

無論您何時何地使用自己的方法，同事，您應該從更具好奇心的角度來。與其向他們解釋為什麼代碼是錯誤的，不如問他們為什麼以某種方式編寫方法。即使您是正確的，也可能會採取防禦性的應對措施來提出全面的指控。古老的格言是“用蜂蜜比醋可以捕獲更多的蒼蠅”。而且，如果您不正確，您將很高興自己的方法謙虛。

1. 如果您想成為某個領域的專業技術人員，必須首先學習該領域的專業人士。
2. 質疑某人不是就像侮辱他們一樣，除非您做錯了。
ol>

這既關乎您問的時間，又關乎您如何問。

“何時”的好時機是一對一的時間，例如在配對編程時或在代碼審查期間。如果兩者都不存在，作為一個初中生，您可以輕鬆地為兩者創造機會。只需問一個高級人員來檢查您的更改，您就可以自己進行代碼檢查。或要求高級配對計劃進行半小時，這樣您就可以了解有關您需要處理的不熟悉組件的更多信息。

關於“如何做”：如果您不了解他們為什麼會以他們的方式做某事，只需告訴他們您不了解並詢問他們為什麼以這種方式編寫代碼。人們有以某種方式做事的理由。您的目標是找到這些原因。有時有完全正當的理由，它們的代碼比您編寫的要好。有時，原因是外在的（例如，鼓勵優化“代碼行”，“單元測試數量”等）。有時原因只是意見上的細微差別（對於功能而言15行太長了嗎？）。有時原因是程序員習慣了一些不良的編程習慣。

如果您弄清楚如何正確地提出問題，許多人會自由地承認該代碼是垃圾，並為您提供了造成垃圾的原因及其原因的列表。到目前為止，我還沒有看到在某種程度上不是垃圾的代碼，而且我已經看到並編寫了很多代碼。

我不知道這是答案，也不是我對這個問題的想法。我認為這種情況取決於代碼及其“不良”程度。我從事過少數應用程序的開發，這些應用程序已經使用了5年甚至15年以上。該代碼可能不是最乾淨的，但是它可以工作，並且已經可靠地工作了多年。

不同的程序員對如何編碼有不同的看法。這些年來，樣式已經改變。並非每個人都緊跟最新趨勢，有些人只是按照自己的方式而定。您必須能夠將樣式與不良的編碼做法分開。最後，重要的是代碼可以可靠地工作。

如果這是舊代碼，則可能需要查看正在編寫的新代碼，並查看它是否遵循更好的做法。在較舊的應用程序上，有時您會看到編碼樣式隨時間變化。較舊的代碼可能不是很好，但是較新的代碼遵循更現代的做法。

查看誰在提交內容。您可能有一些編碼員編寫簡潔的代碼，而有些編碼員編寫簡潔的代碼。

說出來。不知道我是否會在會議上提出來進行討論。與您的隊友1：1交談，並弄清他們對乾淨編碼實踐的感覺。看看是否有任何團隊標準的代碼編寫。將其帶給主要開發人員。如果他們認為這是應該在與團隊討論的會議上提出的，那就太好了。一些團隊比其他團隊更關心編碼實踐。許多團隊只在乎代碼是否有效並通過驗證。

我同意其他人的觀點。不要有判斷力。詢問代碼。詢問標準。盡可能多地學習。提出建議，但不要太用力。

總的來說，提出並進行討論並不是一件壞事。您正在嘗試改善編碼實踐。

您不應批評現有代碼，也絕對不應批評編碼人員。您永遠不會知道人們將如何對此做出反應，並且冒著破裂這種關係並被貼上“一無所知”的風險。模糊的批評或對現有代碼的批評也不起作用。他們幾乎沒有機會重構已經過測試並可能已部署的代碼。

您應該做的是朝著更好的實踐前進。乾淨的代碼是一件好事，在健康的開發環境中，應該有一個平台來建議改進代碼質量。通常，此平台是某種形式的代碼審查。開發人員可以互相學習很多，如果您的公司沒有針對這種對等協作的實踐，那麼促進這種協作就成為您的重點。您甚至可以採取這樣的方法，說您想建立代碼審查以向他們學習—您會的。

大三時，一切看起來都很混亂。喬爾·斯波斯基（Joel Spolsky）在文章中對此進行了詳細介紹。

“總是很混亂嗎？”我問。

“什麼？你在說什麼？”經理說。 “我們剛剛完成清潔工作。

好，到目前為止，我已經提到了作為程序員的三個成就水平：

1. 您不會

2. 您對清潔有一個膚淺的認識，主要是在符合編碼約定的水平上。

3. 您開始聞到表面下不整潔的微妙提示，它們使您煩惱不已，無法夠到並修復代碼。

ol>

不過，還有一個更高的級別我真正想談論的是：

1. 您故意以這樣的方式構造代碼，使您的鼻子變得不整潔，使您的代碼更有可能是正確的。
ol>

高級人員通常處於4級。代碼對您來說很骯髒，但對他們而言卻不是。只要它不導致錯誤，它是否臟都沒有關係。熟悉其代碼的人知道哪些部分對於保持清潔很重要，哪些部分可能很混亂。

請考慮編寫您所謂的“乾淨的代碼”可能不在您的高級同事優先級列表的頂部。而且“乾淨的代碼”也不是最重要的。

通常所謂的“乾淨代碼”實際上是被誤解了-盲從地堅持誤解的概念並不能改善任何事情。通常，它只是增加工作而沒有真正的好處，或者幾乎沒有好處。因此，一個風險就是告訴您為什麼您的觀點是錯誤的-顯然，這對您來說是一件好事。

我有一個案例，我寫了300行方法，有人抱怨說它太長了，於是我告訴他自己修復它。他的代碼幾乎全部都是簡單易懂的功能-其中一半的功能已損壞。只是沒有想到他的功能很長而且很複雜是有原因的。即使它的註釋非常好（例如，在這裡我們執行X來解決在執行Z時發生的錯誤Y，並丟棄相應的代碼）。當被問及為什麼他扔掉代碼時，他說“我聽不懂”（所以您為什麼不問我）或“我認為不需要”（所以您為什麼不閱讀註釋並嘗試一下） 。

因此請做好準備，讓高級開發人員實際上知道他們在做什麼，並且您所說的“還不錯”可能實際上是非常好的。

1. 您的公司是否認真對待代碼審查？就在昨天培訓一些新開發人員時，我強調要展示一個Bitbucket屏幕，其中一個相對初級的開發人員（4年）糾正了一個非常高級的開發人員（40年）。甚至有些來回。初級開發人員是完全正確的。如果代碼審查只是一種形式，那麼錯誤的代碼將被檢入，並且也將中斷。您認為您的團隊的產品是否穩定，或者代碼不僅編寫不當，還會導致在現場出現不良行為？ （錯誤答案，崩潰等）。
2. 公司是否設有代碼質量委員會？我對長期的書面標準並不感到興奮，因為我有時會理解例外的必要性（是的，在過去十年中我使用了 goto 。）但是它需要一支與您共享對此主題感興趣的團隊。加入它。
ol>

如果答案是該公司取消了代碼審查並且沒有贊助任何對質量問題感興趣的小組，則應與您的經理聯繫。那些是大紅旗。

這裡幾乎所有答案都是遵從者。他們告訴您要保持外交態度，不要與您的同事一起過分強調這個話題。大多數人會同意這一點，並會採取相應的行動，從而導致他們可以相處的代碼質量的平均（最差）協議。但是，（代碼）標准在這裡並不是沒有道理的，而是因為它們代表了自己，以提高可維護性，可讀性等。所有這些都是大多數開發人員都不關心的長期目標，因為他們不會感到負面。或它在編寫代碼時的積極影響。

絕不應因某種懶惰或呼籲權威而壓制更高的標準。如果在向“長輩”提出這個話題時，他們感到受到攻擊並採取了防禦措施，那麼您可能應該尋找一個可以實現自己標準的地方。畢竟，您是最有價值的東西：時間。可以在任何地方賺錢。時間是寶貴的-錯誤的代碼正在浪費您的時間。