在軟件開發中，代碼評審是一個關鍵的流程。
一個團隊，代碼評審開展的好，可以大不度的提升團隊整體的交付質量，同時團隊內的成員也可以很好的提升能力。
另一個方面，如果評審走歪了，代碼評審可能就變成了大型踩踏的事故現場，彼此互相攻擊，破壞信任等。
下面是如何搞砸一次代碼評審，來爲你樹立敵人的7個招數：
1、代碼風格的反饋
在代碼評審中，對毫無戒心同事發起攻擊，最好招式就是：不斷指出其不符合編碼規範的問題。
大多數公司內都有編碼規範的文檔，好好學習和利用吧。然後開始要求沒有明確的提及的修改。如果代碼規範中沒有提到什麼，那麼這就是一個完美的機會，可以要求進行無意義的修改，這樣就會給你要攻擊的目標帶來很多無意義的工作，譬如：
- 對單元測試類中的方法進行正確的類型提示了嗎？
- 方法上沒有添加void的標識了嗎？
- 變量的命名是否過於冗長呢？
- 等等。
使用編碼規範，來不斷的折磨你的同伴吧。
2、要求做無意義的變更
第一步很煩人，但不會讓你的敵人心生怨恨。你的繼續努力，接下來就是毫無意義的變更要求。
如果有兩種方法來做一件事，要求他們必須按照你的方式來修改代碼，不接受那些對你不利而對他有利的理由。
你需要長篇大論的寫反饋建議，來捍衛你所謂的正確。
如果你不想寫太多解釋性的東西，那你也可以用這樣的說辭，讓他們覺得自己不合理：
我不知道你爲什麼對我的這個要求如此難以接受呢，這樣做是正確的，是對你好的，請按照我說的來，謝謝。
讓你的同事，每天花大量時間來重寫那些工作的很好的代碼，是不是很爽呢。
3、長時間的拖延
給出評審反饋的時候不要着急。收到評審請求，在24小時，甚至48小時候，再來做評審的事情吧。當收到催促挑戰時，就聲稱自己忙於其他事情啦。
這樣做的目標是讓他的PR變味。未能及時關閉的拉去分支會被認爲是技術債務，需要付出額外的工作來做維護。這是一項非常煩人乏味的工作。所以儘可能的拖延每個分支的持續時間，來增加你攻擊目標同事的版本合併過程中，解決衝突的風險和時間吧。
如果你的攻擊目標，沒有在每一版本分支拉去前，處理過2-3次的合併衝突，那你的速度就太快了，有很多的進步空間。
4、要求增加bug
要求增加變更，是增加工作量的一種很好的方式。而要求做出變更並帶來bug的負面影響，這也是增加工作量的一種方式。
你攻擊的對手們，一面需要努力的做出變更，然後再變更後發現了新的bug，一面還要費力的去花時間修復新增的bug，是不是很有成就感呢。
5、評審請求中只有代碼規範的變更
你讓你的敵人審查的每一次變更中，都至少應該包含有50%以上的非關鍵功能性的、不必要的代碼樣式上的調整。
儘可能不在請求說明關鍵的變更有哪些，讓你的敵人們自己去猜吧，讓他們盲目的去浪費時間來處理你的評審吧。
6、創建超大範圍的評審
當在幾十行代碼上做評審，是非常容易的。但你想要的不是容易和簡單，而是希望你的敵人們在收到你的評審請求是感到恐懼：讓你的評審中，至少包含10幾個文件，1000行以上的代碼吧。
對這類的分支請求，也需要快速的處理，他們是技術債務，你可自己去合併解決代碼衝突。所以要不斷騷擾和催促每一個人，以快速的完成你分支的合併。
同時，也不接受任何人關於你負責分支版本反應慢的反饋，讓他們知道你版本的重要性。
7、忽視他人的反饋
在代碼評審期間，一直要強調這點：忽視他人的反饋，因爲他們是在報復你。
在代碼評審中，避免任何負面反饋造成影響最好的一個辦法:忽視一切的反饋。
有人給出來了需要做出更改的反饋嗎？ 忽視他吧，找關係搞定版本的合併，而不是去費力的修復它。
不喜歡任何人用有效的反饋來增加你的工作量，讓他們像鴨子背上的水珠，從你的分支版本上滑下來。
寫在最後
讓上面這些行動，不斷的重複，重複，再重複。
持續幾個月，你的敵人們就會後悔對你的輕視的。
如果你想讓你的敵人們喜歡上代碼，你不應該做的事情：
- 將你的代碼風格自動化，使其能夠自動處理；
- 只有比現有版本更好的方案時，纔會安排變更請求；
- 快速相應拉去請求，並每天安排時間進行代碼評審；
- 當請求變更時，確保所有的變更都進行了測試；
- 但你使用了新的編碼風格後，安排單獨的請求；
- 爲代碼評審創建小而頻繁的拉去請求；
- 迴應所有的反饋，要麼同意，要麼陳述你不同意的原因。
原文：
http://repohealth.io/blog/code-review-how-to-make-enemies/