先說明一點，對於“我同事代碼寫的亂怎麼辦？”這個問題，每個企業和機構的態度都不太一樣。
例如，有的企業可能會幫你和那個開發者進行溝通。但是也有的企業，其態度會是：“不管你喜歡還是不喜歡，你所抱怨的那個開發者就是公司的高級開發者。”在這種情況下，你可能會覺得自己很無助。
因此，我需要事先說明，我的這些建議，可能在你所在的公司內並不適用。
用數據說話
那個同事寫的代碼讓你忍無可忍，格式混亂，難以閱讀。他的代碼讓你在心理和身體兩方麵都感到惡心。你甚至覺得，他這麼寫代碼，就是為了針對你。
盡管你討厭他寫的代碼，但是你確定他的代碼真的不好嗎？你說他的代碼亂，有什麼證據嗎？你憑什麼說他的代碼寫的亂？你是否將他的入口點和出口別人之前做一點功課，用數據說話，給你的觀點拿出論據。
問問自己：“我算什麼啊？”
為什麼要問自己這個問題？因為公司裏的其他人會這麼想。沒錯，你拿出了證據，證明了那個人寫的代碼太亂。但是這就夠了嗎？
有這樣一種可能：你所指責的那個人，他可是公司的元老！他是公司第一個開發者，他加入公司的時候，電子郵件還沒出現呢，他們之間還用信鴿通信呢。公司第一版的軟件就是他憑借一己之力寫出來的。你能跟這樣的人叫板嗎？
我沒開玩笑，這個問題很重要。你需要考慮一下自己的角色。如果在團隊中，你扮演的是領導人或是導師的角色，而對方是一個新員工，你直接指出他的問題，這樣不會有大的差錯。但是如果你是團隊中的新成員，或是初級工程師，這樣說團隊中的元老，你的好日子也就到頭了。
你一定回想，在事實和正義麵前，角色的差異並不重要。老實說，這也是我的信仰。但是我猜如果你這麼做了，公司的HR一定會好好和你“談一談”。
“以下犯上”會讓你陷入被動的局麵——即使你說的是對的。如果你一定要挑戰一下，一切後果請自負。最好的結果就是，即使你勝利了，也是一場“慘勝”。
提供替代方案和結果
假設你拿出了足夠的證據，對方也接受了你的看法。團隊內的其他人也沒有提出異議。
但是如果你沒有給出替代的方案，人們依然不會完全接受你的意見。假設有一個人向你走過來說：“我做了很多研究，發現你的代碼寫的太亂。”然後轉身走開，你會怎麼想？因此，你需要在提出問題之後，給出相應的解決方案。
除了替代方案之外，你還要想對方證明你所提出的方案能夠產生更好的結果。例如，你可以在團隊中找一個你們兩個之間的對話方式，應該是探討一個問題的兩個平等的同事。
總結
在文章的開頭，我談到了這個問題，但是我還是想要重申一下。“同事代碼寫的亂，我該怎麼辦？”這個問題看似是一個技術問題，實際上是一個人際關係問題。
取決於你的做法，你可以和平的解決這個問題。或者，你也可以逼迫他采用你的做法。你可以給他發一封憤怒的郵件，撤銷他提交的代碼，在code review的時候把他的代碼批的體無完膚，事事和他作對。但是這樣做，不僅會激怒他，還會影響團隊中每一個人的進度。