Dave Thomas：一個開發者的為與不為（圖靈訪談）

我們在RubyCon 2013遇到了Dave Thomas。作為一位開發者，他充滿了熱情，他相信這是個屬於勇敢者的時代。對於業界存在的問題，他痛心疾首，並不斷尋求著解決方法。作為一位出版人，他務實、精明，時刻為自己的作者著想，也為像他一樣的開發者蒐羅好書。他是一位不折不扣的Pragmatic Programmer。

Dave Thomas是一位程式設計師，同時也是一位作者和出版人。他和Andy Hunt一起開辦了出版公司The Pragmatic Bookshelf，他們整個線上業務都是他和Andy用Ruby建立的。他的個人作品包括《Web開發敏捷之道》、《Programming Ruby》。他和Andy共同寫作了《程式設計師修煉之道》，這本書也是The Pragmatic Bookshelf品牌下的第一本書。

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

Dave：在過去的8年中，我用Ruby做所有的事！我們整個的線上業務都是用Ruby寫的。如果你成為我們的作者，我們用來形成一本書的軟體也是用Ruby寫的。所以可以說Ruby就是我們公司的全部。另外，我幾乎每天都會寫Ruby指令碼，這是我生活的一大享受。我的記性很差，如果我生活中能找到任何可以自動化的步驟，我一定會把它自動化，這樣我的生活就會更加簡單。

在開始的時候Ruby社群人很少，第一次聚會的時候大概只有30人。所以參與這麼小的社群其實只是和朋友打交道而已。說到開源社群的貢獻，我大概寫了有4、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個月內完成，第二、第三、第四章要在……所以作者們寫完一章就繼續寫下一章。這樣真是荒繆極了。根據我們的經驗，當你寫書時（尤其是第一次寫書時），你其實不知道書的整體結構會是怎麼樣的。所以你經常會寫下一些東西，然後發現它不應該出現在現在的位置上。所以我們不會一章一章的寫作，而是讓作者把主要內容寫出來，然後我們的編輯會和作者一起來為書梳理架構。所以我們不會說“這是本書的前五章”，我們會說“這是本書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可以用在大型分散式系統上面，它可以用在大容量，大量事務的環境中。它也可以為創業者們服務，為他們完成用傳統方法無法完成的事。創業者們永遠都在找從前無法實現的事，具體是什麼呢？我不知道，如果我知道的話就去創業了。他們可以嘗試從連線所有東西，和很多東西互動的角度來考慮（比如和洗碗機，或者洗衣機交流）。我對此充滿了期待。

Dave Thomas在Ruby大會現場為讀者簽名

enter image description here