Dave Thomas：一個開發者的爲與不爲

非商業轉載請註明做譯者、出處，並保留本文的原始連接：http://www.ituring.com.cn/article/60099

Dave Thomas是一位程序員，同時也是一位做者和出版人。他和Andy Hunt一塊兒開辦了出版公司The Pragmatic Bookshelf，他們整個線上業務都是他和Andy用Ruby建立的。他的我的做品包括《Web開發敏捷之道》、《Programming Ruby》。他和Andy共同寫做了《程序員修煉之道》，這本書也是The Pragmatic Bookshelf品牌下的第一本書。做爲一位開發者，他充滿了熱情，他相信這是個屬於勇敢者的時代。對於業界存在的問題，他痛心疾首，並不斷尋求着解決方法。做爲一位出版人，他務實、精明，時刻爲本身的做者着想，也爲像他同樣的開發者蒐羅好書。他是一位徹徹底底的Pragmatic Programmer。

你用Ruby幹什麼？你是如何參與Ruby社區的？

Dave：在過去的8年中，我用Ruby作全部的事！咱們整個的線上業務都是用Ruby寫的。若是你成爲咱們的做者，咱們用來造成一本書的軟件也是用Ruby寫的。因此能夠說Ruby就是咱們公司的所有。另外，我幾乎天天都會寫Ruby腳本，這是我生活的一大享受。個人記性不好，若是我生活中能找到任何能夠自動化的步驟，我必定會把它自動化，這樣個人生活就會更加簡單。

在開始的時候Ruby社區人不多，第一次聚會的時候大概只有30人。因此參與這麼小的社區其實只是和朋友打交道而已。說到開源社區的貢獻，我大概寫了有四、5千行代碼，有一些文檔，也提交了一些補丁。另外，我常常參與Ruby大會，而且樂在其中。

你對其餘Rubyist有什麼建議？你對對Ruby這門語言感興趣的人有什麼建議？

Dave：好問題！我最大的建議就是參與進來。這就意味着找到一個你須要作的事，每一個人均可以作到，不是非要是個編程大牛才能夠。只要找到一個小bug或者你使用的庫沒有作你但願的事情，那你就能夠作一個新版本出來，或者把補丁發給做者。若是有一些功能徹底不存在，那麼不要只是作出來給本身用，打個包發佈給你們。若是這麼作的話，你就是社區的一員了。這種回饋不只會讓你感受很好，也會幫助其餘人。一樣，這麼作也會幫到你本身，由於你有了名譽和聲望，你在社區中也有了本身的位置。

你是怎麼成功地做爲程序員、做者、出版者工做的？這些東西佔據的比例是怎麼樣的？

Dave：我睡得很少（笑）。做爲一個出版人，個人團隊很是出色。首先，咱們都要感謝自動化，咱們多是世界上自動化程度最高的出版公司。咱們整個公司沒有一張電子錶，這些都要歸功於Ruby。好比我知道不少出版商若是要發佈一本書的新版本的話，須要在以前工做一兩天的時間，而咱們只須要……大概5秒鐘。自動化是關鍵點之一，經過高度自動化，我就有了更多空餘時間。另外有不少傑出的人才和咱們一塊兒工做，他們工做得比我好。我很幸運，他們能夠幫我完成不少工做，因此我有時間空餘出來。雖然有一些我必須作的事，可是大部分時間我能夠作我喜歡作的。也就是去了解新的科技，和有趣的人交談，繼續探索，說實話……這種生活真的很享受！

咱們沒有辦公室，每一個人都在家工做。因此我早上起牀以後，查查郵件，遛遛狗，回來再作事……全部事都是生活的一部分，因此我不用把個人時間分割成8小時工做和下班。其實我天天的工做時間多於8小時，可是事情都是分佈在各類時間段裏，因此感受起來不像是在工做。當天氣晴好的時候，我能夠坐在外面邊曬太陽，邊打字，這樣的感受很好。

做爲一個出版人，你怎麼策劃出下一個選題？

Dave：有兩個問題，第一個是須要知道接下來什麼纔是最有趣的技術；第二個是找到合適的瞭解這門技術的人來寫做。

要想知道什麼技術會大放異彩的關鍵就是要和正確的人對話。我有一條原則，若是我在一個禮拜內聽到某種新技術兩次，那這種技術就會進入個人候選名單中。每週咱們都會召集咱們全部的編輯開一次會，咱們在會上會討論這些話題。這時候可能就會有某個編輯說，嘿，剛巧我認識一個這方面的人。不然，咱們就得出去找人了。這可真是個問題，由於知道這些技術的人還剛巧都是些大忙人，他們都在本身的項目上忙着呢。因此，爲了減輕他們寫書的痛苦，讓他們的工做更加簡化，咱們提供了一些工具。若是你是一位開發者，使用這些工具是很天然的事。但不管如何，寫書都是一項艱難的工做。

如今不少書都在教人如何製做本身的編程語言，操做系統，這樣的DIY項目彷佛也不是大牛的專利，比過去更加容易實現了，你對想作這些的程序員有什麼建議嗎？

Dave：每一個人到了一個時期，都會看着某個項目或者技術說：我能作得比他好。這種可能確實存在，可是90%的多是，他們作不到。由於他們沒有理解到這個項目或技術後面的細節以及微妙之處。對於那些能夠作到的人，不少人都花上一年的時間，根據某些已有的項目從新實現某些功能。這個項目可能會變好……5%，但我所看到的是，他們在別人的想法上花了一年的生命，而這種提高只是邊邊角角的。倒不如把這一年的時間花在實現本身的想法上，這樣作的話你可能會失敗，可是你學到的東西會多得多！若是你沒有失敗，那你就創造出了一種全新的東西，這是讓人興奮的。

你想作本身的編程語言嗎？若是你願意的話，固然能夠。可是現實是，這門語言頗有可能不會大受歡迎。由於有不少人在這麼作，並且你成功與否不只在於技術能力，更要靠運氣。若是我想貢獻本身的代碼的話，我不會這麼作。由於從個人經驗來看，我每一年都會又一次坐在那裏勾勒本身的語言，而後我想起來這句話：不要這麼幹！而後我就會放棄掉。

作本身的語言或操做系統變得更簡單了嗎？是也不是。可能更難了。創造這些的工具確實是更好了，咱們對於技術的瞭解也更多了。你能夠把你的語言放在JVM上。可是人們對於編程語言的期待也更高了，因此實現起來很困難。因此若是你想投入大把精力在某件事上，我不建議你去發明一種語言，這樣作的風險很高。

做爲一個出版者，你對於這些自建項目的書也不感興趣吧？

Dave：咱們每一個禮拜大概都會收到兩個這樣的提案。他們會說咱們作了一種全新的語言或者框架，關於這個項目我想寫一本書。咱們管這些書叫作「我充實的暑假」。一門受歡迎的語言至少須要你花半個月的時間把它發佈出來，而後須要至少有50-100個積極參與者。一門語言至少須要這些啓動力，纔有可能變得被大衆接受。若是隻有你和你的愛犬喜歡這個項目，那你就還差得不少。爲這樣的項目寫書，不會讓它變得更好，只會浪費你又一年的時間。美國有一句諺語叫作：「good money after bad」（陪了夫人又折兵）。因此咱們通常不會作我的項目的選題，這樣對於出版社和做者都是一種傷害，尤爲是對做者。

Ruby和移動開發結合比較熱門，松本行弘本人也專一去作mruby了。請問對Ruby與移動開發的前景有什麼見解，須要逾越那些障礙？

Dave：對於移動方面的開發最大的挑戰就是沒人知道怎麼去作。可是不要緊，由於咱們在不斷努力嘗試，犯錯誤，而後從中學習。我認爲移動不是重要的，而是惟一相當重要的開發。它並不僅是手機，而是分佈網絡下的各類東西。人們討論的因特網同樣的鏈接，我認爲這種實現的到來會比咱們期待的更快。因此咱們要找到一種編寫系統的辦法，這種辦法能夠支持成千上萬處理器，它們出如今各類地方，進進出出，而後把他們整合到一塊兒，在須要的時候還能夠拆分開來。好比當我走入一個房間，而後個人手機，或者設備就開始和這個房間對話，它會告訴我須要知道的信息。我認爲這將在不遠的將來就能夠實現。

在這樣的將來中，Ruby的領域在哪裏呢？松本在作mruby，這是一種模塊化設計語言，因此你能夠選擇你須要的功能。你能夠選擇運行，或者把它變得更加輕量。我昨天和他通話時談到了mruby，他說有一家公司在使用mruby作他們的渲染器，他們把它設置成有45kb的內存印跡，這真是難以置信。這就是Ruby應該發展的領域嗎？我不肯定。Ruby最開始應用的領域是比剛纔所說的退一步的地方，也就是設備之間的接口。全部設備只是骨架上的皮肉。迴歸這樣的位置也許更好，我但願Ruby能夠從一種傑出的Web開發語言的定位上移開。它並不僅是一種Web開發語言，不能由於rails很紅就說它只屬於Web開發。Ruby並無改變！它只是用來寫Web應用很順手而已。我以爲Web應用在將來可能會降溫，因此我也但願Ruby能夠迴歸本源，而且與時俱進。

pragprog.com前段時間出版了ruby motion的電子書，以後是否有更多相似題材的選題能夠先透露一下。

Dave：還有不少。咱們其實很自私，咱們只出版本身感興趣的書！對於和咱們所作的其餘事相關的話題通常都很感興趣。ruby motion頗有趣，我也想出一本mruby的書。咱們不只關注語言，也很關注語言的不一樣用法。咱們這方面的書還不夠多，我很期待有人可以提供Ruby，Erlang等等這些語言的成功用例。這些話題老是頗有意思。

你從事開放出版很長時間了，你能介紹一下你的經驗，和開放出版在當下的現狀嗎？

Dave：咱們寫書的方式和其餘出版商不一樣。大部分出版社會對做者說，第一章應該在3個月內完成，第2、第3、第四章要在……因此做者們寫完一章就繼續寫下一章。這樣真是荒繆極了。根據咱們的經驗，當你寫書時（尤爲是第一次寫書時），你其實不知道書的總體結構會是怎麼樣的。因此你常常會寫下一些東西，而後發現它不該該出如今如今的位置上。因此咱們不會一章一章的寫做，而是讓做者把主要內容寫出來，而後咱們的編輯會和做者一塊兒來爲書梳理架構。因此咱們不會說「這是本書的前五章」，咱們會說「這是本書50%或60%的內容，也許真實出版後的順序會大不同，但這些都是書中的內容」。因此當一本書達到50-60%的時候，編輯贊成的話咱們就會把這本書發佈出來做爲一本beta書。從個人觀點來看，這是很容易作到的，只要按下發布按鈕就能夠了。之因此咱們須要編輯贊成，是由於一般咱們會期待這本書每兩三個月就有一次更新，在書出版以前，做者還有更多內容要放進來。

這樣作的好處就是，首先從讀者來講，先拿到一本技術書是很重要的，若是這本書足夠有趣，就能夠先睹爲快。從做者來講，忽然之間，收到上千條的反饋是頗有意義的。大部分反饋可能都是一些小問題，可是曾經有幾回，有人明確指出了書中的一些錯誤，那麼做者就須要從新寫這個部分。這其實就是咱們想要的。這樣作也讓這本書吸引到了更多的人。當新版本造成時，編輯們會更新改動日誌，而後告知你們新版本已經發布。如今甚至更近了一步，咱們有幾本書，它們永遠處於持續更新狀態。做者贊成，這本書會持續兩年不斷更新，咱們也會在網站上跟進。咱們不會用傳統印刷方法（傳統方法意味着每次更新都要印3000冊書），咱們會採起「按需印刷」的方式。讀者能夠說我要這本書如今這個狀態的紙質版，而後咱們就會印出來發給他。這種方式真的很受歡迎，惟一的問題就是很難找到能和咱們這樣合做的做者。這樣作對於做者來講是有很大回報的，書的銷量會有很大上漲。這樣書的內容既新鮮，壽命也更長久。人們總會爲這樣的書蜂擁而至。若是一本書一出來就已通過時了的話，人們就不會再買了。

圖靈社區：聽起來很不錯，這更像是一種產品，而不是一本書。

Dave：你說得很對，這更像是一個軟件產品。

圖靈社區：在美國還有別家出版社也在這麼作嗎？

Dave：有的。Manning有「先睹爲快計劃」，O'Reilly好像也有相似的項目。要知道，好主意老是被模仿嘛！

翻譯版的技術書籍上市時間通常要晚於原版一年甚至更久。在出版流程的合做方面，能夠在beta階段就由翻譯方介入，加快中文圖書的上市速度嗎？是否考慮與中文翻譯方（圖靈）是否有這方面的討論和進展？

Dave：這個問題咱們每一個禮拜都要被問到。就像上面所說的，咱們的根本問題在於咱們的書不是按章寫成的。若是咱們給大家一本書，其中有50%的內容還沒有完成，那麼一個月後，我再給大家一個新的版本，如今有60%未完成。可是第一章的一半被挪到了第七章，第三章被刪除了，第四章和第二章合併了，並且咱們打算給這種技術換個名字……若是大家拿到這樣的書，譯者可能會出門右轉，了卻今生。若是大家願意嘗試的話，咱們能夠一塊兒試驗，看這樣的方式會怎麼樣。對於咱們來講這樣作很簡單，可是咱們不想爲別人製造痛苦。另外還有一個緣由就是，咱們從未賣過一本尚未完成的書，我我的不喜歡銷售尚未完成的做品，可是這樣作並不是徹底沒有可能。這也就是從咱們系統上只能買到已經正式出版的書籍的版權的緣由。個人擔心是，這麼作有可能會得不償失。可是若是有人想接受這樣的風險，咱們也能夠共同來嘗試。

現代計算機領域的發展真的像某些「專家」說的那樣不多是我的創造歷史的時代了嗎？你們只能依附於大公司的團隊嗎？

Dave：我以爲這些專家真是錯得一塌糊塗。我認爲我的纔是創造歷史的源泉。而大公司只是跟風而至，創造金錢而已。聽起來有點憤世嫉俗，可是事實就是，只有我的纔有那種勇氣和自由來不斷實驗和犯錯。你必須是一個有勇氣的人。

若是你從事的是硬件領域的工做，製藥、製造這些，固然，你須要一個大公司，你須要價值百萬的設備來從事你的工做。可是若是你身處軟件行業，你須要什麼？一臺電腦，足矣！你站在不少巨人的肩膀上，好比Linux, Microsoft，你有用來編譯各類語言的免費編譯器，你有免費的數據庫，你有成功所須要的一切！也許最終確實須要一個團隊來把事情作得更好，可是在開始的一兩年中，你本身就能夠完成偉大的事。事實上我認爲，做爲我的，成功的概率要比大公司高得多。

你須要親身體會風險的感受，你處在前沿，同時你也處在失敗的邊緣。若是你是事務纏身的商務人士，我很難想象你會進入這樣的狀態。

不少公司在招募新人的時候傾向於找具備技術廣度的人，可是做爲程序員可能在某一階段對深刻的研究某些技術感興趣，對於深度和廣度，你認爲在什麼時間點作這樣的抉擇比較合適呢？

Dave：個人經驗偏偏相反，我認爲大多數公司在招人的時候並不看重知識面寬廣與否。他們有不少坑，他們只想找到可以填充到那個坑裏的蘿蔔就行了。他們招人的要求很是具體，程序員面試的時候會作一些編程測驗，只要他們能作這份工做就能夠了。他們填完這個坑，就開始盤算填下個坑。若是你是一位程序員，你想被通常的破公司僱傭，那你只要看看他們的要求，而後把你的經驗填進去就能夠了。這真是慘絕人寰。

有兩種程序員，一種人把編程看成工做，一種餬口的手藝。他們早上上班，而後編程，而後下班。他們在工做之餘從不想關於編程的任何事，他們不看相關書籍，也不會和朋友們聊到這些事，這只是一份工做而已。對於這些人，他們在坑裏也很開心。可是若是你所說的是優秀的程序員，那他們想都不應想跳到這些坑裏去。他們在這樣的環境下會窒息。他們須要的是找到那些不根據那些條條框框招人的公司。這樣的公司須要的是「聰明人」，能夠溝通的人，有激情的人。這也是咱們的目標讀者，這也是我想要僱傭的人。

我多是世界上最差的僱主，我招來的人要麼就是完美的，要麼就是一場災難。我看人最重要的一點始終是熱情。我招的人可能只有一半接受過正式的計算機相關教育，其餘的人都是自學的。可是這些自學的人基本上都是更優秀的開發者。

若是你的工做和事業是軟件開發，你的熱情也在於軟件開發。那你就必需要不斷學習。若是你不持續學習的話，你就會過期，你的技巧會沒有用武之地，你也體會不到樂趣。做爲程序員，你應該始終領先於潮流一點點。若是你們都在看Java，你應該學Ruby，若是你們都在學Ruby，你應該看Scala或者Elixir，或者其餘什麼。有的人會說，我上班的時候太忙，沒有時間。我要說，這不是你的工做，這是你的事業，這是你的生活。

現代編程提倡讓他人理解最重要，斯坦福大學的老師甚至說註釋和代碼同樣重要。冗長的註釋會不會讓代碼的簡潔性大打折扣？

Dave：我不太一樣這種說法。我認爲註釋會讓代碼更不容易理解。我認爲註釋是一個藉口，爲了你表意不明的代碼找的藉口。若是你認爲你的代碼很複雜，或者有些問題沒寫清楚，那你就會想爲你的代碼寫一段註釋。別這麼作！你的代碼有問題，解決代碼的問題先，讓它變得清晰、易懂。若是某家公司有一個編程標準，說程序員必須爲代碼寫上大把的註釋。快停下來吧！這都是些不相干的事。程序員的產出應該是商業價值，註釋並無增長任何商業價值。我用註釋嗎？我確實用，可是極少。基本上，我都是在本身沒有能力把代碼變得更好的狀況下才寫註釋。對於我來講，註釋是一個「這段代碼有問題」的信號。

您以爲數學和編程的關係怎麼樣？最近Google大牛Steve Yegge以爲數學很重要，您以爲二者關係大嗎？

Dave：我不認爲數學是必學的功課。可是我認可，有一些人的思惟和軟件開發的思路很契合，這種思惟追尋模式，尋找事物之間的聯繫，能把各類各樣的東西結合在一塊兒。這可能也是數學家們的思惟方式。可是我知道不少音樂家也可以作到這些。若是有一屋子的程序員，你問問他們誰會演奏樂器，你的結果差很少應該是30-40%。我不知道對於通常人來講，這樣的比例是多少，可是應該達不到這麼高。程序員們演奏起樂器來可能比普通人更擅長。個人朋友Chad Fowler（《Ruby編程（第2版）》合著者之一）原來是一位職業薩克斯表演者，他曾經在田納西的孟菲斯樂團演奏。個人合做夥伴Andy是一位爵士鼓表演者。我認識的不少人都會表演樂器。可能有些人的大腦和思惟方式更適合作這些事。

程序員可能會擅長於數學，或擅長於音樂，可是我不認爲必需要有很深的數學功底，才能成爲一位開發者。

圖靈社區：我在您的網站上看到了您寫的音樂。

Dave：是，我是做了一些曲子，可是個人問題是我不會表演。演奏我曲子的是另外一位程序員，如今他正在一個和爵士樂相關的開源項目上。咱們共同創做了這首7分鐘長的曲子。

據說您對中國的教育事業很感興趣，是真的嗎？

Dave：我對中國的兩件事很感興趣，不不，實際上是不少事（笑）。 第一件事軟件開發，我去過世界不少地方，也見過世界各地的程序員。每一個地方作事情的方式都不同，這種區別一般以國家爲界。我想理解每一個國家的文化是如何影響當地的軟件開發過程的。這只是個人一個愛好。好比說在日本，那裏的文化要求全部人的意見都能統一，甚至是沒法統一的狀況。因此和那裏的程序員交流挺沒意思的。他們只能看到須要他們來修補的東西，他們必須是團隊的一員。這是不對的，這樣的作的結果就是整個的開發流程也會因地制宜，受到影響。我也想了解中國的程序員是如何工做的，可是如今我尚未掌握足夠的信息。

至少在美國，在大公司上班的程序員不少都有本身的項目。他們在公司上班的狀態也是不固定的，他們常常上一陣班，而後再賦閒在家開發一段時間。我以爲這樣的混合經歷會讓他們能夠常常換換腦筋。我感受中國的狀況可能不是這樣，可是我不肯定，我還須要和更多的人交流。

另一件事就是教育。在美國，軟件開發在學生中間不是很受歡迎的專業。在大學學計算機相關專業的學生在減小。我認爲這是一場危機。由於這就意味着咱們講沒有足夠的人才，咱們有可能會落後於世界。這在美國是一個問題，因此我一直都想辦法讓美國的青少年對軟件開發更感興趣。我一直在嘗試，可是始終沒有找到好的方法。在美國，女性程序員的比例小於20%，在其餘職業中的比例小於50%。我但願這個情況能夠改善，至少能夠增長開發者的總體人數。這件事的意義固然不止於此，我不知道形成這樣結果的緣由是什麼。是遺傳生理上的差別，仍是現有軟件社區很醜陋，排斥女性加入。我知道中國的狀況可能還不如美國。不知道這樣的狀況經過讓青少年增長接觸編程的機會可否有所改善。對於有些人來講，軟件會是一件頗有趣的事，畢竟這是爲數很少的憑藉單槍匹馬就能夠改變世界的事。你能夠改變現實，經過打字，就可以創造一片天地。若是咱們能把這樣的思想傳遞出去，也許就會有愈來愈多的人來學習編程了。這就意味着咱們必需要實現承諾，讓公司們明白，軟件不是填坑就能夠了，要讓程序員們有空間發揮本身的熱情，創造出更傑出的產品。

從這個意義上講我確實對教育很感興趣。好比說在美國有一個項目，讓無業和窮苦的人們接受教育，學習新技能。軟件是一個學習成本很低的技能。有的機構向貧苦的孩子們捐助電腦，幫助他們學習，這真是好事一樁。讓每一個人都有機會接觸電腦，不僅是玩遊戲，而是親手創造一些什麼。

據說您正在寫一本關於用Elixir編程的書，能告訴咱們Elixir最吸引你的地方是什麼嗎？

Dave：由於我喜歡！這其實就是最根本的緣由。Elixir能讓我微笑，因此我願意和別人分享這樣的快樂。對於Ruby來講也是這樣，我想和別人分享這份愉悅。

從另外一個層次說，軟件世界在發生變化。每隔兩年，計算機的數量就會翻一番。爲了適應時代，咱們必須改變計算機工做的方式。在過去，咱們作的就是讓計算機變得更快。如今，計算機裏的處理器更多了，個人筆記本是四核的，也許明年就是16核或32核的了。因此做爲軟件開發者，咱們沒有選擇，咱們須要寫出在這些機器上運行良好的代碼。這又回到移動設備上的問題，這些代碼不只要在不一樣的設備上運行，還要在同一設備上的不一樣處理器上運行。用傳統編程語言，好比Java、C#或Ruby，要寫出多核運做的正確代碼是很困難的。Elixir是一門以Erlang爲基礎的語言，Erlang已經誕生了30年。這門語言的很大一個部分就是Erlang虛擬機，它能夠支持數以百萬計的處理器，它們以極高的效率相互通信。它能夠頗有效地調控這些處理器，若是其中一個壞掉了，仍能在不影響其餘處理器的狀況下繼續工做。它也能夠改變處理器，而不須要影響到正在運行的應用。因此在電話中轉中，不少軟件都是用Erlang寫的。啓動轉換以後，運行不會中止。這些都是很好的特性。可是，Erlang語言自己卻十分醜陋。雖然確實有人喜歡這門語言，但它對程序員並不友好，至少能夠說獨樹一幟到使人擔心的程度了。

Elixir是將與Ruby相似的句法，放在Erlang虛擬機上。這樣既能夠獲得虛擬機的好處，又能夠寫出更加平易近人的代碼。不只如此，Elixir還能夠利用虛擬機作到Erlang也作不到的事。在Elixir裏什麼都是能夠改變的，程序員會以爲頗有趣，還能夠避免Erlang裏的重複代碼。因此你寫出來的代碼會更短，也更容易改變。在將來，我以爲Elixir能夠用在大型分佈式系統上面，它能夠用在大容量，大量事務的環境中。它也能夠爲創業者們服務，爲他們完成用傳統方法沒法完成的事。創業者們永遠都在找從前沒法實現的事，具體是什麼呢？我不知道，若是我知道的話就去創業了。他們能夠嘗試從鏈接全部東西，和不少東西交互的角度來考慮（好比和洗碗機，或者洗衣機交流）。我對此充滿了期待。

---

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