DevOps 技術：代碼可維護性
運行我們構建的系統需要大量代碼：Android 作業系統運行 1200 到 1500 萬行代碼，Google 的單一代碼庫包含超過 10 億行代碼，典型的智慧型手機應用包含 50,000 行代碼。
基於 DevOps 研究和評估組織 (DORA) 研究的 2019 年 DevOps 現狀報告表明，團隊有效維護代碼的能力是眾多可積極促成持續交付取得成功的技術實踐之一。
如果您的團隊在代碼可維護性方面表現良好，則滿足以下條件：
團隊可輕鬆在代碼庫中找到示例，重複使用其他人的代碼，並在必要時更改其他團隊維護的代碼。團隊可以輕鬆地將新的依賴項添加到其項目，以及遷移到新的依賴項版本。團隊的依賴項穩定，並且很少破壞代碼。這些發現結果突顯了開發者可輕鬆地在整個組織的代碼庫中找到、重複使用和更改代碼，以及實現相關實踐和工具來幫助依賴項管理的重要性。
代碼可維護性是一項需要組織範圍協調的功能，因為它依賴於能夠搜索、重複使用和更改其他團隊的代碼。有效管理依賴項通常是在使用大型代碼庫和應對大型組織時遇到的主要難題。有助於避免依賴項出現問題或說明代碼更改後果的工具可以為所有工程師改進設計決策和代碼質量，從而有助於他們提高工作速度並打造更穩定可靠的軟體。
如何實現代碼可維護性
就實現而言，雖然可以分開進行原始碼管理和依賴項管理，但一個解決方案（例如單一代碼庫或 Google 使用的 monorepo模式）可以同時解決這兩個問題。
首先，原始碼管理。如果讓每個人都可以輕鬆找到、重複使用和建議對代碼庫的任何部分進行更改，那麼就可以：
加快交付：為了快速交付軟體，團隊需要能夠查看和建議對彼此代碼的更改。儘早執行此操作有助於在整個組織內傳播知識，並且有助於將需要更改代碼庫其他部分的團隊取消屏蔽，以便他們完成工作。提高穩定性和可用性水平：如果發生突發事件，能夠快速找到並建議對代碼庫任何部分的更改至關重要。提高代碼質量：重構代碼以提高內部質量，通常需要更改代碼庫的多個部分。如果這樣做很困難，則會降低人們執行重構的可能性，也會增加這樣做的費用。一些組織（包括 Google）運行跨團隊代碼維護項目，其中個人負責在代碼庫中修復維護級層項，而這依賴於可以在組織中輕鬆訪問和更改代碼。能夠找到示例並重複使用其他人的代碼取決於能夠輕鬆訪問和搜索整個組織的原始碼。實現此要求的最簡單方法是針對整個組織的代碼使用單個版本控制平臺，即使該代碼在平臺內拆分為多個代碼庫也是如此。使用的版本控制平臺越分散，就越難找到代碼。
某些組織可能希望鎖定代碼庫部分，以便只有需要知道的人才能查看該代碼庫的該部分（Google 就是這樣的組織）。理想情況下，這應該是例外（而非規則），並且應將軟體設計為可最大限度地減少機密原始碼表面。在很多情況下，使用版本控制系統的訪問權限控制機制對機密代碼進行邏輯隔離就足夠了。
您還應能夠更改其他團隊維護的代碼。通常，此類更改將需要獲得負責維護相關代碼的團隊批准。如果使用拉取請求（即在版本控制中創建分支和批准導致合併分支）等機制，可最大限度地減少允許其他團隊建議更改的摩擦，同時也可防止未經授權的更改，並強制執行信息安全控制（例如職責分離）。
接下來，考慮依賴項。讓團隊能夠輕鬆添加和更新依賴項，並確保它們穩定且很少破壞代碼，這意味著：
提高安全性：隨著依賴項老化，就越有可能發現漏洞。保持依賴項最新很重要，特別是在發現並修補漏洞之後。加快交付：使用其他團隊或組織開發的庫意味著您無需編寫自己的代碼即可執行該操作。當您部署了一些機制來確保依賴項穩定並很少破壞代碼後，可以將更多時間花在編碼上，縮短維護時間。依賴項管理是軟體開發團隊的常見痛點。在應用之間保持依賴項最新和一致很複雜、耗時且成本高昂。許多組織無法為此任務分配足夠的資源，這一問題因流程和工具不足而加劇。當在依賴項中不可避免地發現漏洞時，這可能表示嚴重的安全風險，並且必須更新使用依賴項的應用。
務必採用並改進相關流程和工具，讓團隊能夠輕鬆使用已知良好的依賴項版本並快速升級這些依賴項，包括自動化持續集成 (CI) 和測試，以發現新版本的依賴項是否包含破壞性更改，並快速且簡單地將正在使用的依賴項的版本與使用這些版本的系統相關聯。
在軟體中添加依賴項時有兩種常用的模型：vendoring 和聲明式清單。在 vendoring 中，會將每個依賴項的原始碼或二進位文件隨應用一起籤入版本控制中。或者，大多數現代平臺都有一個依賴項管理工具，用於管理籤入版本控制的聲明式清單文件中指定的依賴項（例如 Python 的 pip、Node.js 的 npm、R 的 CRAN 和 .NET 的 NuGet）。
無論您是使用 vendoring 還是使用清單，最重要的注意事項都是：
可追溯性：確保您可以從任何給定的軟體包或部署追溯到用於構建它的每個依賴項的確切版本。否則，將無法調試因依賴項更改而導致的問題。可再現性：您的構建過程應儘可能具有確定性。嘗試調試在不同機器上具有不同行為的構建過程引發的問題非常困難。在 Google 中實現代碼可維護性
Google 通過相對不同的方法實現代碼可維護性。雖然我們的方法需要權衡利弊，且並非適合所有人，但這樣做可以有效地讓團隊實現本文中所述的目標。
全球有 95% 的 Google 軟體開發者使用主幹開發模型，處理通過集中式原始碼控制系統維護的共享單一代碼庫。2016 年，Google 代碼庫包含「大約 10 億個文件，其中包括 Google 成立 18 年以來大約 3500 萬次提交的歷史記錄。該代碼庫包含 86 TB 的數據，其中包括大約 20 億行代碼，分布在 900 萬個唯一原始碼文件中」。
由於所有 Google 代碼都保存在一個代碼庫中，因此可以輕鬆找到和更改其他團隊的代碼。Google 提供內部搜尋引擎，使您可以輕鬆地搜索整個代碼庫。開發者可通過各種工具創建更改列表以供審核和批准。系統會針對每個更改列表運行測試，並且可以對更改列表進行更新和評論。與許多其他平臺類似，Google 的代碼審核工具可以向審核者建議任何給定更改。Google 代碼庫中的每個目錄都有一個 OWNERS 文件，其中列出了可以批准該目錄中的文件更改的個人或組（類似功能在 GitHub、GitLab 和 Bitbucket 中有提供）。快速搜索、審批者建議和自動化測試，使得建議更改、審核和協作變得簡單而強大。
藉助這些工具，更改代碼庫多個部分的大規模重構相對容易執行並且能夠以原子方式完成。Google 構建的工具可進一步簡化和自動化執行會影響代碼庫重要部分的更改的過程。Google 工具包含一個名為 Blaze 的構建系統，用於構建和測試來自原始碼的任何更改，包括依賴項。（Blaze 部分以開源工具 Bazel 的形式發布。）Google 中的每個人都可以輕鬆發現並建議對 Google 的任何部分進行更改，包括其基礎架構配置，這些配置也保存在同一單一代碼庫中。代碼共享和重複使用很簡單。
Google 提供了一些控制措施來管理開源軟體的依賴項。首先，Google 使用的所有開源軟體都必須將其原始碼籤入 Google 單一代碼庫。其次，任何時候都只能將給定庫的一個版本籤入原始碼控制。第三，所有軟體都是靜態連結並基於原始碼構建。最後，只要庫的原始碼發生更改，就會觸發所有使用該依賴項的軟體的重新構建和自動化測試。
通過這些控制措施及 Google 強大的 CI 基礎架構，您可以輕鬆讓生產系統保持最新狀態，並確保使用新版本的依賴項。它們還有助於確保所有系統都使用給定庫的一致版本（消除了「鑽石依賴項」地獄的可能性，即產品依賴於兩個組件，而這些組件又依賴於不同版本的通用庫，使得無法構建產品。）
Google 管理外部代碼依賴項的的方法權衡是更難以添加新依賴項（代碼可維護性的主要結果之一）。任何新依賴項都必須將其原始碼籤入 Google 單一代碼庫，這意味著，在最初和任何升級時，都必須先審核和測試代碼。但是，這種嚴謹級別有助於防止將存在安全漏洞的代碼放入 Google 產品，並確保所有依賴項也明確指定了維護者。
實現代碼可維護性的常見誤區
讓所有人都可以全面搜索和更改所有代碼的主要障礙是工具支持和組織文化。
第一個常見誤區是多個版本控制代碼庫或具有嚴格訪問權限設置的版本控制代碼庫。理想情況下，組織應該有一個版本控制平臺，其中包含所有代碼。默認訪問權限最好允許組織中的任何人查看任何原始碼文件，並且可以限制對敏感文件的訪問。還應有一種方法來搜索版本控制。
相比之下，組織通常限制誰可以更改版本控制。這會導致第二個誤區：缺少工具和流程，導致用戶無法更改代碼庫中自身沒有寫入權限的部分。對於解決您依賴其代碼的其他團隊通常無意中造成的問題，這通常是一個重大障礙。這也會阻止涉及代碼庫多個部分的重構。
為了緩解此問題，一些現代版本控制工具提供了一種方法來提交、覆核、審批和審核代碼庫中用戶沒有寫入權限的部分的更改請求。
即使提供工具支持，組織也需要對在組織內提供和搜索代碼庫放心，甚至也對供應商和承包商放心。如果組織的版本控制代碼庫包含大量機密信息和不能在團隊之間共享的代碼，則可能無法實現這一點。
使用二進位文件依賴項更為常見，但每種語言都有各自用於管理二進位依賴項的工具鏈。創建標準策略和慣例以在組織的整個軟體產品組合中跨這些工具鏈有效地管理和跟蹤依賴項是一項複雜的工作。需要對 CI 基礎架構進行重大投資，讓您可以輕鬆測試新版本的庫是否與現有系統兼容，以及是否有漏洞，才能簡化定期升級第三方庫的流程。
實際上，大多數組織都會讓團隊來管理依賴項，導致結果差異很大。因此，如果在庫中發現漏洞，快速且可預測地做出響應通常是非常麻煩的：即使找到受影響的服務通常也是一個重大的考古項目。
如何衡量代碼可維護性
下面是一些有助于衡量代碼可維護性的簡單方法：
貴組織的代碼庫有多少百分比是可搜索？要更改我沒有寫入權限的代碼庫部分，中位數完成時間是多少？我們的代碼庫有多少百分比是重複代碼？未使用的百分比是多少？在使用的所有庫中，有多少百分比的應用未使用最新的穩定版本？我們在生產環境中具有每個庫的多少個不同版本？中位數是多少？良好的目標是什麼？有多少個版本超過 1 年？團隊升級其庫的頻率如何？這需要多長時間？在考慮要衡量的項目時，有三個用例需要重點關注：
管理技術和設計債務變更管理（包括緊急變更）修補漏洞。隨著代碼庫的增長，技術債務是一個重要顧慮。隨著組織以及組織及其客戶依賴的產品不斷發展，能夠重構和重新設計代碼非常重要。對於大型代碼庫，這可能很複雜且令人煩惱，同時缺少重要工具支持。能夠識別未使用的代碼、重複代碼、測試覆蓋率不佳的代碼或包含漏洞的代碼也很重要。第一步是確保您的工具可讓您建立和跟蹤指標，以識別有待改進的方面並以此為基礎安全地採取行動。
其次，變更管理。當有人對代碼庫部分進行更改時，您的工具在多大程度上有助於檢測此更改的影響？如果另一個團隊受到影響，那麼他們多快可以採取行動來補救問題，尤其是修復位於代碼庫的其他區域時？如果必須進行緊急變更，那麼在代碼庫中對代碼進行所需變更、測試和發布需要多長時間？
建立和跟蹤指標，以便跟蹤更改在流程中傳播所需的時間。然後找出瓶頸並努力改進您的流程，並在適當時添加工具支持。請注意「緊急」流程，以免為了獲得速度而繞過驗證和審批，目標應是確保您的常規流程既可靠又足夠快速，以便在緊急情況下有效。
修補漏洞是尤為重要的變更管理場景。如果在庫中發現漏洞，需要多長時間才能發現和修補使用易受攻擊庫版本的軟體？如果您不確定，不妨定期測試一下。鑑於處理漏洞以及數據和代碼滲漏的可能產生的大筆費用以及此類攻擊的發生頻率，通常有必要投入大量資源來確保您依靠的第三方軟體是最新並且在發現漏洞時可以輕鬆升級。
未完待續。(轉自DevOps教練）