[人物專訪]為什麼我喜歡由 O'Reilly 出版我的書
本文由《Java I/O》一書作者 Elliotte Rusty Harold 執筆
1997 年九月，我開始撰寫《Java I/O》一書，當時我估計花兩個月寫出約兩百頁的內容就可竣工了，但其實不然，真正 完工已經是一年半後的事，而篇幅也暴增到 600 頁。在這一年半中，我盡了最大的心力。本書的出版，許多功勞要歸於 O'Reilly 公司，他們讓我以及其它作者能全心雕塑出一個好作品，不會為了市場商機而催促我們盡快趕工。電腦書籍讀者都知道 O'Reilly 的書品質可靠，信譽卓越，絕非書架上那一大堆號稱《Special Edition Teach Yourself Java in 21 Minutes for Dummies Master Reference》（譯者註 1）的 Franken（譯者註 2）所著之書可以比得上的。O'Reilly 的這些書好在哪裡？原因或許眾說分歧，但我會在本文告訴你一些幕後點滴， 讓你知道 O'Reilly 是如何作書的。
譯者註 1：當然沒有《Special Edition Teach Yourself Java in 21 Minutes for Dummies Master Reference》這本書，我刻意不翻譯，希望你能從中 看出 Harold 在影射哪些書。呵呵！他還真毒，用一個杜撰的書名修理到一堆人。
譯者註 2：作者 Harold 用 Franken 隱喻 Frankenstein。Frankenstein 是英國Mary W. Shelley 女士所著小說《1818》中的人物，書中的 Frankenstein 最後被自己所創的科學怪人所殺。Frankenstein 意指「自食其果、作法自斃之人」。
O'Reilly 的書為什麼比較好？大家直覺的想法是：因為 O'Reilly 的作者比較優秀。這個說法不太行的通，畢竟大多數 O'Reilly 的作家也兼為其它出版社寫書。以我個人來說， 就曾經在 IDG、Prentice Hall、以及 O'Reilly 寫過書，不過我在各家出版社的遭遇都還不錯，比起其他跨出版社的作者，我的情況算是幸運的。
O'Reilly 的書內容比較完整而且錯誤少。可能因為如此，他們的書也銷售得較好。我在 O'Reilly 的第一本書《Java Network Programming》所賣出的量已經超過我其它四本書的總和。唔！我認為 O'Reilly 的書鶴立雞群的主要原因有二：
- 更充裕的撰寫時間
- 更良好的編輯環境
好書有如好酒，需要時間的醞釀。只花三個月寫出一本 300 頁到 1200 頁的書，然後希望此書能內容完備而且零錯誤，這簡直是「不可能的任務」。最多你只能祈求書中的錯誤 不要太明顯、不要太折騰人，就謝天謝地了。而且，對電腦書而言，在一般的時間規劃上，初稿會在二到四個月之間完成，時間如此急迫，根本來不及糾正所有的錯誤。事實上， 作者會盡量花時間在寫出內容，而不太花時間去檢查內容的正確與否。如果作者對某件事不太確定，他們會選最有可能的那一項，然後就假定真的如此，繼續埋頭苦幹地寫下去。 如果作者對某內容真的不懂，就乾脆把這部分完全略過，隻字不提，而不會去花時間研究。當然，作者自己也不希望這樣，但限於時間急迫，也莫可奈何。
在我寫作《Java I/O》的期間，時間相當充裕。我可以逐句思考我下筆的每個句子；如果我對某件事不太確定，我會去圖書館研究一番；我還透過電子郵件向某規格書或某 API 的設計者請益相關細節，我甚至有空等他們回覆，不急於寫新的內容。這段時間，花上一整天進行一些背景知識的研究是常有的事，這麼做的目的也只是確保我所寫出的每個句子 都正確無誤。如果我不確定某個 method 的功用，或者我的腦海中有那麼一絲絲的懷疑，我可以花一個下午的時間窮追不捨。在我寫第 10 章〈Cryptographic Streams〉之前， 我花了一個星期專心地讀 Bruce Schneier 的《Applied Cryptography》來確定我所有的觀念都清晰正確。在寫第 9 章〈Compressing Streams〉以及 第 17 章〈The Java Communications API〉之前，我也做過類似的功夫。在補強完這三章相關的基本知識之後，我每章都花了約一個月的時間撰寫完成。如果我當初是在 O'Reilly 以外的出版社，光弄完這三章就已經到整本書的截稿日期了，因為這本書是要給 O'Reilly 出版的，所以我才可以慢工出細活。
為了爭取時效，許多出版公司會在作者寫稿的同時就進行編排。但是，作者可能會努力地每天寫出新的 10 頁到 20 頁內容，好能夠在截稿前全部寫完。因為太趕了，所以他們大概沒空去檢視並修改過去寫的內容，這使得作者所能檢視的部分相當有限。
對電腦書而言，作者親自校稿相當重要，因為編輯常常只專精於文采，沒有技術背景。這些編輯知道如何將枯燥的句子變得生動，或讓初學者更易懂，但是他們常會在 修改的過程中造成技術上的錯誤而不自知。他們對於此技術的第一次接觸往往正是在第一次拿到手稿時，之前毫無經驗，所以根本無法抓出作者自身所犯的技術錯誤。許多出版社會 僱請外面的人當技術編輯，但通常又只是聊備一格。結果就像評議會的員工說的「他們假裝有付錢給我們，我們假裝有工作」的故作姿態（譯者註3）。當然也不是沒有例外，但以我的經驗來說，我寫的書的技術編輯常常對我的內容毫無意見，我希望原因在於我寫的內容無懈可擊，而不是因為 他們偷懶，但真相恐怕非我所願。
譯者註 3：這一點我的印象深刻。某家原文出版社所出版的書在書的封底都會有一個類似郵局戳記的標章，上面寫著「Approved by Dr. Xyz & ZyxSoft」，但我常發現他們的書問題多多。
除了提供合理的寫作時間以及適當的校稿次數之外，O'Reilly 還提供了技術編輯。Mike Loukides 是《Java I/O》和《Java Network Programming》兩書的主要編輯，他在我的 手稿中挑出的錯誤個數比我其他編輯們所挑出錯誤個數的總和還多。因為 Mike 本身就扮演著我未來讀者的角色，當他告訴我，他對我手稿中的某處內容不甚瞭解時，我就瞭解 是我哪裡寫的不夠好，應該重寫。如果我在 O'Reilly 以外的公司寫書的話，當編輯告訴我他對哪裡不懂時，我需要自行判斷他們不懂的原因是否因為他們根本就沒有本書讀者該有 的基礎（我不打算把書寫得連販夫走卒都看得懂，免得造成我真正讀者的困擾），還是因為我表達得不夠清楚而致之。
我要說的不是：「O'Reilly 有一個特別能幹的編輯，我很幸運地和他共事，而 O'Reilly 的其它人都很差勁」。當其它出版社使用一個技術審閱人員（也許有兩個，兩個願意將 微薄的酬勞再平分的可憐蟲）的時候，O'Reilly 卻通常用了五個在該領域中頗負盛名的專家。當 O'Reilly 的一個版本編輯宣稱找到一個錯誤，差不多可以肯定真的是錯誤了。 他們可以為你潤釋文句，切割過長的句構，也可以處理編輯上的細節，而這些細節往往是那些其它出版社中讀多了小說非技術書籍的編輯們無法照應的，比方說：在「InputStream and OutputStream are the most important classes in the java.io package.」句子中，什麼字詞應該用什麼字體。一本電腦書的完成牽涉的人相當多：版面的編排配置、行銷 規劃、網頁設計、封面設計......等等。O'Reilly 的這些人員每個都相當優秀，不僅是因為他們認真負責，也因為他們對於出版品內容技術已有深入的認知。這些人願意瞭解也能夠 瞭解一個作家的思路，使得書的產生過程百分之一千地順利。
也因此，許多作者認為幫 O'Reilly 寫書是一大樂趣。在這裡，我們可以寫出我們自己感到驕傲的作品。有一些來自 IDG 和 Macmillan 的電腦出版部門名氣響叮噹的作者最近 已經開始為 O'Reilly 寫書了。對於讀者來說，這是好事，你可以擁有言之有物的書、擁有知識的寶庫，而非只是趕著出版好在市場上卡位的剪刀漿糊之作；你可以有一本書，即使 經歷過數度軟體的小改版之後，依然有價值。O'Reilly 的書向來別樹一幟，但理由不在封面的動物，而是因為它們真的是比較好的書。 |