Darkthread's Code Review Theory
2 |
昨天,我與部門內一個開發小組的四位成員,實現了十餘年Coding生涯的第一次正式Code Review! 很幸運的,這個團隊的成員都能保有開放的心接受建言,對於Code Review也多半給予了正面肯定,整個過程與結果都比我預期的好很多!
在我的刻板印象中,Code Review的動機與目標都是正面的,但問題出在Code Review的過程常常挑動了不少程式設計人員最敏感的神經,稍有不慎就很容易把原本一椿美事搞成血腥的意氣之爭。原因出在程式設計這門學問,不太容易建立明確的共識! 同樣的結果,可以有成千上百種寫法,哪一種才算"優質"? 哪些算是"雖不完美,但可接受(或是忍受)"? 而哪些是"要不得,非改不可"? 過程中常流於大家各持己見,陷入無效率的冗長辯論,偏離了Code Review原本的目標。最糟的情況是,討論到最後,哪種做法最好已不是重點,大家不過只為吞不下這口氣而爭個你死我活,就在我覺得你的寫法很幼稚,你覺得我的做法不成熟的僵持中,不但整體程式品質沒提升,還搞得一堆人反目成仇,一塌糊塗。
我理想的Code Review,就試著用一種較不同的觀點來銓釋Code Review的目標與過程。傳統的Code Review比較傾向透過"糾正"的方式、要求所有程式師依循一套"標準"來撰寫開發程式。然而"糾正"常使程式人員難堪,而"標準"要誰說了才算,多半只能靠"拳頭"或"嗓門"決定,這些爭議往往帶來不少的副作用。
我的看法是,各式各樣的程式寫法都有其優缺點,本來就很難去界定絕對的優劣;而換個角度想,就算程式的寫法不夠好,寫起來略嫌冗長,或看起來有點笨拙,難道程式一定會Crash,當真如此天地不容嗎? 我主張: 只要沒違反資安或效能上的禁忌,程式人員還是可以保留一丁點自由裁量的空間,但前題是: 他是在知道有其他做法的情況下,衡量過利弊得失,最後選取了自己偏好的寫法,而非在不知其他替代做法下只會用唯一知道的方法實作。
因此,Code Review的首要目標在於讓程式人員有機會了解其他的做法及其優缺點,進而點出原有做法的不足,透過建立共識的方法,逐步歸納出團隊都同意的推薦做法,再進一步規定某些必要的寫法限制(通常是為了要避開某些資安或效能的漏洞)。在我的Code Review理論中,由於程式寫法沒有絕對的好壞,其他人所提出的先會是"
建議"(Suggestions),目的在於提供其他的做法選擇作為參考,並讓各種做法的優缺點被明白的揭示。提出的建議中,透過詳細的優缺點比較,有一些建議會獲得大家一致的共識(Aggreement),而必要性較高的則列為開發過程時應參考的推薦做法(Recommendation)。最後,Recommendation其中又有一些在未遵從時,可能引發較嚴重的後果,例如: 資安漏洞、效能不彰、維護困難... 等等,就可以將其制定為"規則"(Rule),要求所有人一定要遵從。如下圖所示,這個過程演化的基礎靠的是討論與建立共識,建議中只有一部分會變成共識,共識又只有一部分會成為推薦做法,推薦做法中只有一部分會真的變成硬綁綁的規則。
我知道在CMMI哲學中,程式師實在不應該擁有這麼多自由,應該是每人發一本上千頁的Coding Rules或Coding Guide,然後照著Spec,像打毛線一樣,一列一列把程式生出來。只是在實務的環境中,有多少人可以有幸能帶領這種Coding Zombie(僵屍型程式師,這個形容很貼切吧? 如果有人覺得太辣,那我願意修正成半獸人或強獸人)大軍攻地掠地? 大部分的時間,你所遇到的程式師有血有肉,有想法、有情緒,當我們不可能靠一本Coding Rule去奴役這群"人類"程式師時,稍稍回歸一點民生,多一點人性化的空間,也許會有更好的結果吧?
Comments
# by aspect solution
感覺很像是唱歌。如果用那種會打分數的卡拉ok來唱,電腦就會給分。如果是去參加歌唱綜藝節目,評審就會給分。如果是主修音樂,教授會給分。同樣是給分,就看你服不服氣。 不管服不服氣,沒有review,團隊就不會進步。有些公司就是這樣,十年後還是停在原地。
# by Jeffrey
嘿嘿... 這個比喻好! 所以評審的表達技巧也有差別,明明出自善意的指正,如果配上"小松小柏"式的毒舌,恐怕有些新人會難過到恐慌症發作。反過來說,受評者的心態正確,心理素質夠強,就有機會從難聽的批判中揀出對自己有用的東西。不過,如果說好話跟說難聽的話都有效果,嘴巴還是不要太賤,多積積德,將來可以少上幾次刀山吧,呵!