每個人都有自己的工作習性，工程師也是如此，他們容易看別人的程式「不順眼」，想要全部重寫。這個習慣如果發生在小團隊還好，但大型協作案禁得起這樣「砍掉重練」的資源浪費嗎？

群暉科技（Synology）網路儲存裝置（NAS，network attached storage）的核心作業系統（DSM，DiskStation Manager），就是規模最大、複雜度最高的大型專案。以最近的 2 個版本來看，相差的程式碼將近千萬行。群暉動用超過 200 名工程師、700 多個專案共同協作。

在群暉，產品開發流程主要包含 3 個階段：產品設計、研發及驗收測試。設計階段需要工程師、專案經理（PM，project manager）、品質管制（QC，quality control）等相關部門，共同確認產品規格；研發階段則需要工程師彼此檢視程式碼的品質與盲點；最後則是針對系統做不同的效能與壓力測試。

群暉科技基礎架構與網路部門資深開發研究員林宏昱表示，軟體開發每個階段會產生的失誤都不一樣，尤其是寫程式，錯誤無可避免，「小團隊轉個頭就可以溝通，但大團隊會需要規範，透過制度解決、預防問題。」

自動化系統協助，降低編譯失敗率

一般來說，工程師會先在自己的電腦裡撰寫程式碼，等到完成一個段落後，把程式碼轉成機器碼（編譯），再把程式「丟」進服務主機。這個過程中，如果一開始寫的程式碼有錯，稱為語法錯誤；如果無法正確轉換成機器碼，就稱為編譯錯誤。

群暉透過程式審碼（code review），要求工程師程式寫到一個段落，須交由另一位同事看是否有語法、邏輯上的錯誤。如果沒有問題就在程式上刻上名字，以示完成審核。

另外，由於每個工程師有自己的編碼風格，選用的開放原始碼或資料庫也都不同，由多位工程師協作開發作業系統，大大提升編譯失敗的可能性。

林宏昱解釋，就像蓋房子要選用自己順手的工具，軟體開發也要選擇工具，但困難點是，編碼就像樹枝向上發展，而樹根就是工具，一旦選錯或是選到不好的工具，很難替換。

為了避免編譯失敗，群暉 2015 年開發一款名為「甘道夫」（Gandolf）的系統，在不同專案簽入時，會自動執行編譯與單元測試。當編碼不符合需求或有任何問題時，系統會拒絕存取，把不符合的內容擋在系統外，也能在早期發現問題。

研發設「專案擁有者」，建立當責文化

他們平均每天執行甘道夫系統 31 次，在 2020～2021 年間編譯失敗率降低了 6.73 個百分點。假設每次編譯失敗平均得花費 4.5 小時修復，自動化系統的協助，為他們省下超過 1 萬小時的開發時間。

林宏昱表示，專案的分工明確能讓負責人有當責觀念，不只是 PM，研發單位也會有專案擁有者（project owner），他必須針對產品的每個面向做維護，不只是產品本身，也會想到使用者體驗面，「讓那個人負責，就會有更大的動機、積極度關注產品的各種問題，進而提升品質。」目前研發部門的重修率（redo rate）維持在 2% 以下。

不同於許多科技公司指名道姓的文化，群暉利用流程檢視產品，讓每個人都可以點出問題，「在流程上可以確保問題後續會有人幫我驗證，人對人的意味就沒那麼強，也不會有隱瞞失誤而讓雪球愈滾愈大。」

林宏昱

交通大學資訊工程系學士、資訊科學與工程碩士，2014年加入群暉科技，現為基礎架構與網路部門資深開發研究員。