今天在瀏覽網(wǎng)站的時候，看到別人發(fā)的這么一個帖子，剛剛入職一個新公司，代碼審查的時候，leader 對他的代碼進行了一些修改，而這個程序員感覺很多地方?jīng)]有必要，你們看完上面這個帖子什么感覺?

看法

我看的看法是：

一是，遇到這樣的領導真的很好，咱先不討論領導這樣的修改，有些地方是否有沒有必要，光看領導這么事無巨細的在這些小地方都幫你 code review 進行一些修改，就說明領導非常負責，領導的這些修改和你的哪個更規(guī)范?這個不好說，但是領導的修改我個人認為確實很規(guī)范，最起碼沒錯。

二是，我認為確實領導的一些修改沒有必要。就比如：上面的那個我畫紅框的地方，把 setVisible 換成了 show ，其實沒必要，但是我認為領導的那個更容易讓人看懂和辨識。還收上面的那個常量的命名，領導也給修改，其實確實也是沒必要的地方。

還有一個地方比如：a.do1() a.do2() ，領導給修改成 a.do1.do2()，或許沒必要，但是領導的這個修改可以讓代碼更簡潔，看起來更方便，在維護代碼和更新迭代上來講，確實讓你一眼就懂，很清楚，方便整個團隊工作的管理和交接。

想法

其實，作為一個團隊來講，首先看看整個團隊有沒有代碼規(guī)約和規(guī)范，里面是怎么規(guī)定這個變量，常量，方法函數(shù)的命名的，如果這個團隊里有代碼規(guī)約就是這么制定的命名規(guī)則，我們還是應該按照這個規(guī)則來命名。

你想想一下：

一個團隊的 leader 下面十幾個人，你是想讓領導適應十幾個人的風格，還是讓十幾個人統(tǒng)一到領導的風格?

代碼風格和規(guī)范統(tǒng)一了，才利于整個團隊代碼的維護和交接，有利于代碼的管理和升級。這就要求團隊必須有一個代碼規(guī)范。歡迎大家關注我的微信公眾號：非著名程序員

比如：上述程序員，不滿意領導的修改，你先看看團隊里有沒有代碼規(guī)范，代碼規(guī)范是對于命名是怎么規(guī)定呢?如果有，是你沒有按照規(guī)范來使用，那就是你的問題，如果沒有規(guī)范，那你可以找 leader 談一談，團隊應該制定一個規(guī)則，能否出個規(guī)則，以后我按照這個規(guī)約來寫，也可以減輕領導 code review 的工作量。(http://godcoder.me/)

代碼評審

為什么要進行代碼評審?

1. 提高質(zhì)量
2. 及早發(fā)現(xiàn)潛在缺陷與 BUG，降低事故成本。
3. 促進團隊內(nèi)部知識共享，提高團隊整體水平
4. 評審過程對于評審人員來說，也是一種思路重構的過程。幫助更多的人理解系統(tǒng)。

其實，我認為代碼評審，不僅僅是領導的事，每天抽出一個小時，團隊里每個人都對其他人的代碼進行評審也是非常好的，不僅可以找到各自身上寫代碼的缺陷和毛病，還可以學習別人寫代碼的優(yōu)點。畢竟評審過程對于評審人員來說，也是一種思路重構的過程。歡迎大家關注我的微信公眾號：非著名程序員

另外，整個團隊必須要有一個明確的代碼規(guī)范和規(guī)約的好處是，code review 應該是做重要的事，而不是花在這些不規(guī)則的命名上，命名的事，讓規(guī)約來約束大家，code review 最重要的是提高代碼的質(zhì)量，發(fā)現(xiàn)潛在缺陷與 BUG，尋找項目模塊中不合理的地方，比如：系統(tǒng)關鍵模塊，業(yè)務較復雜的模塊，缺陷率較高的模塊等。

***，我想說，截圖上的那個領導，確實水平很高，光從命名上來講，確實很規(guī)范，雖然可能有點較真和過了，但是確實值得學習。