這個首先要恭喜你了。

因為通常的情況下，公司裡總是有寫程式碼爛的人和不爛的人。管理層為了均衡，也不太可能把不爛的和不爛的放一起。你發現了專案組裡寫程式碼爛的人，可以大機率證明，你在領導層眼裡是不爛的那一半。

你覺的隊友的程式碼特別爛，有一種可能是你自己寫的也挺亂，就極有可能被團隊裡其他成員認為爛。畢竟寫程式碼這個事情，沒有不爛，只有更不爛。所以呢，發現別人的時候也要自省，以免五十步笑百步。

每個人寫程式碼都是有風格的，也許風格迥異，但總有規律，鍛鍊一下閱讀爛程式碼的能力，其實也是一種很有價值的能力。其實程式設計師沒有那麼多的機會寫程式的，很多時候就是在讀那些爛程式碼。我們承認有好程式碼，但有時候我們覺得爛，也許是因為和我們自己的風格不一致罷了。

程式設計師在做專案的時候，無論遇到什麼，都要對自己微微一笑，樂觀笑納一切窘境，只因為我們是程式設計師。影響他人，從接受他人開始。

由於每家企業裡面程式設計師的水平不是很一致，如果遇到同伴寫的程式碼特別爛也是很正常的事情，畢竟每個程式設計師早期寫的程式碼本身就存在很大的漏洞，每個人都是從程式設計小白一步一步走過來的，如果在現實場景中遇到這種情況從專案的角度考慮，如果自身屬於專案管理者可以直接調配下資源，儘量讓水平不到位做一些力所能及的事情，儘量不耽誤整個專案的整體進度，可以做些簡單的模組或者做點單元測試的工作，可以輔助技術層次高的人做一些打雜的工作，本身初級的程式設計師都是從打雜看文件一步步入手的。

如果是被安排著和程式碼能力不強的人一起做專案，如果不是不是緊密聯絡的模組，可以適當給與輔助，畢竟如果有一個模組出現問題，對整個專案都會有一定的影響，不是自己的模組做好了就能把整個專案完整的完成，所以如果有機會還是要多交流減少這種錯誤的發生，在合適的機會討論出有效的解決方案，畢竟還是從大局為重。

第一程式設計師首先要具備紮實的基本功。程式碼能力是基本功的一種表現，程式碼寫的不好首先從基本功上就存在很大的問題，所以最簡單直接的方式就是把基本功重新塑造一遍，這樣子再次寫程式碼的時候才能三思而後行不至於由著自己性子去信馬由韁的去完成程式碼，所以要把對應的程式語言基礎語法重新溫習一遍，拿出一定的時間對基礎進行回爐，對解決程式碼質量問題還是有很大的幫助。

第二程式設計師要掌握一定的程式設計思想。要把掌握的實際程式設計基礎融匯到實際的程式設計場景中去，在具備的程式設計場景中歸納出真正意義上的程式設計思想，當然這種思想的提煉是需要真正意義上的專案經驗，在第一次接觸實際專案的時候就要勤于歸納，把掌握的理論只是融入到實際的程式設計工程中，這個經驗的掌握需要真正意義上的專案實戰，需要真正意義上面對實際的產品或者客戶的需求。

第三程式設計師儘可能多接觸專案實戰，對於程式設計師來講最直接的體現價值的地方就是專案經驗了，擁有相關的專案經驗就能很快投入到實戰開發過程中，所以如果對口就容易高的薪資水平，專案經驗和實際解決問題的能力是程式設計師最值錢的地方。

關於程式碼寫的特別爛這件事，其實，你應該有一個好的心態，為什麼？因為從側面反應了一個問題：那就是你的水平比他高。所以，挺好的。

另外，誰都有從初級程式設計師做起來的過程，我們一開始可能也這樣，也經常寫的程式碼很爛，但是，經過鍛鍊，我們都成長了。所以，只要問題不是特別大，程式碼爛點就爛點，但是程式碼爛，並不意味著就是寫 bug 。bug 和程式碼爛是兩回事，這個我們得分清楚。

另外，既然你跟他負責寫同一個專案，那麼你們就是一個團隊，應該反思一下，寫程式碼的時候，你們團隊或者公司層面，有沒有相關的程式碼規範呢？或者在開始寫程式碼之前應該制定一個程式碼規範，大家儘量都按照規範上規定的方式去寫程式碼，這樣整個專案的程式碼看起來會統一很多，你自己去看同事寫的程式碼的時候也不費力。

所以，我認為，你們專案組應該制定一個規範，這樣才可以。

那麼我看回答的答案中，有人提到了一個非常好的角度，就是從公司安排管理的角度講的。說：同一個專案當中，公司會均勻搭配的，一個能力好的，會帶一個能力差的一起負責。既然，你看他程式碼寫的爛，說明你是那個能力強的人。也說明公司知道你能力比他強，所以讓你倆搭配。

說實話，這個角度說的有一定道理，只是有一定的道理。從管理的角度上來講，確實是這麼回事。如果從這個件角度上來講，你應該感覺很慶幸，不錯，起碼贏得了公司的信任。

對專案本身來總結：

1. 逃避，不可取；追求優秀程式碼，或許可以成為更優秀的 leader，但是堅持改善程式碼也有著其他可能，並不是毫無價值；不應該只看到一種出路；

2. 對優秀程式碼有追求是值得肯定的，但是也要學會接受不優雅的程式碼，並反思其價值（對專案、對管理者、對開發者），不應該一味排斥；

3. 菜，是原罪，提高自身水平才是硬道理；這樣，才能從根本上解決“追求優雅程式碼的渴望和自身技術水平”之間的矛盾。

4.有能力指導他人是一件非常光榮，而又神聖的事情！所以要相互學習，取長補短！

一個人完成的具有臭味的程式碼，後期維護消耗的人力成本遠大於2個人。這種情況，要麼走，要麼幫，不這樣的話，他即便被辭退了，後面的苦頭也是無止境的。敏捷開發裡有個實踐叫雙人程式設計，兩個人幹一件事，千萬不要覺得這是浪費資源，很多時候，不知道自己爛的原因是沒見過好的。見到好的後，會潛移默化的影響思想。

ps：有時候我們認為的爛，不一定是爛，只是習慣不同。有人覺得一行完成5行的內容更簡約。有人覺得5行完成1行的內容更可讀。相互溝通，學習。

程式碼爛不爛有時候每個人都有每個人看法和想法。優先看同事有沒遵守基本的編碼規範。如果公司有這方面的規範，可以拿規範跟這位同事說程式碼。這樣他會比較容易接受！另外在和同事指出程式碼問題時候最好以討論的口吻去跟這位同事討論！不要直接說你的程式碼怎麼怎麼不好。大家是同事，互相學習交流比較有益公司發展！

作為一個不資深的程式設計師，我覺得很正常，在我剛寫程式碼的時候，拿到需求，第一時間就是想著怎麼把它實現，而沒有去考慮它的拓展性，相容性，語法簡練等等其他的因素，以致等過段時間在過回頭來看自己的程式碼的時候，腦海不由得蹦出"我嚓，當初寫的啥哦，稀爛的，"不忍直視[捂臉][捂臉]

每個人的經驗和新技術的運用參差不齊，一個邏輯，高手可能只需幾行程式碼或者運用最新的第三方庫等途徑，替換掉你滿屏的if else,

所以我認為一個人覺得別人程式碼寫的爛，那他自己應該是個比較追求完美的人。

遇到這種情況，要淡定，沒啥大驚小怪的[呲牙][呲牙][呲牙]

任務分配，各管一段；

編碼、測試，專職專位；

相關情況，上級彙報；

上級重視，換人崗兌；

上級輕視，跳槽準備；

騎馬找馬，準備做好！

【與職場遇到豬隊友的網友們共勉】

二零一九年十二月十四日

我是後端的程式猿一枚，最近我們公司就有，可以分享一下

我們公司上段時間來了個後端，說是兩年工作經驗，經過兩天的相處，可以輕易的發現肯定沒有這麼久的工作經驗，一些基本的增刪改查都做不好，連表都不會建

有次我給他分配任務，一個小時就可以完成的任務，做了一天也沒出來，還出現好多錯誤，我看了他的程式碼，寫的亂七八槽，直接回滾了程式碼

和程式碼寫的很爛的同事一起做專案真的很難受，還不如自己做

一起合作做事的人，水平良莠不齊，有特別厲害的，也有比較弱的。特別牛的先不說了(注意，是他自己覺得自己特別牛)。先說比較弱的。

其實一起做事的，只要不是瞎搞，總會有所創造的。或多或少吧。一般專案的程式碼公共的部分如果不是授權是不能亂改的。就是說，底線是不能影響別人工作。如果能做到這點，應該不會有多大問題，至於他以後能不能繼續留下來，那是專案管理的負責的。咱做好自己的事情即可。累。不多說了。

這個問題，不同的人、不同的角色、不同的經歷，會有不同的感受和答案，我以小人之心、妒君子之腹，嘗試分析可能的答案。

（1）如果你和同事間有師徒關係，或前輩與晚輩的關係，指出其不足一般是不會有問題的，後輩還會感謝你的指導。

（2）如果你和同事是同級別、同資歷，不管多麼委婉指出別人程式碼寫的不好，有造成同事間不悅的可能。在程式設計師間也存在一點“文人相輕”的現象，說不定人家也是這麼認為你的（早就心裡嘀咕你程式碼寫的爛）。所以在認為別人程式碼寫的爛的時候，要審視一下自己是不是因為自己“瞧不起”別人的能力，如果是這樣確實是不應該。有這種思想也不要有負罪感，時間會人讓成熟，“文人相輕”的思想會減弱。

如果你是有實權的專案負責人、團隊負責人，最好是透過制度、流程來控制程式碼質量，使用“質量標準”、”程式碼規範”等統一編碼規範，然後透過實際測試結果來暴露程式碼質量問題。在制度和測試資料面前，程式碼真正寫的爛的員工也無話可說，而且會自覺的修改和提高，因為在制度裡同樣有著明確的懲罰措施。在適當時候，使用“領導權威”讓員工更高效地修改和提高。

如果你的同伴和你是同級別的同事關係，一般而來說專案中程式開發是有分工的，別人的程式碼別人寫，別人的Bug別人De，程式碼質量的好壞是有上級領導、測試人員等檢驗的。工作了多年的老油條應該不會為別人操碎心的，但是同事間的相互幫助是必要的。

程式設計師有追求完美的心是對的，也有助於自己能力的提高。但是，在指出別人不足時，也要多想一想“我的能力水平能否準確判斷別人程式碼是不是真的寫的爛？”、“團隊的氛圍和同事的性格是否能夠接受直接指出其程式碼寫的爛？”、“別人程式碼寫的爛是否有制度流程來檢查？”、“別人程式碼寫的爛對我的影響有多大？還是因為我的強迫症看不慣？”、“出現這個問題的原因是什麼？需求變態？時間太緊？”、“在什麼樣的場合指正別人的不足最合適？”等等問題。

我不是嚴格意義的程式設計師，是程式愛好者，還沒有遇到這個問題，在此站著說話不腰疼，如果大家有好的答案、好的選擇，請給題主多多建議。

說說我的個人一點看法，

”專案組其他同伴程式碼寫的亂，我該怎麼辦？”這個問題看似是一個技術問題，實際上是一個人際關係問題。

取決於你的做法，你可以和平的解決這個問題。或者，你也可以逼迫他採用你的做法。你可以給他發一封憤怒的郵件，撤銷他提交的程式碼，在code review的時候把他的程式碼批的體無完膚，事事和他作對。但是這樣做，不僅會激怒他，還會影響團隊中每一個人的進度。

簡單說，如果沒有良好的溝通，你無法改變對方的習慣。因此，無論你打算走哪條路，你都要明白，這是一個需要你進行說服對方的人際關係問題，而不僅僅是一個技術問題。

個人感覺框架很重要。

如果是面向物件的語言，一定要充分發揮類的優勢，做好框架的搭建，讓同伴儘可能的只負責自己模組的同時不會影響到自己。最重要的是，他的模組出了問題時自己不會背黑鍋。

一個好的框架，不會因為參與專案人的多少而影響專案整體。

提示一下他。因為很多人寫程式碼有自己的風格。可能他沒有意識到，所以你可以跟他溝通一下，這樣子，也可以讓他的編碼習慣得到改善，反正，技術嘛，都是透過溝通然後不斷進步，改進的。

作為一名從業多年的IT人，我來回答一下這個問題。

對於程式設計師來說，遇到對程式碼質量不太關注的程式設計師是比較常見的事情，之所以程式碼質量不高，一方面原因是自身不太關注於程式碼的整體管理，另一方面原因是經驗不足。實際上，很多團隊在做review的時候，針對於程式碼質量的定義也有不同的標準，這也會導致很多新成員在加入專案組的初期，會出現程式碼風格不統一的情況。

按照歷史經驗來看，程式碼質量差有多種不同的情況，一種是程式碼本身不規範，但是效能和功能是沒用問題的，還有一種情況是，程式碼不僅不規範，程式碼的重複率也很高（抽象程度不夠），這種情況就是一個比較大的隱患，未來可能會有較多的bug陸續暴露出來。我曾經遇到過一個iOS程式設計師，在每次版本迭代的時候，他的程式碼就一定會出現問題，這就說明他的程式碼存在很多問題，這也比較影響產品的整體迭代週期。

要想解決程式碼比較亂的問題，除了團隊做定期的review之外，還有一個辦法就是做程式碼互測，這種辦法是比較高效的，也是不少團隊經常採用的方案。程式碼互測通常在兩至三人之間展開，這樣能夠儘快形成一個統一的程式碼標準，從而提升程式碼的可維護性。程式碼互測還有一個比較好的優勢，那就是可以讓程式碼質量較差的程式設計師，能夠迅速得到成長。所以，如果感覺團隊成員的程式碼質量太差，可以邀請他跟你做程式碼互測。

最後，隨著目前開發環境逐漸向雲計算平臺遷移，程式碼質量的管理也有了更多的方案，基於微介面的程式設計方式，也能夠在很大程式上避免一些基礎性的程式碼問題。

程式設計師每次在做一個大型專案時，肯定是和別人一起合作開發完成這個專案，每個人負責一個功能模組的程式碼開發。有時候難免會遇到這種情況，某個同學的程式碼寫的不好。如果你和他關係非常好的話，你可以給他提出一些程式碼改進的建議。如果你和他的關係僅是同事關係的話，我覺得可以先從自己做起，把自己的程式碼寫的非常的優雅整潔。以後他在看到你的程式碼時，其實也會受到你的影響，向你對齊。

當然，如果這種方式行不通的話，我覺得可以向你的 leader 進行反饋和建議，當然反饋的內容不是說某個同學程式碼寫的不好，而是說要加強團隊的專案程式碼的編寫規範。

一個好的程式碼，對專案、團隊以及個人都有利。其實程式碼不僅僅是給個人看的，最主要還是給其他人看的，因來未來你在離職以後，當你的程式碼交給新人來維護時，好的程式碼其實能夠減少他的運維難度。同時，如果未來程式碼有 bug 時，好的程式碼能夠加快我們對 bug 的定位以及修復。

團隊其他同學的程式碼寫的不太好，一個原因可能是因為平時寫程式碼寫的過少，另外一個原因可能是還沒有形成良好的個人程式碼規範，只想著快速完成業務的需求。這種情況其實在新人裡面可以經常看到，新人可能想快速的達到結果，而忽視了程式碼的質量。

所以一個好的團隊，一定要有好的程式碼規範和約束，比如每週的團隊程式碼 review，或者每次程式碼提交時，都要有一個人 review 之後才能提交。可以給新人推薦一些程式碼方面的書籍，比如《程式碼整潔之道》，讓團隊每個人養成習慣就好。

我之前在公司的時候，公司有時候會舉辦曬程式碼比賽。有很多技術經驗非常豐富的程式設計師，會來審查參賽同學的程式碼。從程式碼的健壯性以及邏輯實現方面，最終會評選出一個優質程式碼獎項，同時會向全公司表揚。如果一個網際網路公司是技術型公司，我覺得公司層面也應該鼓勵良好的程式碼設計，去向開發同學多宣傳這樣的一個思想。

最後，我覺得好的程式碼還是應該從個人做起。自己的把寫的每行程式碼都寫的非常整潔，同時邏輯非常的清晰明瞭，讓大家一看就知道是實現什麼功能。漸漸地，你的程式碼其實也會影響到其他的開發同學。他們在看到你好的程式碼設計的時候，或多或少也會和自己的程式碼進行比較。你程式碼的一些優點也會幫助他們審查自己的程式碼，希望每個程式設計師都能夠養成好的程式碼程式設計習慣。

管好自己就行，一起合作開發專案，一般都是各自負責一個模組，最後在整合測試。自己的弄好了，可以適當幫忙下，但別主動，上面有管理人員會說的。