要一直能回退代碼。確保所有的版本都能夠回退，在一個階段或QA環(huán)境中，要實踐回退功能。在生產(chǎn)環(huán)境中，當必須用它解決突發(fā)事件時，要使用回退功能整理代碼，制定幾個簡單的流程，確保能夠回退自己的代碼。
如果你還沒有經(jīng)歷過不能回退系統(tǒng)的痛苦，那么如果繼續(xù)玩火，不停地迅速修復系統(tǒng)，遲早會遇到這種問題。不要用應用太復雜或者代碼發(fā)布太頻繁作為借口，拒不加入回退代碼的功能。一個明智的飛行員，如果沒有具備讓飛機著陸的能力，就不會讓飛機起飛。一個明智的程序員，如果不能讓系統(tǒng)在緊急情況下回退代碼，就不應該發(fā)布代碼。

為了給接下來要講的原則制造氣氛，我們應該在深夜圍坐在一堆篝火周圍講恐怖故事。我們要講的是經(jīng)典的恐怖故事，就是人們在房子里聽到了恐怖的聲音但并不逃跑的事。那些忽視所有警告信號的傻瓜就是我們。作為程序員的上司和CTO，我們收到過幾平每個經(jīng)理架構(gòu)師和程序員的匯報:應用太復雜了，不能進行回退。我們自己對此也確信無疑。代碼發(fā)布后曾經(jīng)出現(xiàn)過幾次中斷或問題，先是瘋狂地迅速修復，之后在同一天中得到一個熱修復補丁，以便完全恢復服務。我們?nèi)淌芰诉@種小小的不便，因為我們認為這個應用太復雜了，不能進行回退。
和之前發(fā)布的所有版本一樣，一個主要的基礎設施的版本發(fā)布后，也不能進行回退。這次發(fā)布簡直是場災難。凌晨時，一切看起來都很好但當天亮了以后，流量激增，這個站點就招架不住了。如果回退，只會讓幾個用戶不高興，給自己留點兒小傷痕，但不會有更糟的事情了。但我們卻不能回退，所以只好花費一整天的時間，為這個站點做點兒增加容量、限制流量等工作，以便在得到修復補丁之前保持一切仍然運行。那天晚上我們推出了一個補丁，當時站點并沒有流量，所以我們認為問題已經(jīng)修復了。第二天早晨，當流量增加后，這個站點又開始有問題了。只好又在晚上打補丁…這種模式持續(xù)了一周多。
接連折騰了這么多天，到那周結(jié)束時，所有人都已精疲力竭。最后，我們打了一個補丁，完全忽略之前的所有修改，終于使站點穩(wěn)定了。雖然從這次事故(包括指揮失誤)中可以學到很多東西，但與本條原則關(guān)系最緊密的是，無論我們還是客戶所經(jīng)歷的所有痛苦都是可以通過回退代碼避免的。
事后總結(jié)經(jīng)驗教訓，我們確定日后不允許再發(fā)布沒有回退功能的版本。當時除了發(fā)出這個布告外，我們別無選擇，客戶無法容忍這種性質(zhì)的問題，每個程序員也都理解了這種要求的必要性。六周后，當下一個版本準備好時，我們已經(jīng)能夠進行回退了。我們曾經(jīng)都認為難以克服的困難變得相當簡單了。
下面列出了要具備回退功能需要注意的幾個關(guān)鍵點。是的，回退的主要難點在于數(shù)據(jù)庫。通過仔細檢査應用，一一排除那些明顯的問題，然后堅持幾個簡單的原則，所有團隊都能夠進行回退。
口數(shù)據(jù)庫修改只能是増量的。在下一個廢除了列之間的依賴關(guān)系的版本發(fā)布前，只能添加數(shù)據(jù)庫中的列或表，不能刪除。一旦實施了這些標準，每個版本都應該有一部分代碼專門用于清除上一個版本遺留的不再需要的數(shù)據(jù)。
口DDL和DML必須腳本化且測試過。每個版本中對數(shù)據(jù)庫的修改必須通過腳本實現(xiàn)，而不能手動進行。其中應該包括回退腳本。這樣做的原因有兩點:1)團隊需要在QA或某個階段測試回退操作，以便驗證什么都沒有漏掉，不會妨礙回退；2)需要在一定負載的條件下測試腳本，確保在應用程序使用數(shù)據(jù)庫時，它仍然能夠執(zhí)行。
口對應用中的SQL查詢進行約束。開發(fā)團隊需要消除所有SQL語句中的歧義，刪除所有SELECT*查詢，并且給UPDATE語句加上要更新的列的名字。
口數(shù)據(jù)的語義修改。在發(fā)布版本中，開發(fā)團隊不能修改數(shù)據(jù)的定義。舉個例子。票務表中的一列用于存放狀態(tài)信號，其中有三個值assigned、fixed和closed。在應用的新版本中，如果沒有發(fā)布處理新狀態(tài)的代碼，就不能添加第四個狀態(tài)。
口WireOn/ireOff。應該讓應用結(jié)構(gòu)化，使其能根據(jù)外部配置，讓有些用戶能夠訪問某個代碼路徑和功能，而有的用戶則不能訪問。這種設置可以存放在配置文件中，也可以存放在數(shù)據(jù)庫表中既能夠根據(jù)角色賦予訪問權(quán)限，也能夠根據(jù)隨機百分比分配權(quán)限。有了這種結(jié)構(gòu)，就能夠讓有限的用戶對新功能進行beta測試，而且能夠迅速地刪除主要bug的代碼路徑，從而不必回退整個代碼。我們得到的教訓雖然慘痛，但是很有網(wǎng)站建設價值，有了這次教訓，我們再也不會發(fā)布不能回退的代碼了。即使以后和其他團隊一起工作，我們也會這樣要求自己的。可見，這些原則并不復雜，而是相當簡單，任何團隊都能夠應用它們，都能具備回退的能力。

分享標題：沒有回退功能的設計是失敗的設計
本文路徑：http://m.newbst.com/news15/151965.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、服務器托管、網(wǎng)站改版、標簽優(yōu)化、網(wǎng)站營銷、商城網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)