嗨~ 歡迎閱讀 ExplainThis 全端開發雙週報。這週的主題文,將會是摘要先前 E+《Google 的軟體工程之道》直播工作坊的第一段落。很高興先前我們有機會,邀請到在美商資安獨角獸公司擔任資深全端工程師的 John 來談這本書的精華。
E+ 目前除了每週的主題深度文外,幾乎每個月都有直播。在下下週,E+ 將有《如何寫出乾淨好維護的程式碼》直播工作坊,透過互動的方式,帶大家寫出更乾淨好維護的程式碼。對於這主題有興趣的人,歡迎加入 E+ (連結)
[軟體開發] Google 的軟體工程之道
《Google的軟體工程之道》原文書名叫《Software Engineering at Google》,是 2020 年時,多位 Google 的資深主任工程師合寫的書,詳細地介紹了 Google 內部的軟體工程制度、規範、工具,以及軟體工程文化。
這本書的原文電子版本是免費的 (可以在這邊閱讀),非常感謝作者們的慷慨。而現在到 Google 搜尋《Google的軟體工程之道》第一篇會找到的心得文,就是 John 寫的 (連結)。
這次工作坊 John 將結合他多年軟體開發、帶領團隊的經驗,來談論如何做好提升工程品質與自動化 (測試、CI/CD)、系統更迭 (系統依賴、棄用、大規模變更),以及團隊文化 (知識共享、工程效率、技術領導)。
在談論工程品質時,John 向工作坊參與者提問「你目前在的開發團隊,在靜態分析、程式碼審查 (Code Review)、文件的現況為何? 如果要進一步改善,會怎麼做?」,並接著分享這三個面向的一些推薦實踐方式。
靜態工具 (Static Analysis)
首先 John 談到靜態工具是用來做程式碼靜態分析,例如常見的風格 (style)、linting 檢查等工具,來確保程式碼的一致性。因為多數時候,程式碼更常被閱讀 (比起被撰寫),所以要以讀者為本,盡可能保持一致性。透過靜態工具,我們能夠讓工具幫我們抓出不一致的部分,來為一致性把關。
你可能會問,一致性有什麼好處? 具體來說,在大型團隊,一致性的好處可以讓組織發生變化時,工程團隊能夠容易相互支援。舉例來說,今天 A 團隊要開發一個重要的新功能,且時間有限。B 團隊正好有一些餘裕可以支援。
如果這時 A 與 B 團隊的開發習慣差太大,這樣要去支援 A團隊時,差異將導致 B 團隊很難快速上手。所以如果能夠有組織或公司層級的一致性,將能夠確保這部份的上手成本降低。
程式碼審查 (Code Review)
接著 John 談到了程式碼審查。在《Google的軟體工程之道》一書當中有特別談到幾個在程式碼審查要關注的面向,包含:
正確性:程式碼功能是否如預期?
安全性:程式碼是否有潛在的安全漏洞?
強固性:程式碼有沒有做好錯誤處理 (error handling)?
可讀性:程式碼是否乾淨、風格一致?
效能:程式碼能不能有更好的時間或空間複雜度?
而具體來說,程式碼審查該如何進行? 第一個原則是,能夠自動化就不要人處理,例如上面提到的靜態工具,或者自動化測試,這些在進到其他工程師的審查前,要先跑過。
而要加快讓別人能幫你看完程式碼,推薦讓 PR 的變更描述更清楚,以及為 commit 訊息分類,例如 feat、fix、refactor (詳細見此)。同時,盡可能讓每個 PR 保持夠小,例如維持在 200 行內。假如真的是很大的 PR,則可以透過拉會議來過,確保能有效完成審查。
另外,在程式碼審查時,審查者有禮貌與風度會很重要,詳細如何做到,John 推薦了 Google 開源的程式碼審查指南 (連結)。
文件 (Documentation)
除了靜態工具與程式碼審查,文件也能夠幫助團隊提升軟體工程效率。具體來說,文件能讓新加入團隊的人,能夠更快速融入,同時減少不必要的重複問題回答。更進一步來說,文件能確保軟體設計者,有足夠清楚的定義好設計,因為假如沒辦法轉換成文件,很可能是因為設計不夠清楚。
在寫文件時,有一個重要的核心關注點是「為什麼做出如此設計決策?」,在紀錄「為什麼」時,推薦可以特別寫下在過程中有哪些取捨,這樣可以讓未來讀文件的人,更清楚相關脈絡。
除此之外,可以把寫文件當成跟寫程式一樣,寫程式時好的原則,對寫文件也有幫助。舉例來說,文件要有清楚、一致的用語表達。同時,要單一職責原則,避免單一文件又臭又長。另外,也推薦要做文件的版本控制,讓讀的人知道目前的文件是對應到什麼版本,才不會讀到不適用的內容。
也如同寫程式一般,要從讀者的角度出發。在寫的時候要有目標讀者,例如是寫給新加入團隊成員,還是寫給已經清楚相關脈絡的人。假如是前者,就需要考量到新團隊成員可能不知道某些脈絡,這時就需要補上。同時,可以多加範例,這樣更容易讓人懂。
相信多數人會同意文件的好處,然而許多團隊在文件化上做的並不理想,例如文件過時,跟當前實際的程式碼差異很多,或是文件散落在各地。關於這點,John 推薦在一開始就要建立好統一管理文件的空間,以及建立文件模版與版本控制機制,讓團隊在更新文件上不用花費太大的成本。
更多內容
關於軟體工程品質,John 有在工作坊進一步談改善團隊軟體品質,以及系統更迭 (系統依賴、棄用、大規模變更),以及團隊文化 (知識共享、工程效率、技術領導) 等深入內容。
如果你對完整的直播感興趣,歡迎訂閱 E+ 成長計畫 (連結) 來觀看直播回放 。另外,John 本身也有粉絲專頁,推薦可以追蹤 (連結)。
[本期推薦]
除了本期主題文談到的《Google的軟體工程之道》是免費的學習資源外,Google 還有許多其他的優質免費學習資源,我們匯總了總共 7 個,推薦想進一步自我提升的人參考 (連結)
《An interactive study of queueing strategies》是學習佇列 (queue) 做得非常好的互動式教材,如果你對 FIFO、LIFO、Priority Queue、RED 等概念還不熟,相信玩過這個教材,應該能掌握 (連結)
版本控制是現代軟體開發中,不可或缺的重要元素。提到版本控制就不能不提最熱門的 Git。我們彙整了幾個免費又高品質的 Git 入門學習資源,有興趣的人可以參考 (連結)
最近 Nvidia 的黃仁勳的新聞非常多,但在眾多新聞中,看到一個前 Meta 主任工程師的貼文,覺得特別精闢。黃仁勳雖然外放,讓人覺得充滿熱情,但是在經營公司上,是相對冷靜的 (連結)
不論在什麼面試,在面試最開頭,面試官都很常會請你先自我介紹。這個問題要如何回答好呢? 可以參考這篇《面試時如何自我介紹?》 (連結)
svgl 是近期討論度頗高的 SVG icon 集合網站,該網站製作的各種 icon 都特別美,如果你的專案有使用 SVG 的需求,可以參考 (連結)
JavaScript 的 Promise 一直是許多人參透不了的概念,特別是背後的運作機制。《JavaScript Visualized: Promise Execution》這個影用視覺化的方式,把這概念講得很清楚 (連結)
Jotai 是一個相當熱門的狀態管理套件,其作者 Daishi Kato 先前寫了一篇文章分享一些使用 Jotai 的秘訣,推薦有在用 Jotai 的人一讀 (連結)