**摘要：
**Nathan Marz是分布式容錯實時計算系統(tǒng)Storm的創(chuàng)始人。在2011年7月Twitter收購社交媒體數(shù)據(jù)分析公司BackType前，他是BackType首席工程師。2013年3月，他選擇離開Twitter，創(chuàng)立了屬于自己的公司。

關(guān)于個人經(jīng)歷

《程序員》：你何時開始學(xué)習編程，編寫的第一個有趣的程序是什么？

Nathan：我十歲那年開始在自己的TI-82圖形計算器上寫程序。原因是我想在它上面開發(fā)游戲，也是因為那時我在數(shù)學(xué)課上感到太無聊了。我在計算器上寫出的頭一個有趣的程序是款射箭游戲——玩家向移動的目標發(fā)射箭頭，命中的目標越多，或任務(wù)完成得越快，都能得到更多分數(shù)。幾年后，當我畢業(yè)時，就在TI-89上寫程序了。它的性能要強大多了，我還記得TI-82只允許用戶使用26個變量（從字母“a”到字母“z”），而TI-89隨便你想擁有多少變量都可以，想一想真是太了不起了。

《程序員》：作為程序員，你如何不斷提高自己的技能？
Nathan：通過大量實踐和不斷嘗試新事物，我的程序?qū)懙迷絹碓胶?。成為?yōu)秀程序員的最佳途徑之一，就是學(xué)習新的編程語言。所謂“學(xué)習”，并非單純了解這門語言的語法，而是掌握它的習慣用法，并用學(xué)到的語言寫出切實的應(yīng)用。對我而言，學(xué)習Clojure，讓我在使用所有其他語言編程時也都大獲提高。

《程序員》：請談?wù)勀慵尤隑ackType前的經(jīng)歷。
Nathan：我從美國斯坦福大學(xué)獲得了計算機科學(xué)學(xué)士和碩士學(xué)位，主攻軟件理論。也因此完成了許多有關(guān)算法和驗證方面的研究。不過在斯坦福，我做過最得意的事，可能要數(shù)我沒怎么根據(jù)專業(yè)方向挑選課程，而是依據(jù)教授來選。當我發(fā)現(xiàn)某教授是位好老師，就會盡量完成所有由他主講的課程。
舉例來說，Tim Roughgarden教授是我遇見過的最好的老師之一，跟隨他，我研習了一系列有關(guān)“算法博弈論”方面的科目——這一領(lǐng)域是經(jīng)濟學(xué)與計算機科學(xué)的交叉點。我選擇這一系列課程，并非為了掌握課堂本身所講述的知識，而是為了提高自己解決問題的能力。Roughgarden教授對于將極其艱深的問題分解，使之易于理解，有一套難以置信的連貫而規(guī)律的方法。學(xué)到這些本領(lǐng)，令我在解決所有領(lǐng)域的難題時都獲益匪淺，對于將不同概念關(guān)聯(lián)起來受益良多。

《程序員》：你曾說，離開Twitter是一個艱難的決定，能否談?wù)勀銥楹巫罱K還是決定創(chuàng)立自己的公司？
Nathan：在Twitter，我所處的環(huán)境無可挑剔，擁有一整隊人馬全職投身由我創(chuàng)立的項目。然而一想起創(chuàng)建自己的公司這個念頭，我就被它推動著不能自已。于是我意識到，若不在此時創(chuàng)立這家公司，將抱憾終生。

《程序員》：BackType和Twitter的這段經(jīng)歷讓你學(xué)到了什么？
Nathan：反饋即一切。絕大多數(shù)時刻，你做出的是錯誤決定，只有反饋能令人意識到問題所在，并幫你少犯錯。這一原則是普適的。在產(chǎn)品開發(fā)中，需要盡快將其呈現(xiàn)出來，之后才能收集反饋，看看究竟何處可行，哪里又行不通。不過許多時候，你甚至不需要創(chuàng)建真實的產(chǎn)品——一個有關(guān)“新特性”的問卷頁面鏈接，就足以為你收集反饋，進而驗證自己的想法。
管理團隊，在所有流程中收集反饋也極為重要。在BackType，我們曾每月召開例會討論流程，評價它們是否有效或者過于嚴苛。由此我們引入了“站會”，但隨即取消，因為覺得這種形式對我們幫助不大。我們也曾將每月一次的例會改為隔周進行，進而又改為每周一次，后來又改回隔周。

《程序員》：你在博客中提到，你一直樂于和做有趣工作的人建立聯(lián)系，并愿意為他們出謀劃策。你參與了哪些項目，又提出了哪些建議？
Nathan：Insight Data Science（http://insightdatascience.com）項目伊始，它的創(chuàng)始人就與我取得了聯(lián)系，我認為這是個絕佳的項目。它提供為期6周的訓(xùn)練營課程，幫助數(shù)學(xué)、科學(xué)、物理專業(yè)的博士生掌握編程技能，讓他們能以“數(shù)據(jù)科學(xué)家”的身份開啟自己的職業(yè)生涯。
一方面，大批聰明人不能從事自己理想的工作，而另一方面，科技產(chǎn)業(yè)的迅速發(fā)展，對數(shù)據(jù)科學(xué)家的迫切渴求，令這一職業(yè)形成了巨大缺口，而Insight Data Science項目為兩者搭建起了橋梁。我為他們提供了一些自己的經(jīng)驗，而他們的執(zhí)行力也令人印象深刻。

《程序員》：你貢獻了多個開源項目，什么原因讓你信仰開源？
Nathan：開源能令許多人以不同方式受益。初創(chuàng)公司的資源高度受限，倘若別人的工作能為自己所用，真乃天賜之物。對于整個社會，降低初創(chuàng)公司的開銷當然也有裨益。既然你已從開源之中受惠良多，自然也感覺有義務(wù)回饋。最重要的是，當你以開源軟件作為產(chǎn)品經(jīng)營公司，將能享受到使用者的回饋——發(fā)現(xiàn)問題、提高軟件質(zhì)量，而且還是免費的。
在個人層面，開源讓我有機會能與全世界開發(fā)者接觸，而不受限于我所就職的公司。這一點對我的職業(yè)生涯幫助巨大，讓我有機緣廣交能人，又能通過在會議上演講周游世界。

《程序員》：哪個人對你的影響最大？
Nathan：從哲學(xué)角度講，對我影響最大的人非Carl Sagan莫屬。我?guī)缀蹰喿x過他的所有著作，并被其深深鼓舞。我覺得他是有史以來最杰出的傳播者，而留給我印象最深的是，他與讀者能保持極強的同理心。例如，他撰寫了許多有關(guān)“科學(xué)vs.宗教”的話題——但身為科學(xué)家，他并未對宗教或其他事物流露出敵對心態(tài)。他理解為何有人信仰宗教，也理解他們能從宗教中獲取哪些撫慰。因此，當他傳播科學(xué)的價值并對信教者持懷疑論時，他會先以“宗教等同于價值”作為出發(fā)點。換位思考能達到這種程度真是罕見，這也是我不斷想在自己身上獲得提高的地方。他教給我同理心是良好溝通的基礎(chǔ)。

《程序員》：你曾到John McCarthy家中，和他有過一段對話，他同你講了什么，對你有哪些影響？
Nathan：這件事發(fā)生在我讀大學(xué)二年級時，我與John McCarthy有過兩個小時的交談。最令我感到意外的，是當我問起Lisp的歷史時他的講述。他告訴我，當時他需要一門更好的語言用于AI研究，為了這個目的才發(fā)明了Lisp。而他自己，看起來真的并不怎么關(guān)心語言本身——AI才是他的鐘情所在。這件事對我的震撼就如同牛頓之所以發(fā)明微積分，是為了方便他研究物理問題那樣。巨人們隨手撇下的鵝卵石都是龐然大物。

《程序員》：什么原因促成你開始寫作《Big Data：Principles and Best Practices of Scalable Realtime Data Systems》這本書？你希望在其中解決哪些問題？寫書是個漫長的過程，在這段時間，你又有哪些感悟？
Nathan：對于架構(gòu)大數(shù)據(jù)系統(tǒng)，我已提出了多項理論和最佳實踐，這些內(nèi)容都是旁人從未講述過的。人們大多專注于某些具體用例，而我提出的是一套嚴格、完整的方法論。
許多我曾闡述過的話題，例如系統(tǒng)應(yīng)能從容恢復(fù)人為失誤引發(fā)的故障（在我看來，這一原則絕無妥協(xié)余地），但在工業(yè)界中，卻被大多數(shù)人所忽視。我相信，在搭建這類系統(tǒng)時，倘若能多些嚴格驗證，少些任性隨意，整個工業(yè)界都會因此而受益。而寫作《Big Data》這本書正是為了推動這種轉(zhuǎn)變。
我理解寫書需要花費大量精力，但未曾想真實付出遠遠超出我的預(yù)期。寫作這本書尤其富有挑戰(zhàn)，因為它試圖涵蓋一個宏大的主題。在某個時間點，我已完成了半本書的寫作，卻意識到素材的組織方式并不妥當，于是我棄置了所有舊稿，轉(zhuǎn)而另起爐灶。這樣做完全是值得的，這從讀者的反饋中可以得到證實。他們能更好地理解我使用的素材和希望表達的思想。
我的編輯們在寫作過程中功不可沒，他們也助我成為了更好的作家。我發(fā)現(xiàn)，學(xué)校教授的那套寫作方法，完全有悖于高效溝通。那時老師告訴我們要把“論點”放在文章的開頭，之后再向下逐層展開一般性觀點和對應(yīng)支撐，最后才是具體細節(jié)。
然而事實證明，這種方式迫使讀者頗費一番功夫來整合作者的陳述。他們不可能在一開篇就把握論點——因為這會兒還沒讀到相應(yīng)的支撐點呢。所以跟隨作者逐層向下之后，讀者還要拐“上”來串聯(lián)一切。要通過這種方式理解事物，真叫人費解。更有效的溝通方式是講故事——由讀者感同身受的話題出發(fā)，一步步串聯(lián)，直至你希望讀者理解的終極概括性觀點。從具體到概括，總是勝過從概括到具體。

《程序員》：你在博客上也呼吁其他程序員開始寫作，提高寫作技能，對此你有哪些秘訣？
Nathan：提高寫作技能的唯一辦法是多寫。當其他人閱讀我的文章，為我提供反饋時，例如在博客中留言，我總會思考他們?yōu)楹稳绱嗽u論。倘若他們誤解了我的本意，可能意味著我沒能恰當?shù)亟涣鳌只虮磉_不夠清晰，抑或我未能準確預(yù)測讀者的反對（這些反對意見是否成立無關(guān)緊要）。通過理解信息為何沒能準確傳遞，下次我就會做得更好。
同時我也大量閱讀，并嘗試向偉大的作家學(xué)習。我已提到Carl Sagan是我最欣賞的作家之一，閱讀他的作品，我獲益良多，而且每次閱讀都是如此。
關(guān)于編程感悟

**《程序員》：設(shè)計軟件系統(tǒng)時，你會采用哪些步驟？
**
Nathan：我認為，設(shè)計軟件系統(tǒng)完全就是學(xué)習如何在行進中開發(fā)。我應(yīng)用一種被我稱之為“面向痛苦編程”（Suffering-Oriented Programming）的原則，使學(xué)習最大化，浪費最小化。關(guān)于這種方式的詳細介紹我已寫在博客上（http://nathanmarz.com/blog/suffering-oriented-programming.html）。其核心思想是，避免做出“通用”和“可擴展”的設(shè)計，除非你已透徹理解了問題域（Problem Domain）。
相反，你應(yīng)該直截了當?shù)乇M快打造出可用原型，繼而通過迭代和改進學(xué)習問題域，當你對問題域的盤根錯節(jié)有了清晰的理解后，再回過頭來重新設(shè)計系統(tǒng)，使之具備通用和可擴展等特性。到最后一步才開始收緊代碼，優(yōu)化性能。歸納為三個步驟，就是“先使之可能，再使之漂亮，后使之快速?！?/p>

《程序員》：你在編程時，通常會遵循哪些原則？
Nathan：我非常篤信不變性（Immutability）與引用透明函數(shù)（Referentially Transparent Function）是大幅簡化軟件系統(tǒng)的途徑。可變性在代碼中編織了依賴網(wǎng)絡(luò)（一個對象的改變，導(dǎo)致另一個的改變，進而又改變其他對象），令你不知所措。代碼的作用是理解程序的運行狀況，任何能使其簡單化的方法都有益處。不變性就是這類簡化方法之一，它能便于你理解和掌控代碼。此外，引用透明函數(shù)只依賴于其參數(shù)（與其他狀態(tài)無關(guān)），也有利于理解代碼。
另一個我所倚賴的重要原則是“我的代碼有缺陷”。顯而易見，我們尚不清楚如何編寫完美代碼——所有我使用或編寫過的代碼都存在Bug。因此，我在假設(shè)自己的代碼有缺陷的前提下，設(shè)計并使系統(tǒng)盡可能運轉(zhuǎn)起來（至少大多數(shù)情況如此）。其中的技術(shù)細節(jié)我在2013年的技術(shù)會議中分享過。

《程序員》：同剛開始編程時相比，這些年你在編程方面最大的變化是什么？
Nathan：自從拋棄了圖形計算器，我得說最大的變化在于可以在全鍵盤上寫程序了，而不是用那些小按鍵。

《程序員》：你面試過許多程序員，那些最優(yōu)秀的人有什么共同之處？
Nathan：最好的程序員都癡迷于提高自身的核心技能，他們喜歡探索新的編程語言和想法。好程序員的另一個重要特征是，他們都有“把事情做成”的心態(tài)。與完美的設(shè)計相比，讓系統(tǒng)真正可以運行要重要得多。還有一點，他們都知道除非先讓系統(tǒng)運轉(zhuǎn)起來，然后從中學(xué)習，否則別想得到完美的設(shè)計。

大數(shù)據(jù)系統(tǒng)與Storm

《程序員》：關(guān)于大數(shù)據(jù)系統(tǒng)，是否存在誤解和迷思？
Nathan：我所見到最普遍和嚴重的一種誤解是，人們往往對關(guān)系型數(shù)據(jù)庫與相關(guān)理論（如CRUD）頂禮膜拜。將RDBMS視為終極的數(shù)據(jù)庫技術(shù)，并且似乎每個人都嘗試在大數(shù)據(jù)的版圖上重新實現(xiàn)RDBMS。然而這樣做忽視了RDBMS的痼疾：它們都基于可變性，容易遭Bug或人為失誤侵襲而崩潰；此外，這類技術(shù)迫使你要么標準化Schema并忍受性能缺陷，要么采用非規(guī)范化的Schema并準備迎接維護的夢魘（還有其他問題）。
而當你真正從首要原則審視數(shù)據(jù)系統(tǒng)時，就像我在書里面的做法，其實存在多種架構(gòu)數(shù)據(jù)系統(tǒng)的方式，能克服所有的這些復(fù)雜性。

《程序員》：開發(fā)Storm是為了解決BackType的哪些問題？
Nathan：開發(fā)Storm是為了解決兩個問題。其一是確保我們的數(shù)據(jù)庫中總是包含最新的實時社交媒體分析統(tǒng)計狀態(tài)。其二是“到達問題”——計算機如何才能快速獲取發(fā)布在Twitter上的鏈接，它需要計算所有用戶的關(guān)注者發(fā)布的全部鏈接。這是一項高度的計算密集型任務(wù)，難以預(yù)先處理。Storm是這一系列看似互不關(guān)聯(lián)的用例的簡單抽象。

《程序員》：在極少的人力支援，有限的時間和預(yù)算，以及創(chuàng)業(yè)公司緊張的氣氛下，你完成了Storm這樣一套復(fù)雜的系統(tǒng)，信心從何而來？
Nathan：Storm正是遵循“面向痛苦編程”方法的結(jié)果。能在這種背景下完成Storm并非意外，我們在BackType采用手工將Workers與隊列結(jié)合的方式處理實時計算工作已有相當長的時間，因此，我們對實時處理的需求有著堅實的理解。Storm的核心只不過是一套抽象集合，以及一套聰明的算法在幕后保障數(shù)據(jù)處理。那時，一想到我在BackType將面對實時處理這個長期而艱巨的任務(wù)，設(shè)計Storm來解決這個問題便再自然不過了。此外，我還有豐富的Hadoop經(jīng)驗，曉暢它的設(shè)計缺陷，我將這些經(jīng)驗都用在了Storm的設(shè)計上，令它更堅韌。
正是因為有著這樣的背景，我對能否成功實現(xiàn)Storm從來沒有過疑問，那些可能存在的陷阱，我早就了然于胸了。

《程序員》：你為何選擇用Clojure實現(xiàn)Storm？哪些特性是你最青睞的？假如Clojure不存在，會有哪些不同？
Nathan：Clojure是我迄今用過最好的語言。它允許我輕松地使用不可變性及函數(shù)式編程等技術(shù)，令我的效率大幅提高?；贚isp的動態(tài)特性，使我總能將Clojure塑造成符合最佳抽象的狀態(tài)。假如沒有Clojure，Storm倒不會有什么不同，但實現(xiàn)過程將痛苦得多。

《程序員》：因為Clojure的緣故，你也改用Emacs作為編輯器，它帶給你哪些不一樣的感受？
Nathan：我之所以使用Emacs，是因為它是最理想的Clojure編程環(huán)境（它們都有Lisp的淵源）。我驚訝于一款工具在提供如此強大功能的同時，還能如此靈活地隨心定制。
除此之外，因其最初開發(fā)年代久遠，資源占用難以置信的小。不像那些現(xiàn)代IDE，往往吞噬掉大量資源。
我的配置相當簡單，在Emacs中我使用REPL做探索式開發(fā)和交互測試。我的電腦里還有不計其數(shù)的設(shè)計筆記和構(gòu)思，都以純文本格式保存。我的待辦事項列表，就是一個文本文件。

本文為《程序員》原創(chuàng)文章，未經(jīng)允許不得轉(zhuǎn)載，如需轉(zhuǎn)載請聯(lián)系market#csdn.net(#換成@)