[經驗]關於Code Review兩三事

筆者剛開始入職場時,都是獨立完成專案為主,鮮少和其他同事共同開發,大家各自處理各自的專案,互不干涉。工作一段時間後,由於筆者剛好比其他同事資深,所以幾乎都是負責主導架構,但對於同事實際開發出的原始碼,我頂多稍作提醒,不至於要求照我的方式修改,若時間緊湊,也不會特地去看,頂多驗證功能。

對於Code Review,當時僅是聽過,看過一些網路文章,了解到有哪些好處。一直到後來,任職的公司有做版本控制,也一直有在做Code Review,才開始慢慢接觸並適應,所以這篇會說一些個人的經驗和看法。

首先,開發心態會不同,以往都是寫給自己看的,並不是每個人自我要求都很高,我就遇過有些同事只要功能完成就好,不太注重風格、可讀性、以及擴充性,時不時來一個魔法數字,或者處處hard code,廢棄代碼註解完測試過後又不刪掉等等族繁不及備載,這維護起來得多費勁,一旦你知道寫出來的代碼有人會看,會審,就不敢太誇張,會先自己審視過,確認沒問題才送出,至少品質會相對好一些。

另外在review和被review時,會發現許多自己沒想過的作法,或者替對方想到可讀性更高的寫法,對於想自我提升的人相當有幫助,但相對的,也要能接受不同的想法,習慣自己獨立規劃開發完成的開發者,一定會用自己認為最好的方式去做,並有自己的堅持,但你的最好和別人的不一定相同,還是要盡量用客觀的方式去了解reviewer的觀點和做法,若comment上來回說不清,建議直接當面或者電話說清楚好些。

而在下comment時,要盡量以建議的口吻,比較不會有那種要求人家一定要怎麼做的感覺,有時挺兩難的,所以後來我都是直接和開發者聯繫,若是打字講不清就電話,比較不會造成誤會或不愉快。我們的主管也會參與Code Review,好處是能掌握大家的情況,也許下屬會有一點壓力,甚至是抗拒,我個人是覺得主管畢竟是要替我們背責任的,在一些目的一樣但做法不同的前提下,稍微體諒一些也無妨。

另一個最大的好處,就是減少bug,為了驗證功能是否完成,都需要自己編譯並測試一次,有時自己開發時,漏掉一些狀況,但對方測試時就幫你找出來了,達到彼此互相把關的作用。

說完好處,來說說缺點,可想而知就是太花時間了,畢竟要測試過一輪,再看看寫法上有沒有隱藏的bug或是壞味道,有時不清楚測試的流程,還需要再問過,一來一回也挺費時。但整體來看,對於專案和產品穩定性來說,還是利大於弊,畢竟以前自己設計的架構,到後來回頭想,還是有許多設計不周的地方,能夠有人在早期就發現的話,也許產品的生命周期能更長命,避免讓下一個維護者煩惱著該如何重構、還是直接砍掉重練。

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

Create a website or blog at WordPress.com

向上 ↑

%d 位部落客按了讚: