對於一家以軟體研發作為核心競爭優勢的公司來說，除了工程技術的持續推進之外，要如何在一個軟體開發專案流程中，增加開發效率並且確保軟體品質，可以說是相當關鍵的挑戰。
Synology NAS 的核心作業系統 DiskStation Manager（DSM），就是個億級程式碼規模的大型軟體開發專案。以最近的兩個 DSM 版本， DSM 6.2.4 與 DSM 7.0 更新來看，兩版之間的程式碼有近千萬行的行數差距，因應日益成長的軟體規模以及複雜度，我們也花了更多的人力、時間在 DSM 7.0 的研發上，包括歷時兩年，公司內部超過 200 名 RD 協作進行開發、組成 700 多個不同專案組合，都是為了讓 DSM 7.0 成為一套更加千錘百鍊的系統，進一步因應更加嚴苛的 IT 環境。
什麼是軟體品質？淺談 Synology 的產品開發架構
要打造一套穩定、流暢的作業系統，需要許多嚴謹的步驟，而要如何在整個產品開發的流程中確保軟體品質更是至關重要。首先，我們先來了解 Synology 在整個產品開發的流程中，主要有哪三個主要環節。
第一個階段，產品設計（Product Design）。這個階段需要跨部門合作，RD、PM、Support、QC 等相關部門會一同確認架構設計與規格。此外，包括安全性問題，也會在產品設計時一併考量進去。 Synology 的安全應變小組（SIRT，Security Incident Response Team）也會在這個階段協助安全方面的架構設計，在產品開發初期即做到 Security by Design / Default 的源頭管理。
第二個階段，產品研發（Develop） 。透過使用靜態分析工具（SAST）、編譯失敗預防機制（Build fail prevention）與持續整合（Continuous Integration），得以確保整個軟體開發環節的品質。此外，我們也藉由 Code Review ，讓 RD 彼此檢視程式碼中是否有自己沒有辦法觀察出的盲點並進而改善。
第三個階段，驗收測試（Acceptance Test）。在此階段進行針對 DSM 系統以及各套件不同的效能與壓力測試方式。
而在第二個產品研發階段，是以工程的角度來看與軟體品質最直接相關的環節。以下我們會專注談，在 DSM 7.0 的產品研發階段，主要透過解決了哪三個問題來提升軟體品質。
（Synology 在產品研發流程中，透過解決軟體編譯，透過自動化工具找出缺陷以及執行效能驗證來提升產品品質。）
為了讓您的產品更好，我們做了哪三件事？
第一，是解決軟體編譯失敗的問題。
軟體編譯是將程式碼轉變成機器碼的過程。在這個過程中，如果發生了程式碼因為某些原因（例如語法錯誤等）無法正確轉換成機器碼，則會發生編譯錯誤。一旦發生軟體編譯錯誤，就必須回頭修復後再度提交程式碼，影響到的會是所有相依專案的工程人員。
DSM 套件是由 700 多個不同專案組合而成的複雜作業系統，由 Synology 內部超過 200 名全職 RD 協作進行開發，也因為人數眾多，導致專案的變動次數相當可觀，而大量專案之間的相依關係，更進一步提升了編譯失敗的可能性。
我們可以簡單的計算一下編譯失敗所花費的時間成本：如果每次編譯失敗，得面臨最少將近半天（一次編譯時間以 4.5 小時來計算）的工作時間停擺，所有相關的專案人員（RD & QA）以 200 人計，那麼每次編譯失敗所造成的時間成本就等於：「RD & QA 數量 * 修復為止的耗時 *」，整體耗費的成本相當驚人。因此，提升編譯的成功率在推動專案進行可說是扮演關鍵性角色。
為了防止編譯失敗，我們於是自行開發了代號為「甘道夫（Gandolf）」的系統，這個系統可以確保我們在任一專案簽入（Commit）的時候，執行所有相依專案的完整編譯和單元測試，如此一來，就可以在簽入階段為編譯錯誤以及單元測試的錯誤做把關，造成編譯錯誤的程式碼就不會進一步進入到我們的儲存庫（Repository）中，直接降低了編譯失敗的可能性。
過去我們一年平均每天執行甘道夫系統 31 次，一年總計執行了一萬次，平均降低 6.73% 的編譯失敗率。以節省的成本來計算，就是 200 ( RD & QA 數量） * 4.5 * 200 （4.5 小時工作時間* 200 個工作天） * 6.73 = 13325 hr，總計為我們節省了超過一萬個小時的開發時間，大幅提升開發效率，並降低溝通成本。
第二，是自動發現缺陷（Defects）。
首先先解釋一下，隨著系統的規模、複雜度不斷成長，所謂的功能性弱點、 臭蟲（Bug），這些我們可以通稱為缺陷（Defects）的項目，也會在正常情況下出現，且數量會越來越多。因此，透過使用靜態分析工具（SAST）等自動化測試工具，可以協助我們提前找出各種缺陷跟安全性問題，並在每版更新對外釋出之前， review 完所有的缺陷並做相對應的調整。
透過自動化測試工具，我們能定時且有規律掃出安全性問題與 bugs ，自動預防潛在的安全漏洞和臭蟲，更好且更有效率的把關安全性，且在對外釋出更新前，從源頭就優先改善缺陷，也讓研發人力可以將心力投注在更具價值的測試項目上。
回到 Synology 的產品政策，隨著 Synology 的使用者逐步從家用使用者成長到企業市場，我們在大概 7 年前即開始採用自動化測試工具，並在 DSM 7.0 上，導入更多不同的編碼規範（Coding Standard）如 CERT、MISRA 等，為企業用戶提供更佳的軟體品質。
（執行自動化全平台效能驗證，協助提升 Synology NAS 的傳輸表現，滿足對於伺服器效能有高度要求的企業與使用者。）
第三、執行自動化全平台效能驗證
從使用者的角度來看，除了產品的穩定度、安全性外，效能（Performance）也是至關重要，因此我們也花了不少心力在效能的改善上。
相較於安全性問題與 Bug 能夠透過手動測試或是自動化工具來找出來 ，效能問題則是很難在產品開發端就察覺，這是由於軟體的開發是有一層一層的層級的，每一層都有機會導致效能出現落差，必須回頭重新審視架構找出根本原因（Root cause）所在。
有些軟體公司採取的作法，是只在年度性重大版本更新才驗證效能，平常每月或每季的穩定性更新並沒有加入效能追蹤指標。但 Synology 相當重視效能表現，也不希望使用者在每一版升級時遇到效能與預期不符，甚至下降的問題，我們因此建立自動夾板測試機制，協助我們在研發階段提早找出效能可能下降的瓶頸。
自動夾板測試，意即我們會針對每一個內部版本都進行效能測試，並追蹤效能測試的各項指標在各版本之間的差異，只要和原先預期的有落差，就會通知相關的工程人員進行即時處置。執行夾板測試最大的好處在於，每一版之間的變化不會太多，因此較易於追蹤最有可能導致效能下降的原因，讓問題可以被更頻繁的檢視。
例如，過去在某次版本升級時，我們就曾因為升級某個 Open source 版本，導致重要的檔案傳輸效能下降。當時歸功於夾板測試保留了每一板的完整效能測試報告，讓我們在第一時間即可縮小範圍，在追蹤後發現是 Open source 的預設參數調整導致的效能變化。如果沒有夾板的完整測試報告，我們可能要耗費更多倍的時間才可以找出這個問題。
更好的品質與更高的效率
透過改善軟體編譯失敗的問題，用自動化工具找出缺陷，以及執行夾板測試追蹤效能變化這三種方式，讓 Synology 得以在大規模的軟體開發專案中更好的掌握軟體品質，也讓整體開發流程更為順暢。
事實上，一套複雜的系統的練成相當不簡單，但背後的核心理念其實相當一致：盡量在越早期的階段發現問題，就能在相對短的時間內處理問題，再到解決問題，提升開發效率並節省成本。未來，我們也會持續建立審核軟體品質的指標，並且標準化自動化測試流程，持續增加程式的穩定，提供 Synology 的使用者更好的產品服務。