作者: jjhou (jjhou)
標題: 【汗如雨下 . 雜感】
時間: Wed Nov 4 18:11:57 1998
【汗如雨下.雜感】
侯俊傑 jjhou@ccca.nctu.edu.tw
1998.11.04 第一次發表於
清大.楓橋驛站（140.114.87.5）.電腦書訊版（CompBook）
----------------------------------------------------
●讀者、作者、出版社
在此回應網友對於 <侯俊傑 1998 寫作計劃.4> 的幾個意見。
首先是網友 hlin2 的意見：
> 侯sir 的翻譯功力自然是沒話說, 但是, 建議不要將書給松崗出版.
>
> 不是我對松崗有偏見, 實在是松崗的做事態度有問題, 印刷品質差,
> 一本書裡面是 東缺頁,西印不明, 一點也不像國內屬一屬二的出版公司,
> 甚至有些書請人譯, 也譯的不清不處, 如果是第一次請這位譯者翻譯的,
> 不知此譯者的翻譯功力, 那也就算了,
> 若是只因譯者有高學歷及高經歷而讓他一而再,
> 再而三, 亂翻一通, 也還不知檢討改進, 那就有問題了.
> 雖說人非聖賢, 孰人無過,
> 就算是有誤譯或是排版有疏失,下一版甚至是第二刷就要訂正它.
> 印刷公司沒印好, 就該引入品管制度來改進,再不改進就換掉它,
> 市場反應一本書翻譯沒翻好, 就該請譯者檢討,如果下一本書出版,
> 在市場上的風評還是很差,
> 表示此譯者不適任翻譯, 那就要換人做做看.
> 這就是我所言的正確的做事態度, 也是愛惜羽毛的表現.
然後是網友 catfox 的意見：
> 沒錯，我手上這本侯sir的書就是一例。時常有印不好..好在都是在
> 程式列表..了不起看一下光碟就是了算是好運吧..
> 如果不是侯sir的書我也是不買松岡...旗標和基峰可以接受
> 但不滿意/..還是國外的好...如果不論書類，日本的最好..
hlin2 和 catfox 所說的，每一家出版公司都應該引為殷鑑。
著作和翻譯的品質上，我所認識的各出版社幾乎都乏力駕馭，
每一家分數打下來，都不太好看。如果把書籍的印刷裝訂、封面
設計、版面設計視為硬體水準，把書籍的內容（高低階分佈、
正確性、錯誤率）視為軟體水準，我個人認為，各出版社的硬體
水準都差不多，旗標則在軟體平均水準上比較突出。不過我也
欣然見到，許多出版社儘管無力全面控制品質，至少願意在某些
高階書籍上花心血。
追求高成長的過程中，避免不了地，落入俗套地，大家都付出了
代價。舉個例子，一家公司原本 50 個人，一年出 30 本書，品質
管控良好。現在一舉擴大為每年出 100 本書，人數卻只增加為
70 人，品質必然維持不了以前的水平。
踩在從前的光環上，或是踩在強力行銷策略鋪出的捷徑上，或可
維持目標中的高成長。但是光環需要擦拭，否則銅綠更顯難看；
強力行銷策略，在市場上或可印證成功，但書籍乃極為特殊的一
種商品，其消費者懷有千年來「萬般皆下品，唯有讀書高」的獨
特情懷；在我們這種人（也許被視為食古不化）的眼裡，光環與
敬意的流失，是一種高成長後的慘痛代價，不是任何高利潤所能
彌補的。
是以，兩位之所言，每一家出版公司都應該引為殷鑑。
「出版品質」應該是作者努力、出版社把關、讀者享受的一件事情，
但如果讀者能夠參與其中，爭取一點自己的福利，是不是身為讀者
的我們，都願意這麼做呢？我看卻又未必！
我指的是硬體的品質，更狹窄地說單指印刷品質。今年九月，
<深入淺出 MFC> 即將印行二版五刷，恰巧當時連著兩位讀者寫
email 給我，告訴我他們購買的 <深入淺出 MFC> 好多頁印刷不清。
於是我檢查了手上的第四刷，確實發現這種情況，便列出所有
不理想的頁次，而松崗也從善如流地將這些頁次重新製版。
如果沒有那兩封 email，我也無從察知這些問題。
（就印刷技術的角度去想，我不知道為什麼這些頁次會模糊，因為
第二刷沒有這種情況，而二至四刷之間並無任何更動）
松崗公司甚至願意配合我在 <多型與虛擬> 第二刷就更換幾達 80 頁
的版面（影響所及，幾乎原書全部重新製版），只因我希望精益求精
地修潤少量文字。
我們讀者是否都願意就書籍的優缺點，寫在免貼郵票的回函卡上，
寄給出版社，讓好的發揚，壞的改善呢？沒有，99% 的讀者懶得
這麼做！罵還是要罵的，但是...動手寫...唔...有點懶耶！
出版社未能在發書之前檢驗出印刷的問題，這一點，身為作者
以及讀者的我，考量到出版業務的實際情況，可以諒解。
如果我指出了這個缺點，而出版社卻沒有回應，那就不可原諒。
再者，一如我從前所言，一本書的內容修訂，作者自己是否
配合，配合度如何，也只有合作雙方心知肚明。
松崗公司對於我所指出的缺點，都儘力做了修正，所以我必須就
這一點為他們說句公道話。
我不知道如果讀者直接向出版公司反應，或其他作者向出版公司
反應這類事情，會有什麼結果。我不能純做臆測，我也不會阿Ｑ地
否認社會上普遍存在的「人微言輕」的事實。當然，我由衷希望，
每一個善意的建言都被每一家出版公司接納「並採行」。
●關於 <Win32 作業系統 - 基本教義派>
這是網友在討論 <拜託推薦一本 SDK 中文書> 時的 post 內容：
> 侯俊傑老師的 Win32 的書,看了公告才知道出到80%
> 大概要明年6月不知道會不會好???
另一位說：
> 不過我想這一本是要有SDK基礎
> 而不是教你如何寫 SDK 程式.... ^__^
> BTW, 希望明年初就可以出版
我的這本 <Win32 作業系統 - 基本教義派>，原本鋪陳浩大，涵蓋面廣。
但是考量自己的時間，對於一些自己不再那麼有興趣的題目，也就慢慢割捨。
割捨到現在的結果，這本書的定位是（還有可能再變）：
■讀者技術基礎：C，SDK，OS common sense
■適合對象：對作業系統工作原理有強烈興趣，並具備上述「讀者技術基礎」的人。
■內容：以大量圖解和實例的方式，介紹 Win32 平台（Win9x 為主，WinNT 為輔）
上的各種系統觀念，包括：
overview、Win32 API programming model（message based, event driven）、
process、module、thread、task、address space、context switch、
executable file format（NE/PE）、secrets of dynamic link、
virtual machine、VxD programming basic、
NT kernel mode driver basic、
window management、message management...
所以，千萬別誤會，這不是一本教你 SDK programming 的書，這是一本
作業系統書籍，焦點放在 Windows 平台上。資訊人在大三修過 <作業系統>
課程，如果對於 context switch, process/thread... 等觀念與實作技術
不解而好奇（我相信你一定不解，因為作業系統教科書沒有辦法細部
講解某一平台上的實作技術），那麼你可以從此書認識 Windows 的
實作法。
●得魚而忘筌
這讓我聯想到我一直鼓勵的「紮根基」學習方式。前不久我在版上
貼了一篇 <C++ 的沉迷與愛戀>，曾被網友譏為「老人」的學習方式，
並質疑難道學習 Java 也得把 Java virtual machine 搞懂才可以？
我的想法是，就拿作業系統的學習而言，為什麼要寫上述那樣一本書呢？
我們沒有人想自己寫一個作業系統呀，但是教科書上所說的那些邏輯的、
籠統的、抽象的方法，沒有辦法令我們安心。如果能夠拿某個平台的
實際作法，與教科書上的一般化概念兩相比對，我們就可以「落袋為安」。
特定平台上的技術，雖然不具代表性，卻是一個具體的東西，加強並提昇
我們原本模模糊糊的概念，使我們胸有成竹。
我要的，便是這種「胸中自有丘壑」的感覺。從基礎知識中受惠的眾多
讀者，要的應該也是這種「胸中自有丘壑」的感覺。
回到 C++ 話題。我們懂得各種底層事務與技術，也許對 programming
沒有直接明顯的幫助，但對相關的技術思維，卻絕對有幫助。
如果不懂 C++ Object Model，我幾乎可以斷言，不可能懂
Component Object Model。會寫 Actives control 是一回事，
懂得其中運作原理是另一種層次。
不要得魚而忘筌呀，身為高手的你。
對於基礎知識的建立，我一直認為適可而止。以 C++/OOP 為例，
我的目標直指 Polymorphism，但學習過程中必須對 virtual functions
的底層意義（實作方法）徹底掌握，所以才回頭學習屬於 C++ Object Model
層次的 vptr 和 vtbl 這部份。至於其他如 template instantiation 機制、
ctor/dtor 機制、bitwise/memberwise copy、exception handling...，
可以留到必要時再學習。
對於基礎知識的建立，我從來就認為要反覆振盪。不能光停留在底層。
並非底層不是一門學問（object model 是門大學問，framework
是門大學問），而是，從「application 開發」的角度來看，大部份人
要的是「基礎建設為體，實務運用為用」。
回過頭說，如果什麼都從「application 的開發」角度出發，
眼光其實已經狹隘了。
容我這樣回答：如果我已從 C++ virtual functions 的困惑中解脫，
我就不會想在學習 java 時再挖一次 java virtual machine 對於
virtual functions 的實作法。如果我已從 MFC infrastructure 的
困惑中解脫，我就不會想在學習 OWL 或 VCL 時再挖一次內部機制。
（除非又出現什麼讓我大惑不解的東西）。如果我已從 Windows 的
內部結構與演算法中知道一個作業系統是如何地管理 processes 和 threads，
如何 context switching，如何 dynamic linking，我就不會想在
UNIX 再挖一遍（除非有實際需要）。
這是我的學習原則。
●關於 RAD（Rapid Application Development）
<Delphi 學習筆記> 作者錢達智先生，是我的好友。我們之間對於 RAD
有段討論，或許你想聽。
■侯：BBS（News）上時有關於 RAD 的工具見解。我認為你很夠資格
說些話。不少人對 RAD 有誤解。如果你能點醒大家 :
(1) RAD 是很好的開發工具
(2) 使用 RAD 並不代表不需要底層紮實的基礎，
那麼誤解的人就會比較少一點，知道該怎麼做的人就會比較多一點。
■錢：過去在 DelphiChat、NEWS Group 以及我的書中，這樣的想法
都不只一次宣揚過。
其實，就我接觸過的人，不論是網路或者是學生，RAD的使用者的確
是比較急功近利，也難怪會有這樣的刻板印象。 :(
雖然說過，但還是要持續宣揚這種理念，就如大哥說的，誤解的人
會少一點，知道該怎麼做的人就會比較多一點。
這些天，一得空就翻譯書籍，翻著翻著，上述的感覺就愈來愈強
烈，但也愈來愈感到不對勁。
過去，我曾以比較純手工的方式寫過 CGI 與 ISAPI 程式，等累
積了一些經驗後，便先以 FrontPage 之類的工具編輯好一些樣
版 HTML 檔(HTML Template)備用，這些檔案中都已事前預留一
些註解或者特殊標籤(Tag)。然後，網站程式就視情況讀取這些
HTML 檔，將其中的標籤替換即可。
總之，累積經驗久了，就會找到自己的工作模式。至於 Delphi
的 WebBroker 元件，所用的大致上也正是我過去採用的模式，
同樣也是「替換標籤」，只是現在更為方便，與其他諸如資料庫
元件的互動而為一體，十分具威力。
由於過去在網頁設計與網站程式開發的經驗，當然了解為何
Delphi 採用這種方式，而且也容易接受這樣的作法。因此，當
然能體會這點：
>(1) RAD 是很好的開發工具
不過，我也覺得這中間總有什麼地方不太對勁，推論是這樣的：
接受這些 WebBroker 元件，其實也就等於接受了這些元件所安
排的工作模式，而這個工作模式又如此地經驗豐富。換成是我自
己動手設計，恐怕也無法比它好，既然如此，以下這句話就顯得
弔詭了：
>(2) 使用 RAD 並不代表不需要底層紮實的基礎，
因為，這正好是「不需底層紮實的基礎」理由。的確，RAD 使
用者所企求的不正是－－讓具有「底層紮實基礎」的人完成元
件，使得不具「底層紮實的基礎」的人也能快速地完成應用程
式。
從這個角度來看，反而「不需底層紮實的基礎」就可寫程式，
想具有「底層紮實的基礎」再來寫程式，可能得研究很久之後
才可以開始寫程式。結果，一個不具「底層紮實的基礎」的人，
卻仍有「底層紮實基礎」的效果，因為，那位具有「底層紮實
的基礎」的人訂下了相當不錯的格局。有趣的是，對於了解來
龍去脈的人而言，會更體會 WebBroker 這組元件真的寫得很不
錯，於是，也接受相同的工作模式，這時候，除了多一份心安
理得，兩種人最後所做的工作，表面上是差不多的。
簡單地說，「具備底層紮實基礎的人」，寫出來的會是類似「
不具底層紮實基礎的人」的人正在使用的元件。
因此，我在想，該拿什麼理由，支持這些普遍功利的RAD使用者
也花一點時間多一點研究 －－ 特別是當他們面對專案完成的
壓力、面對這樣快速變化的技術環境時．．．
上週，當我列出一些步驟，應用 Delphi 的 MIDAS 那組元件，
就讓可以說完全不明白 DCOM 是什麼的學員實作出一個應用
DCOM 技術的 Application Server，寫好一組 3 Tier Client/
Server 程式，而且，與他們過去開發資料庫應用程式的經驗
相去不遠。那時，我不免要提到 MIDAS 包裝了 DCOM 等技術，
然而，當我想要更進一步時，卻發現難以啟齒於 MIDAS 所蘊含
的 DCOM 與 CORBA．．．當時，課程已近尾聲，我卻發現學員
未來竟有這麼多東西要學。
■侯：我常舉一個例子：
剛拿到駕照的人，凌晨 03:00 把車開上台北敦化大道，此時
月明星稀，車少人稀。他不禁大喊：開車有什麼難的，我會開車，
在台北開車。
下午 17:30，他把車開上台北基隆路，此時車水馬龍，萬頭鑽動，
狀況多得不得了。他滿頭大汗，動也不敢動，還被後面叭。不禁
大喊：行路難。
是的，按圖索驥，拼湊串聯出一個和其他人都差不多的產品，可以
滿足某種層面的需求。但是一個真正的 software developor 所
需要的，是解決問題的能力，以及源源創意背後的技術支撐。
我敢說，在你所舉的例子中，接受了相同的 WebBroker 工作模式的
兩種人（一具底層紮實基礎，一否），其變通力和領悟力必是截然
不同。在他們日後應用或觸類旁通的學習上，亦將有截然不同的結果。
> 這時候，除了多一份心安理得，兩種人最後所做的工作，
> 表面上是差不多的。
表面上是差不多，但我們如果深入去和他們談談，我想實際上差不少。
當然我不認為「底層紮實基礎」應該是全民運動。工具的使用以及
使用的程度與層次，應該視實際應用而定。如果只是要隨機出貨一個
多媒體播放面板軟體，用 RAD 一個小時搞定，那時「底層紮實
基礎」就無足輕重。只是，你我所教育的，是科班學子，是資訊系
學生，是業界工程師，所以我時時強調「底層紮實基礎」的觀念。
朋友曾銘源在紐約 CA 軟體公司任職。他的工作（前些年）是負責
該公司軟體的 UI。他們都不使用 MFC controls，而自行以 SDK 完成。
我問他為什麼？他說等 MFC 包裝起來，時機已慢，而且包得不一定
符合他的需要。
連 MFC controls 都不用，為了 timing。這是對技術需求的另一層級。
> 因此，我在想，該拿什麼理由，支持這些普遍功利的RAD使用者
> 也花一點時間多一點研究 －－ 特別是當他們面對專案完成的
> 壓力、面對這樣快速變化的技術環境時．．．
你我都是重視「底層紮實基礎」的人。但不知我這樣的回答，
是否能夠成為一種對他人具說服力的理由。
●汗如雨下
才剛向讀者報告過，<System Programming for Windwos 95> 的中譯稿
刻正拿給華碩的朋友檢閱。昨天得到回覆及校正稿。對 chap11~chap16
（各種 drivers 的實作）有嚴厲的評語。
看得我汗如雨下，甚覺愧赧。一夜難眠！
當初決定譯此書，著眼於此書對臺灣（尤其科學園區內）的工程師的
重大幫助。雖知是苦差事，仍願為之。此書前半我可掌握，
後半（drivers 實務）非我所長，所以一開始即商請硬體專長的朋友
協助 chap11~chap16，最後再由我總潤（這算是第一次合譯模式了）。
但朋友的進度嚴重落後，平均下來 2~3 天才得一頁成果。最後只好
我自己接下他的份量。
因為知道自己的 weakness，所以才邀請真正的專家斧正。專家的回應，
讓我更清楚體會到，隔行如隔山；面對一個不熟悉的領域，會譯出什麼
樣可笑的東西出來。這使我汗如雨下，臉上長線（櫻桃小丸子）。
這本書不能如預期地於 11/06 交稿了，我需要好好參酌專家的意見，
改到正確與滿意為止。
我也聯想到「腐化」這個問題。這是一個警訊。顯然我在 1998 年安排了
太多的工作。好東西需要雕琢與反覆檢查。時間不夠，就沒有辦法
雕琢與反覆；實力不足，就很容易把隱微處看錯並譯錯。
這對我是個警訊。上次 post【新血輪替.雜感】時曾回覆 Roy：
『David Kruglinski 的 <Inside Visual C++> 系列與我十分有緣，
同時也是很值得翻譯的好書。我不排除任何可能。看機緣吧』
現在決定不譯了（不管有沒有人來找我）。1999 還是以幾本著作的
大改版，以及 <C++ Primer> 3/e 的翻譯為要。
--- the end
--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ Mail: Xshadow@cs.nthu.edu.tw
※ X-Info: Mave -> ric.bbs@ptt.csie.ntu.edu.tw
※ X-Sign: 0ROABM2PH7DOJTDR3J4E (99/07/09 7:05:38 )