新聞中心
身處在一個卓越開明的開發(fā)團隊,你被安排了一整天的時間,什么都不干,只做代碼審查。然而,在活動開始兩小時前,你發(fā)現(xiàn)自己把近視眼鏡忘家里了,整個早上你看到的都是模糊的影像和顏色。你該怎么辦?

創(chuàng)新互聯(lián)服務項目包括七里河網(wǎng)站建設、七里河網(wǎng)站制作、七里河網(wǎng)頁制作以及七里河網(wǎng)絡營銷策劃等。多年來,我們專注于互聯(lián)網(wǎng)行業(yè),利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等,向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案,七里河網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前,我們服務的客戶以成都為中心已經(jīng)輻射到七里河省份的部分城市,未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任!
正確的做法是,回家取你的眼鏡,因為步行十分鐘就能到家,然后今天會跟往常一樣愉快的度過。但是,如果說,是你在早上準備離家上班時,發(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層。看起來你試圖在一個小小的地方里裝下太多的東西。你要么應該想想不要分那么多層(是的,我可以看到這里有兩個輔助類,應該放到它們自己的空間里,但如果把它放到其它地方會有不好嗎?),要么拆分一些代碼,放到自己的根空間下。
代碼審查 例五
非常詳細的注釋,佩服!這段代碼需要好幾個章節(jié)的文字來輔助理解,佩服!
代碼審查 例六
仔細看一下這第二個方法。如果一個方法需要8個參數(shù)才能讓它知道干什么事情、如何干事情,那么,這個 方法有點太累了。請重構它,從它的肩膀上消減一些負擔,拿走一些壓力。把它一分為二(或更多),或者,也許將一些參數(shù)當成類的初始化參數(shù),可能會更有意義些。這8個參數(shù)你會同時都用到嗎?所以,不要期望你的方法這樣。
所以,這就是當你忘了拿近視眼鏡、或直視太陽太久時做代碼審查的方法。如果你有豐富的編程經(jīng)驗,我相信你也能舉出很多有趣的例子。有人可能會反對,說這些只是一些小事情,還有很多更重要的事情需求考慮。然而,清爽、簡潔、良好格式的代碼是你需要的,如果你不去用心控制好你的代碼結構,它終究會給你帶來煩惱。
英文原文:
Code review without your glasses
譯文出自:http://www.vaikan.com/code-review-without-your-eyes/
網(wǎng)站題目:如果代碼審查時你忘記了拿近視眼鏡
URL鏈接:http://www.dlmjj.cn/article/dhjcopc.html


咨詢
建站咨詢
