如果代碼審查時你忘記了拿近視眼鏡
身處在一個卓越開明的開發(fā)團隊，你被安排了一整天的時間，什么都不干，只做代碼審查。然而，在活動開始兩小時前，你發(fā)現(xiàn)自己把近視眼鏡忘家里了，整個早上你看到的都是模糊的影像和顏色。你該怎么辦？
正確的做法是，回家取你的眼鏡，因為步行十分鐘就能到家，然后今天會跟往常一樣愉快的度過。但是，如果說，是你在早上準備離家上班時，發(fā)現(xiàn)一群兇猛好斗的大黃蜂在放眼鏡的抽屜里筑起了蜂巢，擋住了你拿眼鏡的途徑，而且它們看起來很不喜歡被打攪。那你怎么辦呢？
另一個正確的做法，很顯然，是假裝你帶了隱形眼鏡，免得讓自己很尷尬。而且你知道自己有不看任何代碼細節(jié)、只看大概就能說出很多讓人欽佩的意見的能力。
代碼審查 例一
我們都認可代碼責任應該絕對的分離。任何類都應該只做它自己職責范圍內(nèi)的事情。但是，你的這個 UserCreator很可能有點過了。如果這個 UserCreator對象只做這一點事，那其實Users 對象自己就應該創(chuàng)建自己。另外一點不好的是，創(chuàng)建一個簡單的Users，你還需要在成堆的小文件中找出它的創(chuàng)建者對象，不宜操作，也不宜理解。
代碼審查 例二
看看這些一大堆的方法函數(shù)，卻偽裝成一個類，我可以看到，從技術上講，這些方法都是在各自做自己的事情。雖然沒有任何的文字信息提示或暗示，我也能猜出你沒有很好的給這個類寫測試程序。如果給我一杯濃咖啡、一個下午時間，我想我可以分析出中間這20行的代碼是用來判斷應該給哪個用戶發(fā)送郵件，但我還是希望你將這部分代碼放到def users_to_send_emails_to函數(shù)里，免得我再去動腦子。
代碼審查 例三
很好，在這個類里，你的方法都非常的簡潔短小，這是一個進步。然而，你做的是有點過了。雖然Ruby解釋器并不在意你的代碼邏輯在每個只有一行的方法間來回跳躍，但人腦解釋器會在意。也許有人會喜歡上下翻屏看代碼，但如果換成我，讓我在手臂上記下哪個方法應該調(diào)用哪個方法，那我更喜歡將這些小方法組合到一起。
代碼審查 例四
可以看出，你非常關心這個類是否被放在了合適的命名空間里。非常好，使用命名空間是個好事。但在這個文件里，你嵌套了6層?？雌饋砟阍噲D在一個小小的地方里裝下太多的東西。你要么應該想想不要分那么多層(是的，我可以看到這里有兩個輔助類，應該放到它們自己的空間里，但如果把它放到其它地方會有不好嗎？)，要么拆分一些代碼，放到自己的根空間下。
代碼審查 例五
非常詳細的注釋，佩服！這段代碼需要好幾個章節(jié)的文字來輔助理解，佩服！
代碼審查 例六
仔細看一下這第二個方法。如果一個方法需要8個參數(shù)才能讓它知道干什么事情、如何干事情，那么，這個 方法有點太累了。請重構它，從它的肩膀上消減一些負擔，拿走一些壓力。把它一分為二(或更多)，或者，也許將一些參數(shù)當成類的初始化參數(shù)，可能會更有意義些。這8個參數(shù)你會同時都用到嗎？所以，不要期望你的方法這樣。
所以，這就是當你忘了拿近視眼鏡、或直視太陽太久時做代碼審查的方法。如果你有豐富的編程經(jīng)驗，我相信你也能舉出很多有趣的例子。有人可能會反對，說這些只是一些小事情，還有很多更重要的事情需求考慮。然而，清爽、簡潔、良好格式的代碼是你需要的，如果你不去用心控制好你的代碼結構，它終究會給你帶來煩惱。
