源代碼 QA：不再只是針對開發人員

二十年前，當我在汽車行業工作時，一家工廠的廠長經常會說，“我們有一天造車，但我們的客戶有一輩子的時間來檢查它。” 質量是最重要的。 事實上，在汽車和建築行業等更成熟的行業，質量保證是系統集成到產品開發過程中的關鍵考慮因素。 雖然這當然是由保險公司的壓力推動的，但正如工廠主管所指出的那樣，最終產品的使用壽命也決定了這一點。

然而，在軟件方面，較短的生命週期和持續升級意味著源代碼完整性往往被忽視，而傾向於新特性、複雜功能和上市速度。 產品經理經常不重視源代碼質量保證或將其留給開發人員處理，儘管事實上它是決定產品命運的更關鍵因素之一。 對於關心為產品開發打下堅實基礎和消除風險的產品經理來說，定義和實施對源代碼質量的系統評估至關重要。

定義“質量”

在探索正確評估和製定源代碼 QA 流程的方法之前，重要的是要確定“質量”在軟件開發環境中的含義。 這是一個複雜且多方面的問題，但為了簡單起見，我們可以說質量是指支持產品價值主張而不影響消費者滿意度或危及開發公司業務模式的源代碼。

換言之，優質的源代碼準確地實現了產品的功能規範，滿足了非功能性需求，保證了消費者的滿意度，最大限度地降低了安全和法律風險，並且可以負擔得起的維護和擴展。

考慮到軟件分佈的廣泛和迅速，軟件缺陷的影響可能很大。 錯誤和代碼複雜性等問題可能會阻礙產品採用和增加軟件資產管理 (SAM) 成本，從而損害公司的底線，而安全漏洞和許可證合規違規可能會影響公司聲譽並引發法律問題。 即使軟件缺陷沒有造成災難性的後果，它們也有不可否認的代價。 在 2018 年的一份報告中，軟件公司 Tricentis 發現，來自 314 家公司的 606 次軟件故障導致上一年的收入損失達到 1.7 萬億美元。 在剛剛發布的 2020 年報告中，CISQ 將美國劣質軟件的成本估計為 2.08 萬億美元，另外估計還有 1.31 萬億美元的未來成本來自技術債務。 這些數字可以通過早期干預來減少； 在產品設計期間解決問題的平均成本明顯低於在測試期間解決相同問題的成本，而這反過來又比部署後解決問題的成本低得多。

處理熱土豆

儘管存在風險，但軟件開發中的質量保證是零散的，其特點是採用被動方法，而不是其他行業採用的主動方法。 源代碼質量的所有權是有爭議的，當它應該被視為不同功能的集體責任時。 產品經理必須將質量視為一種有影響力的特性，而不是開銷，管理人員應關注質量狀態並對其進行投資，工程職能部門應抵制將代碼清理視為“燙手山芋”。

使這些委託挑戰更加複雜的是，現有的方法和工具無法從整體上解決代碼質量問題。 使用持續集成/持續交付方法可以減少低質量代碼的影響，但除非 CI/CD 基於徹底和整體的質量分析，否則它無法有效地預測和解決大多數危害。 負責 QA 測試、應用程序安全和許可證合規性的團隊使用旨在僅解決問題的一部分並僅評估某些非功能或功能需求的工具在孤島中工作。

考慮產品經理的角色

源代碼質量是產品經理在產品設計和整個軟件開發生命週期中面臨的眾多難題。 技術債務是沉重的開銷。 在低質量的代碼庫上添加和修改功能更加困難和昂貴，並且支持現有代碼複雜性需要大量時間和資源投資，否則這些時間和資源可能會花費在新產品開發上。 隨著產品經理不斷平衡風險與上市速度，他們必須考慮以下問題：

• 我應該使用 OSS（開源軟件）庫還是從頭開始構建功能？ 哪些許可和潛在責任與所選圖書館相關？
• 哪種技術棧最安全？ 哪個確保了快速和低成本的開發週期？
• 我應該優先考慮應用程序的可配置性（高成本/時間延遲）還是實施定製版本（高維護成本/缺乏可擴展性）？
• 在保持高代碼質量、最小化風險和保持低工程成本的同時集成新獲得的數字產品的可行性如何？

這些問題的答案可能會嚴重影響業務成果和產品經理自己的聲譽，但決策通常是基於直覺或過去的經驗，而不是嚴格的調查和可靠的指標。 一個全面的軟件質量評估過程不僅提供決策所需的數據，而且還使利益相關者保持一致，建立信任，並有助於形成一種透明的文化，在這種文化中，優先級是明確的和商定的。

實施 7 步流程

一個完整的源代碼質量評估過程會產生一個診斷，該診斷考慮了完整的質量確定集，而不是一個更大問題的幾個孤立的症狀。 下面介紹的七步方法與 CISQ 的流程改進建議一致，旨在促進以下目標：

• 查找、衡量和解決接近其根本原因的問題。
• 根據整體質量測量，明智地投資於軟件質量改進。
• 通過分析完整的測量集並確定最佳、最具成本效益的改進來解決問題。
• 考慮軟件產品的全部成本，包括擁有成本、維護成本和許可/安全法規調整成本。
• 監控整個 SDLC 的代碼質量，以防止令人不快的意外。

1. 產品到代碼的映射：將產品功能追溯到其代碼庫似乎是顯而易見的第一步，但考慮到開發複雜性增加的速度，這並不一定簡單。 在某些情況下，一個產品的代碼被劃分在多個存儲庫中，而在其他情況下，多個產品共享同一個存儲庫。 在進行進一步評估之前，有必要確定包含產品代碼特定部分的各個位置。

2. 技術棧分析：這一步考慮了使用的各種編程語言和開發工具、每個文件的註釋百分比、自動生成代碼的百分比、平均開發成本等。

推薦工具：cloc

替代品：Tokei、scc、sloccount

3. 版本分析：根據這部分審計的結果，包括識別代碼庫的所有版本併計算相似性，可以合併版本並消除重複。 此步驟可以與 bugspots（熱點）分析結合使用，該分析可以識別代碼中最常被修改且往往會產生更高維護成本的棘手部分。

推薦工具：cloc、scc、sloccount

4. 自動代碼審查：這種檢查會探測代碼中的缺陷、違反編程實踐的情況以及硬編碼令牌、長方法和重複等風險元素。 為此過程選擇的工具將取決於上述技術堆棧和版本分析的結果。

推薦工具：SonarQube、Codacy

替代方案：RIPS、Veracode、Micro Focus、Parasoft 等。 另一種選擇是 Sourcegraph，一種通用代碼搜索解決方案。

5. 靜態安全分析：這一步也稱為靜態應用安全測試（SAST），探索和識別潛在的應用安全漏洞。 大多數可用工具針對 OWASP 和 SANS 等組織發現的經常發生的安全問題掃描代碼。

推薦工具：WhiteSource、Snyk、Coverity

替代方案：SonarQube、Reshift、Kiuwan、Veracode

6. 軟件組件分析 (SCA)/許可證合規性分析：此審查涉及識別直接或間接鏈接到代碼的開源庫、保護每個庫的許可證以及與每個許可證相關的權限。

推薦工具：Snyk、WhiteSource、Black Duck

替代品：FOSSA、Sonatype 等

7. 業務風險分析：此最終措施涉及整合從前面步驟收集的信息，以了解源代碼質量狀態對業務的全面影響。 分析應生成一份綜合報告，為利益相關者（包括產品經理、項目經理、工程團隊和最高層主管）提供他們權衡風險和做出明智產品決策所需的詳細信息。

儘管此評估過程中的先前步驟可以通過廣泛的開源和商業產品實現自動化和便利化，但沒有現有的工具可以支持完整的七步過程或其結果的聚合。 由於這些數據的編譯是一項繁瑣且耗時的任務，因此要么隨意執行，要么完全跳過，可能會危及開發過程。 這是一個徹底的軟件檢查過程經常崩潰的點，這使得這最後一步可以說是評估過程中最關鍵的一步。

選擇正確的工具

儘管軟件質量會影響產品並因此影響業務成果，但工具選擇通常委託給開發部門，非開發人員可能難以解釋結果。 產品經理應積極參與選擇確保透明和可訪問的 QA 流程的工具。 雖然上面建議了評估中各個步驟的具體工具，但在任何工具選擇過程中都應考慮一些一般性考慮因素：

• 支持的技術堆棧：請記住，大多數可用產品僅支持一小部分開發工具，並可能導致部分或誤導性報告。
• 安裝簡單：安裝過程基於復雜腳本的工具可能需要大量的工程投資。
• 報告：應優先使用能夠導出詳細、結構良好的報告的工具，這些報告可以識別主要問題並提供修復建議。
• 集成：應篩選工具，以便與正在使用的其他開發和管理工具輕鬆集成。
• 定價：工具很少附帶全面的價目表，因此仔細考慮所涉及的投資非常重要。 各種定價模型通常會考慮團隊人數、代碼大小和所涉及的開發工具等因素。
• 部署：在權衡內部部署與雲部署時，請考慮安全性等因素。 例如，如果被評估的產品處理機密或敏感數據，則本地工具和使用盲審方法 (FOSSID) 的工具可能更可取。

保持下去

一旦有條不紊地識別和分析了風險，產品經理就可以圍繞優先級和更準確地分類缺陷做出深思熟慮的決策。 可以重組團隊並分配資源以解決最緊急或普遍的問題。 像高風險許可證違規這樣的“攪局者”將優先於低嚴重性缺陷，並且更多的重點將放在有助於減少代碼庫大小和復雜性的活動上。

然而，這不是一個一次性的過程。 測量和監控軟件質量應該在整個 SDLC 中持續進行。 應定期進行完整的七步評估，每次分析後立即開始質量改進工作。 識別新風險點的速度越快，補救措施就越便宜，影響也就越有限。 將源代碼質量評估作為產品開發過程的核心，使團隊能夠集中註意力，協調利益相關者，降低風險，並為產品提供最大的成功機會——這是每個產品經理的工作。