CODING DevOps 系列第四課：DevOps 中的質量內建實踐

什麼是質量內建

隨着時間的推移，咱們項目的開發效率會逐漸下降，直到幾年以後整個項目可能就沒法維護，只能推倒重來。具體的表現首先就是隨着時間推移，咱們會發現整個需求列表裏面能作的需求愈來愈少，由於每當咱們增長一個新特性，須要改動的代碼就很是多，因此最後每提出一個新的需求，團隊評估出來的改動成本都很是高，致使最後難以增長新的特性。

第二個表現就是缺陷難以修復。咱們作出來的系統只要有人用就會有反饋一些線上的故障，一開始代碼很簡單的時候修復起來是很快的，可是隨着代碼愈來愈複雜、代碼行數愈來愈多，咱們會發現定位問題太難了。尤爲是如今咱們的項目採用的是很是複雜的架構，因此當用戶線上報錯的時候，咱們很難去定位到是哪裏出了問題。但其實只要定位到了問題，修復起來是很快的。

第三個表現咱們稱之爲「打地鼠現象」，簡單來講就是當你「按」下一個缺陷的時候，又會蹦出來幾個新的缺陷。這樣會致使你們在工做的過程當中壓力很是大、心情也會比較沉重。

因此對於這些挑戰，咱們也有想辦法去解決，CI、CD 以及 DevOps 的出現都讓咱們看到了很好的方向。可是我看到不少團隊其實只是靠 DevOps 解決了一些基本的問題，並無解決核心的問題。這是爲何呢？由於核心問題主要是靠開發人員的能力提高來解決的，但因爲改變一我的是很難的，因此企業每每會繞開這些問題。因此我今天分享的內容主要會涉及到開發人員如何去寫代碼等一些實踐。

咱們在剛開始啓動一個項目的時候，咱們會制定一些代碼規範，因此代碼相對來講是比較清晰的。可是隨着需求的演變，在實現這些需求的時候，每一個人都會選擇最低成本、最保險的方式。這就會致使沒有人敢去大幅度地改動代碼，只會在裏面追加一些代碼，形成了代碼裏面有大量的重複、過長的方法。同時開始的時候設計的架構也是很是清晰的，可是若是後續沒有很好的落地、監控、自動化地發現問題，架構就會在這過程當中腐化，變得一團亂。

Deming 先生曾提出「問題發現得越早，修復的成本越低」，這句話也是咱們去下降軟件開發成本、更高效地保證質量的重要原則。因此咱們採用質量內建的方式，能夠把整個軟件質量的保障內嵌到開發的過程當中去，而不是留到後面再去檢測，由於越日後修復的成本越高。

85% 的缺陷都是在代碼編碼階段引入的，然而大部分的缺陷並非在編碼的時候發現的，而是在後面的單元測試、功能測試、集成測試發現的，越日後發現的缺陷越多。按照剛剛那個原則，假如在編碼階段發現的缺陷只須要 1 分鐘就能解決，那麼單元測試階段須要 4 分鐘，功能測試階段須要 10 分鐘，而到了上線以後再發現可能就須要 640 分鐘，這個成本是很是高的。

那麼質量內建的方式是怎麼樣的呢？首先咱們經過自動化測試、重構、簡單設計等手段，可使在編碼階段引入的缺陷變少，由於咱們代碼寫清楚了，bug 就藏不住了。同時當咱們作到自動化測試等工做時，在編碼階段發現的缺陷也變多了。那麼經過質量內建，咱們在編碼階段就把大部分的問題都捕獲到，同時引入的缺陷也更少，它就下降了軟件的開發成本。

你們可能會有一個疑惑，就開始開發人員本來只用寫功能就好了，如今卻還要寫測試代碼，並且測試代碼的比例和實踐代碼的比例不必定，這樣會不會增長成本。這裏想跟你們說一下，不少人會把咱們編寫代碼的時間當成整個軟件開發的時間，其實不是。在編寫玩代碼以後，還得開發自測，而後還要去聯調，以後還要進行內部測試、線上故障修復等，因此整個軟件開發有這麼多的過程，而咱們如今解決問題的辦法是在第一階段投入更多的時間，作更多的測試、更多的代碼優化等，從而減小後面所要花費的時間。根據剛剛說的修復時間越晚，成本越高的原則，咱們這樣作是划算的。

技術債與質量門禁

技術債是什麼呢？債是一種比喻，與咱們金融方面所說的債務意思相同，那麼在咱們技術範疇裏面也有這樣的債務問題。在咱們編寫代碼的過程當中留下了一些重複的代碼，或者沒有起好名字、沒有給出註釋，相似這樣的問題就是咱們欠下的技術債。

對比金融裏的債務，技術債也有相應的特性。首先這個債咱們必須得還，不然到了後面越欠越多可能會把整個團隊壓垮了，致使你們沒有動力去開發新的功能。同時技術債是有利息的，假如最開始寫代碼的人留下了問題沒有去解決，那麼下一個接手這個代碼的人可能就無法理解這個代碼，就不敢大膽地去改代碼，越晚就越不敢。

既然技術債存在這麼多問題，你們爲何還要去欠債呢？由於技術債也有好處，有的時候咱們要作的產品並非一個很是靠譜的產品，咱們就會追求更快，用一個比較粗糙的手段作完交給客戶去進行測試。獲得反饋以後，靠譜的話咱們就會用心去優化、迭代；不靠譜的話咱們就會放棄這個項目，這是它的成本也很低。因此因爲互聯網行業的這種快節奏，人們會傾向於欠下不少的技術債務，從而快速試錯。當我獲得反饋，確認用戶的痛點以後再來進行代碼的優化。固然我今天更想講的咱們爲何會欠下債務，其實仍是是由於態度以及習慣問題。若是咱們能改掉咱們的壞習慣，咱們就會少欠下一些技術債。

當咱們搭建好一個項目的基礎框架，寫了一些示例的代碼，後面就會上不少的人來作一些新需求。這個時候就會出現「失控」，咱們會發現一開始的代碼很是整潔，可是人一多以後就會造成「破窗效應」——簡單來講就是一旦一扇窗戶上出現了一個破洞，那麼很快上面的破洞就會愈來愈多。代碼庫也是如此，當一我的沒有按照規範寫代碼，同時沒有人制止，那麼很快其餘人也會紛紛開始這樣作，很快代碼就會變得亂七八糟。

那麼應對這種「破窗效應」的方法就是「童子軍軍規」，就是無論原來的質量怎麼樣，咱們也得保證咱們接手處理完以後，代碼的質量要比原先好上一點、乾淨一點，哪怕是改一個變量命名也好，改一個格式也好，人人都這樣作的話咱們的代碼庫就會愈來愈乾淨、質量愈來愈高。這種方式就是咱們所謂的「質量門禁」。

接下來說一下償還技術債，首先第一點是並不是全部技術債都應償還，或者說技術債的償還應該有一個優先級，咱們更應該關注的是那些頻繁地須要變動的代碼。第二點是應用童子軍規則，也就是有債就還，不要拖欠過久，保證每次提交代碼的時候比接手時要乾淨一點。第三點是先償還高息技術債，就是看哪些問題不處理的話帶來的後果會更嚴重，咱們就優先處理這些問題。接着是分期償還技術債，將咱們的技術債管理起來，每次迭代的時候就一邊作有客戶價值的工做，一邊償還技術債。這裏很關鍵的就是不能依賴開發人員的自覺性，而是在迭代的時候就要明確那哪一塊要優化、要重構，分到我的的頭上，同時後面要進行評測、驗收，通過這樣一個流程正式地去對待技術債。

自動化

自動化是一個實踐，咱們常常會聽到像自動化發佈、自動化打包、自動化構建、自動化測試等，尤爲是自動化測試是一個反覆被強調的一個實踐。咱們的流水線其實整個都是自動化的，構建是自動化的，檢查是自動化的，包括後面的測試和部署也都是自動化的。

有一個原則叫自動化一切，就是「一切能被自動化的都應該被自動化」。除了常見的編譯、檢查、測試和部署，服務器的配置也能夠進行自動化，甚至業務上的一些部署，好比一些遷移之類的，能自動化的咱們都把它自動化。咱們做爲開發人員，最擅長的其實就是寫代碼，不少人會以爲本身的工做沒什麼挑戰，這是由於你每天都在手工地作一些重複的事情，固然沒有挑戰了。這時候你能夠嘗試去自動化一些事情，你會發現很好玩，也能學到新的東西，我的能力能獲得成長，同時作的事情也有價值。

我體會到自動化的幾個好處，跟你們分享一下。第一個是沉澱知識，就是把知識沉澱到了自動化的腳本里面，而不是存在於某我的的腦子裏。而對於掌握知識的這我的來講，他也減小了被打斷的可能。第二點就是自動化可以提升效率，解放生產力，這一點實際上是一個很明顯的好處，原來手工要花五個小時的事情，自動化可能幾分鐘就跑完了。最後一點就是固化流程，下降出錯率。也就是將咱們的這個流程固化下來了，本來一件事情今天是 A 作，明天是 B 作，他們在作的時候可能就基於本身的理解來作，中間就會引入一些錯誤。而自動化就能夠規避這種問題。

其餘有效實踐

①結對編程：結對編程是我很是推崇的實踐，不少人認爲結對編程就是一我的寫一我的看，這樣就浪費了一我的，其實不是的。其實結對編程有點像汽車拉力賽，領航員會看地圖而後告訴 driver 前方的路線，例如前面的彎道該怎麼走，因此他的視野會更加宏觀，看得更遠，也有助於對咱們的 driver 作一個思惟上的引導。寫代碼的時候也是這樣的，操做鍵盤的人在考慮代碼該怎麼敲，而另外一我的則是在引領思路，因此他倆是在互相配合的。

②代碼評審：代碼評審就是你們坐在一塊兒，分享代碼的收穫、踩過的坑以及解決問題的方法、技巧。這是一個開發人員的交流活動，而不是一個相似於質量門禁的東西，這是有溫度的一場交流、分享，傳播有價值的東西。

③暴徒式編程：暴徒式編程是結對編程的一種方式，由一我的操做鍵盤，同時設置定時，每隔一段時間換人。其餘人就負責盯着大屏幕告訴他該怎麼操做，這個也是一個很好的學習手段。

小波老師將在完整視頻中繼續爲你們帶來
更多精彩分享以及重構的在線演示
點擊觀看完整視頻