Categories
程式開發

Code Review 是一場苦澀但有意思的修行


前言

最近 CodeReview(以下簡稱CR )心態相當的平和,代碼是一個講道理的東西,是就是,否就否。在 CR 時,溝通特別輕鬆,問題討論也特別聚焦,因為它是量化和定向的。 CR 的過程不是恃強凌弱,也不是一言堂,大家看著代碼,當作是一種靈魂的交流,那麼每一次的 CR 也是同事間提升和諧度的一種方式。優良的 CR 傳統可以體現團隊溫度,體現高年級同學傳幫帶的技術文化。平時,大家抬頭看 PRD ,低頭寫代碼,很少有時間靜心氣閒地交流一下業務流程、業務邏輯、業務未來擴展,在 CR 時,往往可以反復被討論到。一個人的能力不是體現在解決了問題上,也不是發現了問題,而是利用某種手段預知問題並解決問題。曾經有段代碼,我覺得取反邏輯生澀難懂,反復修改之後,發現寫代碼的小伙伴是錯誤領會了業務意圖。

提陞技術質量、促進人才成長、培養技術情懷這些口號我們今天先放一邊,聊聊最近CR的切身體會。 CR 不是互相看天書,而是產生天天看書的感覺,每一段寫得好,寫得不好的代碼都是一本書,好的代碼希望見賢思齊,差的代碼希望見不賢而內自省也。總之, CR 是一種修行,也是一種自我積累,苦澀的是看到慘不忍堵的代碼,心裡說:我去!有意思的是看到優雅的代碼,心裡也說:我去!

業務跑得這麼快,沒時間 Code Review

這是一個很大的謊言,不要為自己的醜代碼找華麗的藉口,沒有時間好好 CR ,總有時間焦頭爛額地處理故障和投訴。

Code Review 是一場苦澀但有意思的修行 1

Photo @ Djim Loic

時間老人是公平的,我一直認為某個同學在工位上劈裡啪啦打字,就是說明他幹活快,通過團隊打字比賽,發現其中 20% 在按 BACKSPACE 鍵。業務跑得快,代碼寫得快,可能寫的是一堆沒有營養甚至是有毒的代碼。我們需要追求的是 CR 的效能,而不是逃避 CR 。 CR 是一種修行,對於雙方都是一樣的收穫,因為如果想像成一個攤派任務,抵觸情緒總會油然而生。業務跑得快,也得兩腿是健康的, CR 就是保證業務持續跑的快的一個小醫生,不正常的業務節奏對公司的中長遠發展肯定是弊大於利。

代碼是講道理的

我認為靠燒香來保佑代碼不出問題時,保平安往往也是暫時的。優秀的代碼,就是在小流量、單線程沒有問題,在高流量、高並發時還是沒有問題,你的限流,你的容災,你的降級各種導彈防禦系統一樣自動打開並正確地發揮價值。很多人的思維覺得,代碼只要在場景和邏輯上沒有問題就行,那是因為夜路走得不夠多,還沒有碰到鬼。代碼是講道理的,就像有一個同學說>=比>更加慢,那隻是我們的潛意識猜測,經過深達編譯層的分析,發現兩個指令幾乎是完全一樣。其實憑我們的想像,那也是一個位運算級別的操作,從左向右比,如果一處有 1 ,另一個沒有 1 ,那麼前者一定是更大。沒有無緣無故的愛,沒有無緣無故的恨,一切的故障總是代碼的字裡行間。我們需要做的,就是讀懂她,用好她,寫好她。如果代碼任性闖禍,只能是我們不懂代碼的心思。

Code Review 是一場苦澀但有意思的修行 2

Photo @ Hitesh Choudhary

每一行代碼的存在是有意義的

更加嚴格地說,每一個字符的存在都應該是有意義的。如果某行代碼的存在完全是可有可無的,這個時候,我們考慮過 JVM 的感受嗎?憑白無故地要編譯這些字節碼,然後棧進棧出的忙活一陣子,然後告訴它,你的勞動是沒有任何價值的。比如,Boolean assetFlag = Boolean.true ; 這裡都已經明確地給給出來顯示的初始值,可是在調用端,居然還有這樣的判斷:if ( assetFlag != null && assetFlag == true) {…},什麼情況下為null 值啊?另外參數在框架裡已經做了值的判斷,那麼下邊又是 n 行,對所有參數重新判斷一遍,是對我們的代碼有多少不自信,還是對框架不自信?每一行的代碼,相當於生命,它的存在一定是有意義的,一定是能夠被執行到並且能夠為實際的業務負責的。

我們比拼的不是代碼行數

在Code Review 過程中,發現有些方法,重複用到一段邏輯,這段邏輯如果不抽取出來成為一個方法,未來的修改就成了一個必須多點全部修改的大坑,稍有不慎,容易遺漏。重複代碼在提交行數上,似乎挺壯觀的。如果在同樣的效果上, 3 行代碼能夠實現功能的價值,就不應該用 4 行來實現。我們經常說曬出代碼行數,並非是單純地鼓勵代碼行數多,而是提倡大家去寫代碼,寫優質的代碼,優質的代碼一定是少即是多的原則。代碼的實現,不要像魯迅先生說的一樣:懶婆娘的裹腳布又臭又長。

用戶視角的成功與失敗

在交付時,調用服務失敗,然後返回前台一個空列表,那麼前端業務的展示是後台數據正常,這個人不擁有數據列表,這明明是對數據的一種曲解。所以,後台調用服務失敗,就應該明確告訴前台,服務出錯了,這個用戶有沒有數據。系統出錯的信息給用戶看,合適嗎?不合適。前後端的用戶交界面上,往往飛著兩類信息:錯誤碼、錯誤信息。這樣夠了嗎?用戶提示需要額外地再給出來,往往根據不同的錯誤碼,有不同的用戶提示,可能是一個多對多的關係。多個錯誤碼,提示給用戶的信息:請輸入必填項。多個用戶信息,可能也對應一個錯誤碼。一般來說後台承包這三者的聯動關係, json 串推送給前端時,前端拿來主義即可。

有重複使用的量一定要找個地方集中隔離

不管是變量,還是常量,工具類,如果是多個地方同時用到,那麼如果硬編碼在代碼或者沉澱在包裡,未來一定是一個災難。比如,一個組裝 SQL 語句的代碼,到處都是 “from” “where” “limit” ,都是這類語句直接寫死在代碼中,注意問題來了,這些單詞前後都需要加空格。有時候在復制粘粘時,發現少了一個空格,出現的問題,往往是致命的。再比如,一個互相約定的分隔符 “###” ,定義在本類中 private String ,這明顯是兩個共同遵守的常量,單獨定義的結果就是容易造成不匹配。隔離的目的是複用它,保護程序地正常運行,易於維護。

單測沒必要代碼 Code Review

單測有時候感覺像是闌尾,有或沒有感覺都是無關緊急,這是錯誤的觀點。單測感覺就是一個任務。你寫單測了嗎?寫了。單測是否需要 MOCK ,是否進行邊界值測試,是否用例覆蓋到業務場景,這都也是 CR 的一部分。單測寫得好, BUG 肯定少。

需要調試來查找錯誤時,往往是一種對異常處理機制的侮辱

良好的日誌和異常機制,是不應該出現調試的。打日誌和拋異常,一定要把上下文給出來,否則,等於在毀滅命案現場,把後邊處理問題的人,往歪路上帶。別人傳一個參數進來,發現是 null ,立馬拋出來一個參數異常提示,然後也不返回哪一個參數是 null ,這在調用參數很多的情況下,簡直就是字謎遊戲一樣。到底是拋異常,還是拋錯誤碼?我不管拋什麼,反正錯了什麼東西,都應該透明出來。到底是拋受檢異常,還是非受檢異常,我只想說,沒有充足的理由,不要亂拋受檢異常。異常拋出時,一定要自己消化干淨,告訴別人說我的方法簽名拋的是 AbcException ,實際運行中,代碼某個地方直接拋出 EfgException ,這也是不負責任的。

多個 return 的語句,概率高的一定先進行判定

if(condition1) return; if(condition2) return; if(condition3) return ; 那麼需要評估一下condition1/2/3 出現概率的大小,概念大的在最前邊,盡可能快地進行return ,不需要進行後續無謂的匹配。不要總覺得計算機跑得快,不差這點蠅頭小利的,這種思維,和《南轅北轍》裡的寓義一樣的嗎?

吝嗇空行

感覺空行是廉價的,到處亂扔是一種;另一種是感覺空行是昂貴的,捨不得用,這種情況更多見。 50 行代碼沒有一個空行,就像英語 50 句話,沒有任何標點符號一樣。既然標點符號起到隔斷和語義區分作用,我們的空行不是同一個道理嗎?在以下情形:

1、在方法的 return、break、continue、這樣斷開性語句後必須是空行。

2、在不同語義塊之間。

3、循環之前和之後一般有空行。另外,方法和類定義下方就不需要空行了吧。

命名太隨意

代碼有兩件事情比較頭疼:命名和循環。人如其名,如果不是它幹的活,名字卻是一副道貌岸然,太容易把人帶偏了,一個中國人如果取名叫趙C,一個女孩子如果取名叫石敢當,第一印像生生地給扭曲了。英語不好的同學,要么用錯英文單詞,要么翻詞典,整出一個專八的詞彙,任何人都不認得這個單詞,在 CR 時,還需要打開在線翻譯時的命名,絕對不是好命名。當然如果在線翻譯都翻不出來的時候,那更頭疼。如果表意錯誤,那更要命。

Code Review 是一場苦澀但有意思的修行 3

Photo @ Jon Tyson

註釋是電影的旁白

電影的旁白:1)信息量大。 2)適時出現。就像 star war 裡,開始的一段一樣,如果不交代那些背景,可能進入正片是一臉懵逼的。在代碼上不需要寫正確的廢話,名字取得好,自然是自解釋的。在嵌套循環中,或者在復雜條件分支中,往往是需要講明白的。

另外,添加業務背景信息,以及執行頻率,執行條件,甚至維護者註意點,都是註釋的重要理由。識別到哪裡要寫註釋,也是一個對業務的閱讀能力,而不是代碼閱讀能力。

滿天飛的函數式編程好嗎?

答案是:不好。如果一個 stream 後邊的調用超過 5 個,我覺得你是為了炫耀,因為別人不敢改這段代碼,體現出來你的不可替代性。這種 10 行都是函數式編程的方式,就像讓人在水里憋氣超過 10 分鐘不能換氣一樣難受,有點缺氧的感覺。如下圖,反對這種直接 return 一個長鏈路的處理結果:

Code Review 是一場苦澀但有意思的修行 4

作者介紹

孤盡,《阿里巴巴Java開發手冊》和《碼出高效》作者。

本文轉載自公眾號阿里巴巴中間件(ID:Aliware_2018)。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzU4NzU0MDIzOQ==&mid=2247489170&idx=1&sn=e47dcf2227517172ff97105e8a0543d0&chksm=fdeb24f2ca9cade4985b11abd05d4c8e2fdf2cf9b5a73dbe27d320a036d684563679e8d5c565&scene=27#wechat_redirect