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