[視訊]Jez Humble：我們為什麼要“持續交付”（圖靈訪談）

圖靈訪談之三十七：專訪Jez Humble談我們為什麼要“持續交付”

Jez Humble，中文名韓捷，是ThoughtWorks的首席諮詢師，也是《持續交付》一書的作者之一。從2004年開始，他進入ThoughtWorks，並在北京、班加羅爾、倫敦和舊金山的ThoughtWorks Studio工作。他擁有牛津大學的物理和哲學學士學位，以及倫敦大學亞非學院的民族音樂學音樂碩士學位。現在他和妻子、女兒居住在舊金山。

圖靈社群：那我們就開始吧。你能簡要地介紹一下你自己，以及此次來中國的目的嗎？

Jez：當然，我是Jez Humble，我寫了一本叫做《持續交付》的書，是ThoughtWorks的首席顧問，我來中國的原因是我要在這裡做幾個Workshop以及一些演講。ThoughtWorks在中國有公司，我們在這裡也有客戶，而且我的書也由圖靈在中國出版了，所以我也很樂意來中國宣傳一下這本書。而且ThoughtWorks也希望可以擴大“持續交付”在中國的影響面。

圖靈社群：我希望這會對這本書的銷量帶來增長。

Jez：我也這麼想（笑）。

圖靈社群：我曾經看過你的學業背景，看起來很複雜，你學過物理、哲學，甚至還學過一門叫做人種音樂學的專業，這看起來和你現在所從事的工作有些無關，你覺得這些知識和經歷對你現在的工作有什麼幫助和啟示？

Jez：我在大學之所以學習這些專業是因為我對這些東西很感興趣，但很不幸的是這些東西賺不來錢，所以我轉向了計算機（笑）。因為在還是個少年的時候，我經常宅在家裡寫程式，後來我竟然驚奇地發現，這也是一種生財之道。我認為物理和哲學對於計算機還是很有用的。物理中我學到了電子學，這幫助我理解了計算機根本的工作原理。而學習哲學的時候就要學習邏輯，這對我如何清楚地思考很有幫助。而音樂學似乎不是那麼有用，但是人種音樂學研究的是音樂和文化之間的聯絡，尤其是文化那部分很有意思。人種音樂學可以分成人類學和音樂，人類學對於產品設計來說是很有用的學科，因為在設計產品的時候需要觀察人是如何和產品互動的。所以當使用者體驗的工作人員在做產品的時候這些知識都能派上用場。所以從根本上來說，我認為所有事情都是有聯絡的，根本就不存在沒有用的知識。而且大部分在開發產品時遇到的問題都是出在“人”身上，其中包括如何與人互動。所以我所學到的所有知識都可以有其用武之地。

圖靈社群：接下來這個問題我們曾經問過Martin Fowler，現在可以問問你了。圖靈公司是勇於嘗試“敏捷開發”和“持續交付”的。我們計劃在今年引進的新書中，採用每翻譯完一章就釋出一章的出版方式。您對出版業如何應用敏捷，有什麼建議嗎？

Jez：這其實是個很好的想法。但是令人慚愧的是，《持續交付》這本書花了我和Dave四年的時間才完成，所以我不能說我們在這方面的工作達到了持續交付的級別（笑）。在出版界有一家美國的初創公司叫做leanpub，在那個網站上你可以完成自出版。如果出版商打算這麼做的話，如果圖靈打算這麼做的話，我認為這對你們來說是很好的，對於作者來說也不錯，大家都可以收到很快的反饋，這絕對是個好點子。

圖靈社群：你的書曾得過Jolt大獎，有人曾評價說“持續交付”將會影響接下來的十年，你是怎麼看的呢？

Jez：我非常高興有人能這麼說。可以這麼說，其實我們所寫的東西並不是真正的原創，我們在書中討論的很多概念其實都已經被很多人談論了很多年了。比如說，我們在書中提到的一個主要概念就是“質量內建”（build quality in）,這個觀點其實有人在上個世紀50年代就已經提出了。我很高興可以影響軟體行業二三十年，但遺憾的是，IT軟體行業對於歷史的理解並不充分。所以我覺得如果我們可以讓人們更好地認識歷史，同時也可以讓人們在工作中做得更好，我就已經很高興了。但是我個人認為持續交付這個概念可能要十年之後，人們才能完全接受。因為要做到持續交付其實還是挺難的。

圖靈社群：今年的Jolt獎得主是《例項化需求》，你讀過這本書嗎？

Jez：我知道這本書，Gojko Adzic 是這本書的作者。我沒有讀完，但是讀了一部分。就我讀的這部分而言，我很同意他的說法，我甚至在我的演講中也經常提到這本書。我認為他在書中提到的方法是很管用的，而且這本書中的概念和《持續交付》的內容也是相輔相承的。

圖靈社群：我聽說你在寫一本叫做DevOps Cookbook的書，這本書進展得怎麼樣了？你負責哪部分的寫作呢？

Jez：有七個人在寫這本書。其實並沒有明確每個人應該負責的部分，我們打算把好的實踐經歷和工作模式都放到這本書中來。我不知道這本書出版的具體時間，但是寫作的過程很愉快，這也會是一本很有價值的書。這本書的重點在於系統思考和精益思想的應用，以及文化問題和技術問題，我們希望可以鼓勵開發和運維團隊更有效地合作，書裡也涉及幫助運維團隊應用敏捷和精益原則在工作中這樣的技術問題。 這本書的大背景是這樣的，我們會設定一個基調就是如果要達到從開發，到運維，再到使用者這樣無障礙的狀態就要採用一些好辦法。如何讓企業的各個部分更有效地合作，如何建立管道，就像我們在《持續交付》這本書中說過的一樣。什麼是應該做的事，完成這樣的事需要什麼步驟，這就是我們在書中想表達的。

圖靈社群：剛剛你才說過“持續交付”的難以實現性，那你有沒有打算就此再寫一本書呢？比如叫做《CD實戰》之類的？

Jez：我和另外兩位來自ThoughtWorks的同事其實正在寫這樣的一本書。但是我還沒有寫多少，所以可能大家還都不知道。我可不想逢人就說：嘿，我正在寫書呢。結果書兩年後才出來。

圖靈社群：Dave Farley曾說過任何在3-6個月內需要再次改動的軟體都適用於持續交付。這看起來是個很大的市場，但是中國有一些技術領袖，他們對持續交付持懷疑態度，他們對待這種新的工作模式態度是防禦性的，你認為怎樣才能鼓勵他們嘗試持續交付呢？

Jez：其實我不太理解為什麼有人會對持續交付持懷疑態度。事實是，我和Dave在書中寫到的東西都是來自於我們的真實經歷，書中的概念都是來自ThoughtWorks的眾多專案。其實這本書的創作人並不只是我和Dave，而是很多ThoughtWorks的同事以及我們的共同經歷，書中提到的所有概念我都曾經在實踐中應用過，有些在大企業中，有些在分散式的機構中，而且也涉及不同領域。 我們如果對一個概念有任何懷疑的話，那這本書也不會收錄這個概念。我們沒有編造任何東西。事實上也有其他人有類似的概念，比如leanstartup，以及DevOps社群的很多思想。我們說的其實都一樣，而這些都是建立在50年的管理經驗上的。
如果仔細看看很多大公司比如google, facebook, MSN, 甚至是蘋果，他們都需要接受每天釋出兩次這樣的挑戰，google每天都會做上千萬次的自動化測試，這些都在實踐中應用過。 所以需要記住的是，持續交付並不是試驗性的東西，也不是充滿風險的，恰恰相反，我們所作的一切都是要降低風險。我們的目的是把團隊的效率最大化，當你說你的專案完成了80％的時候，這個專案真的是完成了80％。我們之所以寫這本書是因為我們厭倦了超時工作，厭倦了週末加班，厭倦了危險的釋出，我們要更安全的釋出，我們要每週認真工作40個小時，然後週末回家的時候可以很自信地說：我們的工作都是有效的。所以我希望至少持懷疑態度的人可以嘗試一下，如果你有好的經歷可以分享出來，如果遇到問題也要分享出來，這樣大家才可以在社群裡互相幫助。

圖靈社群：當我們說到敏捷的時候，很大成分我們說的是人。在採訪Bob大叔的時候他曾經說過，任何工具或者流程如果讓人們在自己的工作環境中感到舉步維艱，那它就不能被稱為敏捷。持續交付中的概念中哪個最能代表這個思想？

Jez：我認為Robert Martin這句話很有道理。持續交付中最重要的思想就是作為一個開發者，我希望能儘快地看到我寫下程式碼所產生的反饋。縮短週期時間後，生產時間減少，釋出之後你就可以馬上看到人們使用時的反映，所以就可以知道，人們到底喜不喜歡你剛剛所做的東西。所以持續交付的一大好處就是讓開發者和使用者產生直接的聯絡，一旦開發者和使用者捱得更近了，所產生地反饋迴圈也就越發得強大。我覺得這就是Bob大叔所說的。這也是以前的釋出方法的問題之一，作為開發者，你寫完程式碼後，可能要等上半年才會看見產品釋出，這感覺真是糟透了。因為那時候你可能已經進入到其他別的專案中了，而你寫的程式碼還沒有在實踐中應用呢。所以如果開發人員每天上班寫程式碼，而他自己也不知道這些程式碼是不是有價值、是不是有效，這種感覺肯定不好。而更重要的是，在這樣的情況下，你就無法學習，如果無法看到程式碼變成產品，無法看到人們如何使用，你就無法學到如何創造出更有價值的東西。我覺得這個的重要性不僅在於要讓你感覺到你創造的價值，也要讓你學習到如何能做得更好，而沒有反饋這一切都無法實現。

圖靈社群：在這本書中，有很多實踐是和人們慣常開發軟體的習慣相悖的。比如說，如果單分支開發可以是主流的話，那麼Git為什麼這麼受歡迎？Git或者分散式VCS在分支上的表現怎麼樣？

Jez：Git 是一個強有力的工具，我很喜歡使用Git，我也很喜歡使用Mercurial，事實上我已經用了5年多了。我對分支完全沒有意見，但是我對歸併有一些看法（笑）。Git就像C++一樣，同樣都是很棒的工具，可以用在好的方面，也可以用在壞的方面。我覺得Git並不是要人們在長功能分支上工作，它的目的是讓人可以更好地合作、更好地交流。Git有分支並不意味著人們就應該用功能分支來開發軟體，這是完全不同的概念。我其實在這方面已經寫了一篇文章在continuousdelivery.com，喬樑好像已經把它翻譯成中文了，我用長篇大論闡述了我的觀點。我認為Git沒有問題, 分散式VCS也沒有問題，如果你在Github上發現了克隆程式碼，而這些程式碼也作了很大的改動，它們是絕對不會再歸併回原始程式碼的。必須要確定分支出去的程式碼不會變動得太多，否則它們就會變得無法歸併。在開源專案中可以見到這樣的現象，在Github上也可以見到，你可以把專案分支出去，但是這並不意味著你就應該做一個長長的分支，Git可從沒告訴你要這樣做。

圖靈社群：必須要在實施持續交付前實施持續整合嗎？你覺得它們的區別在哪？

Jez：我認為是這樣的，確實應該在實施持續交付之前實施持續整合。持續整合在實踐中就是每個人都要提交到主幹，而且要確證做到當測試失敗後，團隊就會馬上停下來，修復它，以保證程式碼每時每刻都處在工作狀態。而持續交付是要保證這樣的程式碼處於可以部署的狀態，要優先保證你的系統處在可釋出狀態，而不是功能開發狀態。還有另外一種實踐叫做持續部署，持續部署意味著你把所有通過持續整合的版本釋出到生產。持續交付是說如果你希望的話，可以去做持續部署，但是不做也是可以的。所以這是比持續整合更進一步的狀態，如果你覺得釋出所有能夠通過持續整合的版本都沒有問題的話，那就是持續交付了，這就是它們的區別。但是大多數人的系統都更加複雜，很多通過持續整合的版本都不足以釋出出來。有一條持續整合的規律就是，是否通過持續整合，在幾分鐘內就可以確定，而這在大規模的系統中並不足以給你足夠的信心來作為釋出條件。所以才有了持續交付。

圖靈社群：你的書中很少提到工具，你曾說過在這本書的網站上會有關於工具的資料，但事實上上面關於工具的內容並不多，你是怎麼做出這種抉擇的？

Jez：我個人認為工具這方面是很無聊。當然，這並不是說我認為工具很無聊，我們公司自己也在做很多工具，比如Mingle, Go, Twist, 等等。工具是很重要，但是工具有一個問題，就是它們發展變化得太快了，我也沒在每天的工作中引入太多的工具，所以我也沒法就此發表太多觀點。有很多人在自己的部落格中，或者寫文章提到了工具的使用，有一個很棒的郵件列表叫做devops-toolchain groups，可以在那上面討論關於工具的內容。而且還有很多其他資源，所以我就不研究這方面的內容了。我更樂意研究我比較在行的部分，比如從大公司的專案或者thoughtworks的專案中借鑑經驗，討論其中的實踐、模式，以及原則，這才是我感興趣的方面。

圖靈社群：當談到持續交付時，你總是會提到很多“每個人”，你認為有沒有可能這才是實施持續交付的難點？

Jez：在大多數機構中有兩種情況讓持續交付的實施變得很困難，退一步說也讓軟體開發變得很困難。第一種就是功能分割槽，開發人員、測試人員、運維人員都各自為政，這讓持續交付變得很困難。精益軟體討論的就是跨功能團隊，在這樣的小團隊中每個人都參與到產品或者服務的釋出中來，大家都在“一個房間”內，這是最好的開發軟體的方法。不要一直都陷在過程優化中，在上個世紀80年代，大家認為功能分割槽是個好主意，這個想法在現在看來並不十分受用，也不太有效，甚至有點可怕。有位軟體質量方面的專家Elisabeth Hendrickson在2001年發表了一篇論文，他指出單獨成立一個測試部門，讓軟體開發的質量變得更糟。功能分割槽不是開發高質量軟體的方法。而另一個問題存在於架構中，人們在設計軟體的時候並沒有把可擴充套件性和可測試性作為主要考慮因素，這樣的系統實施持續交付很苦難，事實上，這樣的系統做任何改變都很困難，而很多人都有這樣的問題，而這個問題可不是好解決的。

圖靈社群：非常感謝你接受我們的採訪！

Jez：非常感謝你們的採訪邀請！

---

更多精彩，加入圖靈訪談微信！