我的高質量軟體釋出心得
譯者按: 好好寫程式碼，充分做測試，和小夥伴溝通清楚，灰度釋出，上線後要有監控和一鍵啟停。
為了保證可讀性，本文采用意譯而非直譯，並且對原始碼進行了大量修改。另外，本文版權歸原作者所有，翻譯僅用於學習。
無論是軟體攻城獅還是技術主管都為了一個共同的目標：準時釋出高質量的產品。但是各種雄心勃勃的需求，嚴格的截止日期和之前沒有理清楚的技術債總會打亂開發團隊原本規劃好的任務優先順序。不過，軟體質量很重要，否則無數的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、使用者的需求等等，這些都是我們都知道的。但是，一個用程式碼實現的特性並不一定按照預想的行為來。比如，沒有測試的程式碼可以歸類到”知道大家不知道“，直到你十分清楚程式碼的工作原理，並把文件寫清楚。
你認為程式碼會按照你寫的行為執行是一回事，如何證明的確是這樣是另一回事。單元測試，功能測試，甚至手動的單步除錯來增加你知道的部分，減少不知道的部分。
知道大家不知道/不知道大家知道
我將這兩條合併到一起，因為它們是相關的。
-
知道大家不知道
這部分是指開發者自己很清楚，但是一起工作的其他開發者不知道。一個好的例子就是：建立了一個新的API代替了原來的舊的的功能，但是另一個開發者還一直在用舊的API；另一個例子是：將某些共有的程式碼的行為修改了。
-
不知道大家知道
這部分是指開發者不知道團隊裡面其他開發者知道。舉個例子：一個對核心部件看似很小的更新，可能會連鎖式的觸發其它隊友們重寫很多程式碼。或則只有幾個攻城獅才知道的奇怪的特性之類的。
清晰的溝通很重要！甚至可以過度溝通也沒關係！勤發郵件，經常檢查設計，保持和使用者溝通。如果要做一些大的設計變動，作為一個開發者/團隊領導/管理人員，你需要花充分的時間和使用者溝通，充分理解他們的使用場景。通過使用者訪談，可以優化設計，也可以提前防止未來可能出現的問題。
所有人都不知道
這是最具有挑戰的部分。目前還沒有一個模型可以為哪些不可預測的事件做準備 -- 比較它從未發生過。那些不知道包括：******，資料丟失，盜竊，蓄意破壞，軟體bug等等。不要為此苦惱，我們可以用兩個指標來量化：1. 平均修復時間(mean time to repair)；2. 平均檢測時間(mean time to detect)。
最好的辦法就是保證這兩個時間儘量小。可以想象一下修復資料破壞耗費5分鐘和一個小時對業務的影響。
-
平均檢測時間
一個監控系統是很有必要的，那些基本的指標(記憶體、CPU、硬碟讀寫率等)，HTTP請求狀態(500、400等)和其它。最好的情況是：一個有問題的釋出立馬觸發報警傳送給管理員。這樣保證及時對問題作出反應，並迅速恢復。（線上bug可以用我們fundebug實時監控喔）
- 平均修復時間
在系統裡面對某些屬性配置一個開關，如果該屬性在某次發行導致嚴重問題，可以立即將其關閉來防止造成嚴重損害。
另外，你需要有一個敏捷釋出系統。如果你花兩天時間才能成功把修復釋出出去，那麼你的平均修復時間則是2天+。你需要優化整個釋出流程。
還有什麼要說的？
在攻城獅釋出一個核心更新之前，一定要問自己這幾個問題：
- 是否有充分的日誌監控系統來方便debug？
- 對於那些有風險的特性，是否有配置一個線上開關？如果遇到狀況，需要花多久時間才能關閉？
- 一個特性發布後，如果出了狀況，是否有足夠的指標來輔助分析？
在此推薦一個釋出方法：灰度釋出。
關於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/