如果程式碼審查時你忘記了拿近視眼鏡

　　你身處在一個卓越開明的開發團隊，你被安排了一整天的時間，什麼都不幹，只做程式碼審查。然而，在活動開始兩小時前，你發現自己把近視眼鏡忘家裡了，整個早上你看到的都是模糊的影像和顏色。你該怎麼辦？

　　正確的做法是，回家取你的眼鏡，因為步行十分鐘就能到家，然後今天會跟往常一樣愉快的度過。但是，如果說，是你在早上準備離家上班時，發現一群凶猛好鬥的大黃蜂在放眼鏡的抽屜裡築起了蜂巢，擋住了你拿眼鏡的途徑，而且它們看起來很不喜歡被打攪。那你怎麼辦呢？

　　另一個正確的做法，很顯然，是假裝你帶了隱形眼鏡，免得讓自己很尷尬。而且你知道自己有不看任何程式碼細節、只看大概就能說出很多讓人欽佩的意見的能力。

　　程式碼審查 例一

　　我們都認可程式碼責任應該絕對的分離。任何類都應該只做它自己職責範圍內的事情。但是，你的這個 UserCreator很可能有點過了。如果這個 UserCreator物件只做這一點事，那其實Users 物件自己就應該建立自己。另外一點不好的是，建立一個簡單的Users，你還需要在成堆的小檔案中找出它的建立者物件，不宜操作，也不宜理解。

　　程式碼審查 例二

　　看看這些一大堆的方法函式，卻偽裝成一個類，我可以看到，從技術上講，這些方法都是在各自做自己的事情。雖然沒有任何的文字資訊提示或暗示，我也能猜出你沒有很好的給這個類寫測試程式。如果給我一杯濃咖啡、一個下午時間，我想我可以分析出中間這20行的程式碼是用來判斷應該給哪個使用者傳送郵件，但我還是希望你將這部分程式碼放到def users_to_send_emails_to函式裡，免得我再去動腦子。

　　程式碼審查 例三

　　很好，在這個類裡，你的方法都非常的簡潔短小，這是一個進步。然而，你做的是有點過了。雖然Ruby直譯器並不在意你的程式碼邏輯在每個只有一行的方法間來回跳躍，但人腦直譯器會在意。也許有人會喜歡上下翻屏看程式碼，但如果換成我，讓我在手臂上記下哪個方法應該呼叫哪個方法，那我更喜歡將這些小方法組合到一起。

　　程式碼審查 例四

　　可以看出，你非常關心這個類是否被放在了合適的名稱空間裡。非常好，使用名稱空間是個好事。但在這個檔案裡，你巢狀了6層。看起來你試圖在一個小小的地方里裝下太多的東西。你要麼應該想想不要分那麼多層(是的，我可以看到這裡有兩個輔助類，應該放到它們自己的空間裡，但如果把它放到其它地方會有不好嗎？)，要麼拆分一些程式碼，放到自己的根空間下。

　　程式碼審查 例五

　　非常詳細的註釋，佩服！這段程式碼需要好幾個章節的文字來輔助理解，佩服！

　　程式碼審查 例六

　　仔細看一下這第二個方法。如果一個方法需要8個引數才能讓它知道幹什麼事情、如何幹事情，那麼，這個 方法有點太累了。請重構它，從它的肩膀上消減一些負擔，拿走一些壓力。把它一分為二(或更多)，或者，也許將一些引數當成類的初始化引數，可能會更有意義些。這8個引數你會同時都用到嗎？所以，不要期望你的方法這樣。

　　所以，這就是當你忘了拿近視眼鏡、或直視太陽太久時做程式碼審查的方法。如果你有豐富的程式設計經驗，我相信你也能舉出很多有趣的例子。有人可能會反對，說這些只是一些小事情，還有很多更重要的事情需求考慮。然而，清爽、簡潔、良好格式的程式碼是你需要的，如果你不去用心控制好你的程式碼結構，它終究會給你帶來煩惱。

　　英文原文：Code review without your glasses