iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 10
1
Software Development

軟體開發隨筆談系列 第 10

程式碼風格要點在於一致,而不是優劣

〈如何導入 Code Review 〉有略提到程式碼風格的議題,提到程式碼風格應該透過自動化去檢核,而不是在每次 Code Review 時仰賴人工審核。然後在《為團隊與組織導入敏捷的經驗分享》 系列文中的〈制定一個可落實的政策〉也有提到下面這段話,因為和本主題相關,就一併引用過來集中資訊:

一次要針對所有程式碼都統一風格,可能會因為範圍太大,有點窒礙難行,所以可以先限縮範圍在 JS 的程式碼,然後只有新的 Commit 需要遵守,先不溯及既往,不然光是重構就瘋了。

再來是要遵循怎樣的風格,有人喜歡 AirBnB 的風格、有人喜歡 standardJS 的風格,可能是先選擇一個作為標準去遵循,那可能就是讓幾個目前比較活躍的 JS 專案嘗試看看,編寫一個腳本去只針對 Git 顯示有變動的部分去透過 ESLint 檢查是否符合風格。

這樣不斷的限縮範圍和補完後,一個可落實的政策就差不多完成了。接著可在訂定一個在哪一天大家再重新檢視這個專案是否要修改,或是有什麼地方可以讓大家提出想要修改其中哪一條風格設定,讓原本遵循的風格更具團隊特色等等。

上面講的這些話,大致把團隊如何導入程式碼風格的方式做個建議,這邊在簡短的總結、補充:Code Review 應該透過 Lint 來進行,並透過 CI 進行自動化檢測,只讓通過檢測的變動可以併回主線。程式碼風格可以先選擇一個標準,再逐漸修改成團隊自己喜歡的風格。另外補充,除了先選擇一個標準外,也可以從零到有,讓團隊在每次 Code Review 提出一個統一建議,並且另外提出一個 PR 去將標準寫進設定檔,併入主線。

好,除了導入程式碼風格外,今天來聊聊另一個議題,也就是標題所言:「程式碼風格要點在於一致,而不是優劣」。

在軟體開發的圈子裡,有個很有趣的現象,就是大家都很喜歡戰語言、也喜歡站程式碼風格。誠然,有些程式碼風格會讓整體程式的可讀性增加,應該要盡快引入,但是在引入時,又有人會因為信仰不同,而提出另一個風格建議,最後兩方就開始吵誰優誰劣,甚至鬧到不歡而散。

但事實上,對團隊開發來說,程式碼風格的要點在於一致,而不是哪種風格比較好。舉個極端的例子,若是本來專案已經用了惡名昭彰的匈牙利命名法,新來的成員覺得不妥,提出改成了駝峰式命名法,後來又有新成員近來,覺得蛇式命名法比較好,於是又換了另一種風格。成員來來去去,風格可能也換來換去,當是在換風格時難免會漏改幾個,最後整個專案命名規則紊亂,那還不如全體都遵守匈牙利命名法比較好。

所有程式設計師應該都有有個認知,彼此對程式碼風格的喜愛不一樣是正常現象,重點是同個專案程式碼風格要統一,若是最後以投票表決決定某種程式碼風格,就應該要尊重團隊的決議。只有當風格統一時,彼此在閱讀其他人編寫的程式碼時才能比較輕鬆。

其實,程式碼風格就像是團隊的默契,也是會需要逐漸養成的。很難一開始就定義出一個完整的程式碼風格,所以會建議如前面所講,再逐次遇到對風格有歧異時,團隊約個時間一起坐下來討論,不同意見者發表各自支持的論點,最後彼此綜合這些意見,以投票或是團隊認同的形勢作出決定,再把決議寫進 Lint 設定檔中。若有些風格不是設定檔所能規範時,就寫在專案根目錄的某個文件裡。透過這樣逐漸訂定出團隊自屬的風格,讓彼此的程式碼讀起來就像自己寫程式碼一樣輕鬆。


上一篇
MVP 與 Product
下一篇
暸解目的去實作,而不是暸解要去實作什麼
系列文
軟體開發隨筆談31

尚未有邦友留言

立即登入留言