11 月 22 日，由 CODING 主辦的 DevOps 技術沙龍系列「品質」專場在上海圓滿結束。在活動現場，四位來自騰訊等知名企業的技術大咖們分享了研發品質與效能的實戰經驗，與觀衆們共同探讨如何采取有效手段以保證和提高軟體品質。
本期沙龍回顧為大家帶來的，是來自騰訊雲 CODING 布道師楊周的議題——《DevOps 代碼品質實戰》。
随着團隊成員增多，每個人在縮進、換行、空格以及大小寫方面有不同的習慣，導緻代碼越來越亂。代碼風格問題尚且不緻命，更嚴重的是這些問題：
Hard code：在代碼中書寫各種環境配置、連結、密鑰，導緻安全風險
魔法數字（Magic Number）：難以了解和維護
代碼行數過多：難以維護，違反面向對象的 SOLID 原則
不少業界大廠公布了代碼規範，推薦大家直接采用，因為自己發明規範往往不夠全面，很難服衆。
代碼規範不隻是縮進換行問題，通過強制限制圈複雜度、檔案行數和方法行數，可促使大家按照面向對象的方式設計。
有了代碼規範，但怎麼落地？是很多團隊面臨的問題。Lint 程式用來檢查代碼規範，各個語言（比如 Kotlin、Java、PHP）都有自己的規範和 Lint。
自動檢查代碼規範有三個時機：
IDE：最實時友善的，但需要所有人進行配置、某些 IDE 可能不支援
Git commit Hook：送出時，會調用指令行工具強制檢查，優點是非常及時，然而存在可被删除的風險
服務端：在 Git push 之後，在服務端進行檢查，很可靠，但缺點是不夠實時
是以，建議同時使用這三種方式。
在代碼檢查之後，如何處理？老項目有成千上萬處不規範，很顯然不能一次清理幹淨，讓所有人停下老項目去清理老代碼并不現實，而且一次改動太多檔案的風險也很高。是以建議使用增量檢查，尤其是 Java 增量檢查方案比較複雜，詳情可識别下圖二維碼閱讀 CODING 文檔。
服務端檢查：建議使用持續內建（持續不斷地把代碼內建到主幹，實作品質内建）。流程為：鎖定 Git 主幹，所有人開發功能拉取小分支，小分支送出後觸發持續內建進行代碼規範檢查，通過之後再通知同僚進行代碼評審，通過這套流程來提高代碼品質。CODING 持續內建相容 Jenkins，圖形化界面易上手，如果項目已經在用 Jenkins 可平滑遷移。
很多項目到最後面臨的困境——沒有人敢改老代碼。比如開發人員會把已有函數如get() 複制一份再修改，變成了 get1()、get2()，這種做法導緻項目逐漸潰爛。根源在于沒有人知道修改老代碼會不會導緻其他地方調用出錯。
在開發和測試分離的團隊架構中，一個負責任的開發者在寫了代碼之後要自測，然後提測給測試人員。但是後期大家逐漸會變得不耐煩，從自測 10 種情況到 5 種情況，再到隻測一種，最後到完全不自測直接提測，所有的壓力都慢慢轉移到了測試人員身上。負責任的開發逐漸變成不負責任的開發，問題還是出在機制上。
國外十幾年前就開始這個方案：測試人員轉崗學程式設計開發，僅保留少部分的人工測試。開發人員自己寫測試代碼，測試覆寫率不達标（比如 80%）則禁止合并。
開發人員如何對自己的代碼有信心？不是靠聰明才智，因為人總會百密一疏，即使頂尖的程式員也可能會犯最初級的問題，是以自己寫測試代碼才是最可靠的方案，測試代碼覆寫了多種邊界情況，即使其他人來改寫代碼也無需擔心挂掉。
自動化測試很好，但是也面臨困境：業務太忙，沒有時間寫測試代碼。
從個人職業發展的角度，把手動操作 Postman 自測的時間用來寫自動化測試代碼，這樣一來，自己的水準得到了提高，後續改代碼的時候重測時間也得到了節省，不再是一直堆業務代碼，難以成長。
以前中國的大公司項目品質普遍十分糟糕，因為前 20 年是 2C 的紅利期，大家在快速搶占市場，但現在到了守地盤的時候，這兩年大公司開始重視代碼品質問題，建議大家為這個機遇早做準備。
從公司角度，主要看時機。比如 2C 項目逐漸成熟，使用者量變大，線上的故障損失已經大于多招開發人員的成本，或者随着項目功能逐漸增加，回歸測試時間越來越長，如果一個網站一天上線多次，一天把整個網站所有功能測過來是不實際的，是以自動化測試才能保障持續的高上線頻率。而 ToB 項目初期出現了嚴重 bug 可能就要賠償客戶，是以初期就需要自動化測試。
代碼品質評級标準：從下圖中可以看到，“優”級别的代碼品質标準圈複雜度最多允許 5，類行數不能超過 50，函數行數不能超過 10，測試覆寫率需達到 90%。CODING的合作夥伴優普豐提供了 CSD 認證教育訓練，能夠幫助開發者們達到相應的标準，可識别二維碼了解詳情。
那麼本次的分享就到這裡，大家可以前往 B 站觀看演講視訊并擷取完整 PPT，或者前往 CODING 了解更多。