個人高質量軟件發佈心得

譯者按: 好好寫代碼，充分作測試，和小夥伴溝通清楚，灰度發佈，上線後要有監控和一鍵啓停。

• 原文: A framework for shipping high quality software)
• 譯者: Fundebug

爲了保證可讀性，本文采用意譯而非直譯，而且對源代碼進行了大量修改。另外，本文版權歸原做者全部，翻譯僅用於學習。

不管是軟件攻城獅仍是技術主管都爲了一個共同的目標：準時發佈高質量的產品。可是各類雄心勃勃的需求，嚴格的截止日期和以前沒有理清楚的技術債總會打亂開發團隊本來規劃好的任務優先級。不過，軟件質量很重要，不然無數的bug將會讓開發團隊忙得一團糟，是的本來就很緊張的開發日程變得更加緊張。

這篇博客提出了一個用於穩定發佈高質量軟件的模式。

來源

這個框架式是我在開發一個超級具備挑戰的項目中所積累下來的。個人目標是讓一個網站應用能夠全球訪問，要知足可擴展性和可信性。這樣一個簡單的目標卻花了咱們好幾個月的時間，並要完成一下任務：

• 從單一服務器擴展到服務器集羣
• 橫跨全部微服務，對平臺級的基礎性服務作改動
• 一直保持和不一樣的團隊協做來得到更多的看法

全部的服務部署都要無縫銜接，不然服務將會宕機。

拉姆斯菲爾德(Donald Rumsfeld)會怎麼作？

姆斯菲爾德是誰？

Donald Rumsfeld爲德裔美國人，1954年畢業於普林斯頓大學，同年開始在美國海軍服役，1962年當選爲伊利諾州的共和黨聯邦衆議員，此後4次當選連任。1969年辭去聯邦衆議員職務，加入理查·尼克松總統內閣，成爲白宮經濟機會辦公室的主任和總統助理。1973年出任美國駐北約大使，1974年被拉爾德·福特總統任命爲白宮辦公廳主任。1975年被任命爲國防部長，成爲美國曆史上最年輕的國防部長。2001年再度出任美國國防部長，由此成爲史上最年長的國防部長。

前國防部長拉姆斯菲爾德在83歲時曾這樣說到：」人生足跡遍及商場、戰場和政界的我，決定嘗試開發一款移動遊戲應用。「

他不是一個專業的軟件開發者，不過他下面這段話卻十分中肯：

There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don’t know. But there are also unknown unknowns. There are things we don’t know we don’t know.

這是哲學裏面Johari window的一個簡化版本。咱們將它應用到軟件開發，以下表：

標題	開發者知道的	開發者不知道的
其餘開發者知道的	你們都知道	不知道你們知道
其餘開發者不知道	知道你們不知道	全部人都不知道

你們都知道

需求特性、已經發現的bugs、用戶的需求等等，這些都是咱們都知道的。可是，一個用代碼實現的特性並不必定按照預想的行爲來。好比，沒有測試的代碼能夠歸類到」知道你們不知道「，直到你十分清楚代碼的工做原理，並把文檔寫清楚。

你認爲代碼會按照你寫的行爲執行是一回事，如何證實的確是這樣是另外一回事。單元測試，功能測試，甚至手動的單步調試來增長你知道的部分，減小不知道的部分。

知道你們不知道/不知道你們知道

我將這兩條合併到一塊兒，由於它們是相關的。

1. 知道你們不知道

   這部分是指開發者本身很清楚，可是一塊兒工做的其餘開發者不知道。一個好的例子就是：建立了一個新的API代替了原來的舊的的功能，可是另外一個開發者還一直在用舊的API；另外一個例子是：將某些共有的代碼的行爲修改了。

2. 不知道你們知道

   這部分是指開發者不知道團隊裏面其餘開發者知道。舉個例子：一個對核心部件看似很小的更新，可能會連鎖式的觸發其它隊友們重寫不少代碼。或則只有幾個攻城獅才知道的奇怪的特性之類的。

清晰的溝通很重要！甚至能夠過分溝通也不要緊！勤發郵件，常常檢查設計，保持和用戶溝通。若是要作一些大的設計變更，做爲一個開發者/團隊領導/管理人員，你須要花充分的時間和用戶溝通，充分理解他們的使用場景。經過用戶訪談，能夠優化設計，也能夠提早防止將來可能出現的問題。

全部人都不知道

這是最具備挑戰的部分。目前尚未一個模型能夠爲哪些不可預測的事件作準備 -- 比較它從未發生過。那些不知道包括：黑客攻擊，數據丟失，盜竊，蓄意破壞，軟件bug等等。不要爲此苦惱，咱們能夠用兩個指標來量化：1. 平均修復時間(mean time to repair)；2. 平均檢測時間(mean time to detect)。

最好的辦法就是保證這兩個時間儘可能小。能夠想象一下修復數據破壞耗費5分鐘和一個小時對業務的影響。

1. 平均檢測時間

一個監控系統是頗有必要的，那些基本的指標(內存、CPU、硬盤讀寫率等)，HTTP請求狀態(500、400等)和其它。最好的狀況是：一個有問題的發佈立馬觸發報警發送給管理員。這樣保證及時對問題做出反應，並迅速恢復。（線上bug能夠用咱們fundebug實時監控喔）

2. 平均修復時間

在系統裏面對某些屬性配置一個開關，若是該屬性在某次發行致使嚴重問題，能夠當即將其關閉來防止形成嚴重損害。

另外，你須要有一個敏捷發佈系統。若是你花兩天時間才能成功把修復發佈出去，那麼你的平均修復時間則是2天+。你須要優化整個發佈流程。

還有什麼要說的？

在攻城獅發佈一個核心更新以前，必定要問本身這幾個問題：

1. 是否有充分的日誌監控系統來方便debug？
2. 對於那些有風險的特性，是否有配置一個線上開關？若是遇到情況，須要花多久時間才能關閉？
3. 一個特性發布後，若是出了情況，是否有足夠的指標來輔助分析？

在此推薦一個發佈方法：灰度發佈。

關於Fundebug

Fundebug專一於JavaScript、微信小程序、微信小遊戲、支付寶小程序、React Native、Node.js和Java實時BUG監控。 自從2016年雙十一正式上線，Fundebug累計處理了9億+錯誤事件，獲得了Google、360、金山軟件、百姓網等衆多知名用戶的承認。歡迎免費試用！

版權聲明:

轉載時請註明做者Fundebug以及本文地址：

https://blog.fundebug.com/2017/09/27/a-framework-for-shipping-high-quality-software/