Google 的軟體工程之道 (22) — 衡量工程效率
Published in
Feb 4, 2024
此系列為 【 Google 的軟體工程之道 】一書的書摘與點評，期待用最精要的文字，帶來豐富的內容分享。預計 2~3 周左右會有一篇更新，歡迎追蹤支持!
【 Google 的軟體工程之道 】全系列: https://medium.com/@johnliutw/list/da301cc31b15
需要測量軟體效率的原因
- 業務擴張帶來的組織規模需要成長，但溝通成本並不是線性成長，因此需要衡量工程師的效率，並提高之
- 除了工程師的效率需要提高，中間的改善過程，也需要高效率
衡量，指標是否值得測量
- 基本認知: 準備一個指標，並去『測量』，本身即是一個昂貴的行為
- 需要針對指標考慮
- 這個指標期望的結果是什麼? 跟商業目標有什麼關聯之處?
- 當這個期望的結果是有資料佐證的，有什麼對應行為?
- 如果這個指標有了負面的結果，要採取的行為是什麼? 是誰會採取這個行為? 他還需要那些資料?
3. 衡量時，可能會出現，不適用作為值得測量的指標之理由
- 因爲時間或金錢上資源的限制，無法承擔此指標的處理成本
- 此指標會被其他決策行為影響，而失去原本的效益
- 所幫助要定義要改變的行為，本身即是一定要完成的工作，變得錦上添花
- 指標本質上就不夠精確，無法測量其原本要處理的問題
測量的標準 ( GSM 框架)
透過 Goal、Signal、Metric，避免只測量能測量的部分 ( 通常是指指標 )，透過此框架，能夠保證一定的追朔性，去朔源一個指標最初要追蹤的問題為何。
Goal 目標: 最終需要期待的結果
- 時常會忘記將生產力的權衡因素考慮在內，例如衝刺速度目標，但卻忘記品質也有一定的重要性
- 要求團隊關注生產效率的五個核心部分: 程式碼品質、工程師的注意力、認知負荷程度、工作速度和自我成果滿意度
- 舉可讀性為一個目標為例，可讀性的優化幫助了程式碼品質，並且降低知識負荷，能夠更快更滿意地完成任務。雖然沒有幫助到工程師的注意力，但也是能夠接受的。
Signal 訊號: 想要測量但可能無法測量的東西
已可讀性的目標為例，對應的訊號:
- 高品質程式碼: 被授予可讀性認證的工程師能夠對程式碼品質有積極影響
- 降低對組織 best practice 的認知負荷: 工程師能分享在可讀性處理過程中的學習
- 提升工程師被 mentor 的機會: 工程師和資深工程師更積極互動
- 工程師能更快完成任務: 具有可讀性認證的工程師自認更有工作效率
- 工程師對自我成果夠滿意: 具有可讀性認證的工程師，認為此流程值得
Metric 指標: 實際上測量的標準，足夠接近訊號，並能代表之
- 針對高品質程式碼的目標與訊號，能整理出包括透過調查，找出對程式碼品質滿意的比例，並能測量 code review 中，討論到可讀性問題與意見相左可能性的比例
- 針對組織 best practice 認知負荷，調查能夠清晰說明內在知識，或是對於專業知識理解增強表示正面的工程師比例
- 工程師更快完成任務: 調查具有高生產力的工程師比例，並測量具有可讀性認證 review 時間中位數，並調查工程師自認增加工作速度的人員比例
- 工程師對自我成果夠滿意: 調查對於整體可讀性認證過程中，總體經驗滿意，且覺得值得的工程師比例
最後，指標只是搜集，並定義資訊，最重要的還是採取行動。
如果喜歡這個系列的話，歡迎將此連結加入你的最愛:
【 Google 的軟體工程之道 】全系列 https://medium.com/@johnliutw/list/da301cc31b15
