April 10, 2008

對自己好一些:談技術手冊閱讀


想當年 (好像人老了,就喜歡說這句),我們若沒有把技術手冊閱讀懂,是不敢坐在工作站前面,深怕一不小心,把系統組態弄壞,或者是因為反覆查閱手冊而耽誤寶貴的使用時間。不過,顯然這些顧慮幾乎已排除,隨便在網路上安裝個開發套件,對著圖示「拖拖拉拉」後,任何人都能寫程式 (無貶抑之意,相反地,我覺得這是很正面的事情),遇到不懂,就把關鍵字 / 錯誤訊息貼上 Google,看看能否得解。我們說,這大概就是「Google 世代的軟體開發方式」。

在談弊端之前,先提一個真實故事。最近休假 N 個月 (N 遞增中),賦閒的我很無聊地租借兩打 VCD/DVD,通常在睡前助眠之用,使用就比較隨性些 (通常是躺著看),竟然因為光碟沒放好,而讓光碟機卡住而無法取出光碟。遇到這種事情,對我這種硬體白痴來說,真是惶恐不已,該不會要賠償店家損失吧?後來想到,畢竟是一植入光碟,機器就不運轉,所以似乎只要取出光碟片,應不至於損壞。基於這個念頭,我試著將光碟機從組裝的 PC 上取出,沒想到,這竟然花費了一個多小時,為什麼?其實外殼很早就拆開了,但是光碟機一直拿不出來,無論如何施力,就是不行,在幾乎快放棄的時候,將光碟機稍微往前推移,結果就取出了,隨即以工具撬開光碟機,卡在其中的光碟片沒有損壞,慶幸。這個故事固然可笑,特別是這發生於一個國小三年級就開始玩電腦的人,沒辦法,我就是拒絕碰電腦硬體 (PC 架構),這種荒唐、烏龍事件層出不窮,舉凡插錯記憶體模組造成燒壞、連續讓兩台電腦 CRT 螢幕爆炸、接錯線讓 Power 燒壞、...,這時候就想起前女同事臉帶不解地質疑:
    「現在的電腦不是都會防呆嗎?」
是呀,的確有防呆設計,但是無法防止白痴,發生在我身上的這些故事,大概可在 Ptt BBS 笨板張貼好幾篇,光想到就覺可笑。對於有形的硬體,竟然有人會犯下這些笨錯誤,對於無形虛幻的軟體,又會犯下什麼錯誤?

小時候寫程式時,一來不熟悉原文技術手冊或文件 (會寫程式時,還看不懂英文,所以都用猜測的方式去理解),二來是對背景知識的掌握度不高,還好身邊有一些前輩可請益,所以以鴨子划水的姿態,得以培養出對程式設計的技能。並不是說小弟多會寫程式,而是說我很珍惜這等分享與解惑的過程,所以,行有餘力的話,對於網友的來信,我大多會試著回覆其中的技術問題 (基本上不收費的,若需要的話,我會事先告知,保證讓您心甘情願)。絕大部分的網友都相當客氣,我也從這這些問題中得到頗多啟發,只是,近年來,面對部份問題時,實在感覺有點心疼,摘錄描述如下:
  • 「我在 Google 已經找了一週以上,但是一直搞不懂該下什麼參數?」
  • 「到底要怎麼使用 xxx 工具?我 Google 好幾天了」
  • 「xxx 很強大,但是怎麼安裝?我好幾天沒睡,都在 Google」
這類的描述太多了,可發現 "Google" 被當作動詞來用,表示在茫茫「網海」苦苦「撈」資料的過程。人生苦短,青春怎可如此揮霍呢?這樣對待軟體,不就與我瞎弄胡搞電腦硬體的行為,如出一轍嗎?每每想到這裡,實在是不忍不去幫忙對方一把,在自己能力可及之處。究竟透過 Google「撈」資料,可得到什麼「資訊」呢?讀 mouson 的 blog 文章 [有點搞笑 - 縹緲、飄渺傻傻分不清楚],讓我們很清楚看到,其實 Google 搜尋引擎本質上只是基於「統計」,無論用什麼技術,其意涵都是一樣:讓出現頻率高者置前,這樣一來,就如同 mouson 的發現一般:
    「虛無飄渺」的 126,000 筆大勝「虛無縹渺」的 1,480 筆,所以依照大家都使用的習慣來確定,應該是虛無飄渺,但,你注意到了嗎? 沒有說您肯定不知道,在虛無縹緲這個詞中,除了縹有可能與飄混雜,渺與緲也會搞混,所以到底是虛無飄渺、虛無飄緲、虛無縹渺還是虛無縹緲呢?
顯然,「虛無縹緲」才是正確用法,但是 Google 只是一味依循網路文章以訛傳訛的作法,給予這個錯誤的答案,不得不要當心。那麼,這與本文標題的「技術手冊」有何關係呢?在有網路的地方寫程式,特別是修改某個開發完善的程式專案時,捫心自問,當我們遇到程式編譯、執行,或者相關的問題時,是不是曾將錯誤訊息、關鍵字,或者胡亂將專案名稱加上功能描述,一併丟入 Google 搜尋呢?我想,大部分人都很難抗拒這種「誘惑」,因為運氣好的時候,可以獲得一些解答,不過,往往我們只會看到其他人對此同樣的疑惑罷了。

有著「我在 Google 已經找了一週以上」的朋友,應該相當多,只是沒有提筆開口問人,一開始不想麻煩他人,最後卻賠上青春,只為了在「網海」裡頭消磨?!不,身處於二十一世紀高科技社會的我們,怎可允許這種慢性自殺呢?我沒有對此搖頭,只是,我只想勸勸這些朋友,給他們一句話:
    「對自己好一些,花一兩個小時閱讀技術手冊吧」
稍微像樣的軟體專案或套件,應該都有技術手冊可查閱,不會因為其免費取得而折損價值,我們可在 FSF/GNU 的自由軟體專案看到這點,這些高品質的軟體背後,都有上百、上千頁的技術手冊,甚至還提及其內部設計等細節。若能細心拜讀這些經歷無數琢磨與推敲的技術文件,對於技術能力的提昇,有相當大的助益,不過,往往在 Google 的搜尋結果來看,其排名卻相當低,而且相對舊版、不完整的文件還比最新、校閱多次的版本,有著更高的排名,一切都是因為「統計」本質使然,哪篇最多人看,就放前面,對資料庫設計來說很自然,但對程式設計者來說,就是一種折磨,我想,身處於「Google 世代的軟體開發方式」的我們,不免都有為了嚐點「甜頭」,而付出慘痛代價的經驗:要不 API 不合,要不軟體改版時換掉若干程式設計模式等等。

現在由程式碼去產生文件或參考手冊的系統,越來越成熟,個人相當推崇 Trolltech 的 [Qt Reference Documentation],這就是由眾多產品線的原始程式碼,透過工具去自動產生特定版本的文件,並提供有限度的搜尋、交叉參考的功能。其他像是透過 [Javadoc] 或 [Doxygen] 所產生的文件也相當不錯,圖文並茂的精美程度媲美專業的排版系統,而且這無疑是所謂的「第一手資訊」,不先去拜讀,而盲目迷失於「網海」,實在失策。儘管很多人都能理解這淺顯的道理,但不經意還是犯了錯誤,而且還一犯錯就耗了一週的時間,怎叫我們不心痛呢?

發展活躍的自由軟體專案,如 [GCC] 或 [MPlayer],每日都有大量的 patch 或 issue 被提出,我們可見到,其實這些不全是針對軟體設計本身,很多時候是所謂的 "documentation patch",也就是修正某份文件較為含糊的用詞或者不合時宜的參數與描述,訂閱開發者的郵件論壇 mailing-list,還會不時發現追求完美的開發者,為了幾個英文詞彙的使用,推敲好一段時間,為的就是讓技術手冊或文件得以精益求精、更臻完善,作為自由軟體消費者,怎好意思辜負他們的苦心呢?如果行有餘力,去指出或修正其中的錯誤,不失與社群開發模式互動的一種途徑,也不需花上太多時間,說不定還能釐清自己的誤解。

至於閱讀技術手冊,個人的建議是掌握以下要點:
  • 設計動機與核心概念:這個系統為何被提出?基於什麼想法去建構整個系統?
  • 適用對象與限制:沒有完美的軟體,只有合用的設計
  • 功能概況:不需要熟記每個章節,但需要在腦海中建構一套索引
  • 範例或樣品程式:如果時間允許,請試著驗證
這當然是老生常談,但我們常因專案進度壓迫而忽略紮實的功夫,因小失大,實在得不償失。前天讀 cait 的 blog 文章 [問問題前,請先問問自己],讓我想花點時間也寫點東西,談談對著 Google 前「發問」的一些思維,正如暢銷書《蘇菲的世界》、《紙牌的祕密》等書作者 Jostein Gaarder 的說法:
    「答案永遠是在你身後延伸的那條路,只有問題才能指引眼前的道路。」
倘若我們能更加清楚「問題」是如何被提出,也就是在閱讀技術手冊後,循著原始設計者的思維,去探討「問題」,這樣,距離答案就不遠了,這是我微薄的經驗分享,也祝所有面臨難題的程式設計師,得以左右逢源,戰勝困境。
由 jserv 發表於 April 10, 2008 12:35 PM
迴響

基礎,基礎,基礎。
基礎的確重要。

對於第一時間沒有選擇閱讀技術手冊
除了 Google 提供了資訊的容易取得外
原文資料總是沒有自己熟悉的文字親切。

或者是還沒有體會到閱讀的技巧
怎麼閱讀技術手冊?

在郝名義先生的 [1] 書中提到了很多關於閱讀的事情
什麼時候該略讀什麼時候該精讀
還有網路時代的閱讀技巧
如何將自己的疑惑與手上有的資訊丟到搜尋引擎 Google
中,透過搜尋結果與再搜尋的遞回中縮小範圍聚焦到你要的答案。

人是如何思考怎麼縮小搜尋範圍找到需要的答案 ?
或許這個個過程是使用者要學習的。
這也是善用搜尋引擎 Google 的技巧。

或許下一代的搜尋引擎不是提供一堆可能的搜尋結果讓使用者自己去過濾挑選自己需要的;而是配備了人怎麼思考的這個過程,
提供一個答案,一個使用者需要的答案。
(Machine learning?)

如果可以分享一個
從遇到一個問題到利用閱讀技術手冊或者透過 Google 找到答案的思考的細節的過程 (類似 [1] 裡面提到僅有片段訊息而搜尋到一部電影的過程) 或許會有幫助。

PS: 我就是使用 Google 時機多於直接看技術文件啊 :)

[1] http://www.books.com.tw/exep/prod/booksfile.php?item=0010365206

suglwu 發表於 April 10, 2008 02:06 PM

我的心得
真的要好好讀說明書就行了
光碟機說明書有寫,請把迴紋針插入退片孔
就可以拿出光碟了 XD

SJH 發表於 April 10, 2008 02:40 PM

To SJH:
一般情形下是這樣沒錯,但如果光碟片是別人的(或租來的),這樣做仍有風險。

用此法取出的光碟有可能碎裂(我本人親眼目睹過兩次,另外同事也有切身經驗)

jserv 用的方法成本雖高,卻安全許多。

guest 發表於 April 10, 2008 05:35 PM

SJH說「把迴紋針插入退片孔,就可以拿出光碟了」若光碟機有設計退片小孔,而且插入後能退出,是不會有碎裂危機的。不知道 guest 說拆機「安全許多」的根據何在?

不過下次可以試試「拔電源」再插回,這招對好幾個廠牌的DVD Player都有效。

言歸正傳,還是謝謝 Jserv 很棒的分享!

Allen 發表於 April 10, 2008 10:29 PM

那張圖真是讓我笑了XD

燒賣 發表於 April 10, 2008 11:18 PM

拜讀了 感謝 Jserv 大的指點呀

aguai 發表於 April 11, 2008 06:15 AM

小孔管用的。google有時卻是很強大,但有時也會讓你吐血至死,苦苦google,掉進鏈接的無底洞,答案就是不出來哈哈

td 發表於 April 12, 2008 12:13 AM

到现在我还无法正确的使用google解决技术上的问题, 大多数的情况还是看手册, 看code解决.

Drip-shui 發表於 September 22, 2008 11:34 AM

磨刀不誤砍柴功。

不過,縹緲、飄渺應該都可以,本來就是聯綿詞,有多種寫法。

weakish 發表於 August 12, 2009 09:38 PM
發表迴響









記住我的資訊?