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

類別: IT

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

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

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

程式碼審查 例一

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

程式碼審查 例二

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

程式碼審查 例三

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

程式碼審查 例四

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

程式碼審查 例五

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

程式碼審查 例六

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

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

如果程式碼審查時你忘記了拿近視眼鏡原文請看這裡

推薦文章