敏捷開發:程式碼Review
熱情高漲
程式碼走查作為一種流程形式,起初大家的參與熱情非常高漲。
因為,自己可以學習到別人一些巧妙的思想,自己的程式碼和習慣都暴漏出來。
這個過程中不斷地吸收和改正。
但是。。。。。。
我們一開始組織的程式碼走查是一個很重的會議形式。
參加的人有寫這段程式碼的人(小菜)、比較有經驗的開發(大佬)
如果為了再隆重一些,請一些領導也參與其中。
但是。。。。。。
我上面提過了,會議很重,協調時間這個事情就是一個很費時間的事情。
還有就是,大家恨不得對每一句程式碼都發表自己的意見,往往非常的細枝末節。
導致會議時間經常在2小時以上,3小時時間就一般不得不停止。
大家都很累,再就是效果如何呢?
如果小菜自律性不夠,甚至沒人進行監督,這次的審查的程式碼不是都會修改。
因為有一些確實太過於雞蛋挑骨頭,根本改不動。
熱情褪去
不知不覺中,這種方式慢慢褪去。程式碼走查成為了一個優先順序、頻次都不高的活動。
有很多原因,上面說的形式太重是一個,還有就是大家都很忙了,沒有進行持續跟進導致效果不佳。
但是。。。。。。
也都知道程式碼走查對一些新人來說,成長史毋庸置疑的。收穫也是毋庸置疑的。
慢慢大家也都放下了。只是每次專案迭代中作為一個硬性要求執行一次罷了。
痛
我們小組裡面只有我還有一個剛畢業一年多的女生。
在我們組內的一個專案中,我總是以任務重為由,沒有進行程式碼走查。這個持續了很長時間。
一個字 —— 懶
在處理客戶反饋的問題時候,我突然發現,她寫的程式碼確實出現了比較粗心的失誤。
我心一想,長達3個月的時間都沒有對她的程式碼進行任何關注。
於她於我於專案,都是極其不好的。我這塊做得太自私了。
改
於是我在gitlab上加上了 【合併請求許可權】,逼迫她去仔細思考自己的程式碼,逼迫我必須去看她寫得每一行程式碼。
合併請求許可權
提交合並請求
程式碼走查
其中有規範、命名、優化、風格、bug
......
收穫
是的,這些時間付出是有價值的。是潛移默化的。很多時候我們為了Review一個問題點,討論20分鐘。
一方面深入挖掘她當時的思路:是知識面問題?還是偷懶?還是知道這樣後期再優化?
另一方面,也把我的想法和思路進行交流。有幾次是我認知就是錯誤的,通過討論發現了更好的實踐。
其實程式碼Review真的是一種非常好的實踐,我們不能以我們過來的人的眼光看待新人。
他們有他們的優點,當然他們也很可能會犯錯。我們使用一點時間,就能把這個問題給找到,對我們對他們都是一件好事。
再加上,程式碼review也是把團隊和部門甚至公司的制度流程以及規範進行一種培訓。只是換了一種方式。
至少我覺得我是有收穫的,通過幾次交流,成員也說明自己確實有收穫。
剛剛進入社會,剛剛入行的軟體工程師們,不都是自律能力非常強的。都有惰性。
通過這樣的形式,讓她感知提升,增加自信心,所以後期很多時候她都會把一些好的想法,反過來給反饋給我,我覺得確實是。於是我就偷偷回去改我的程式碼。
這也是一種溝通渠道,我覺得很多時候軟體就是在解決溝通問題。如何讓溝通做得有價值,有效率。
進
有了收穫,我依然想進行再一步的精進。找到一本書,能完全肯定我們現在做的事情是一種有價值事情的書籍。
《程式碼整潔之道》 《重構2》
規定時間裡閱讀完一章,找出系統中不好的,並按其思想進行修改。或者系統中已經這樣做的,找出來分析一下。時間不用很長。
從命名規範、函式分解、同一抽象層次分層、硬編碼、效率、類、模組、甚至資料夾構成
為什麼要做這些?
首先,我們先不去追蹤複雜的效率問題,先解決簡單功能實現,後期有人能看懂的問題。
這些實踐容易,並且效果明顯。有效果,我們就喜歡更深層次提升,再深入提升,就會自然而然晉升到了效能層面。
現在我覺得我和成員的一些討論都在討論執行效率。因為程式碼的命名、分層已經潛移默化養成了習慣。
有了成就感,就有了動力,有了動力,再去研究就會更加主動一些。
我也因此偶爾再總結一下,確實好的程式碼,令人心曠神怡,賞心悅目。更有讀下去的衝動,甚至更有模範的衝動。
K.I.S.S 原則、單一職責、多用組合少用繼承、最少知道原則等
很多時候,功能很簡單,我們卻寫得天花亂墜。
我幻想了一下,如果我們的客戶他喜歡程式設計,非要看原始碼實現呢?如果他看到原始碼實現如此簡單優美,心中如何感慨?
有時,我也時不時小結一下。
新人需要我們的指導,才能避免一些彎路;
我們也需要不斷回爐鍛造;
對程式碼多一些敬畏和欣賞~