K氏讀書雜感——Java (轉)
[宣告]:本文由kingofark創作。本文中的所有內容僅代表kingofark個人的觀點,與任何其他個人或團體無關。任何人或團體都可以複製、傳播本文,但需附上完整的本宣告。kingofark對於不同意上述各點或不履行上述各要求的人或團體的言行不負任何責任。特此宣告。:namespace prefix = o ns = "urn:schemas--com::office" />
K氏讀書雜感——
[kingofark的話]:是的,五評計劃寫不下去了……因為來不及看那麼多書…… :-p 所以就退化成了有時間便隨便說說罷。猛然間非常無厘頭的想到“××營養米粉”,所以將文章謂之“K氏讀書雜感”。
“推薦度”顯示了kingofark個人對書的看法,範圍在0到10之間,10即是指kingofark覺得極好(雖然並非就肯定時完美),0指的什麼就不用累述了(雖然並非就肯定是渣滓)。“推薦度”免不了會帶有個人偏執情緒,所以請您不要大以為然。
[一]:《Java思想 第2版》影印版,Bruce Eckel著,機械工業出版社
[推薦度]:10
[推薦理由]:
《Thinking In Java》這樣的書,Bruce Eckel這個人,似乎沒有必要介紹了。機械工業出版社的經典原版書庫是筆者最為期待的圖書系列之一,《Java程式設計思想 第2版》影印版自然是我必買的書籍。有側重點的通讀之後,給我印象深的大約有三……噢,不,是四處:inner classes、、JNI以及書的裝幀質量。
其一:作者用了近30頁介紹了(唔,這還能算是介紹嗎?)inner classes,其之各種用法與變形被全全展現了出來。
其二:龐大的swing被挑出最重點的若干個介紹出來,感覺非常清晰,全沒有檢視 documentation時候的龐雜感。
其三:對JNI的介紹簡短精悍、非常有用。如果你有興趣檢視j2sdk的話(比如collections),會發現一到“敏感”的地方,就使用了JNI。對於一個學習Java的人來說,JNI是一個未必常用但必須知曉的技術。筆者曾饒有興趣的在j2sdk原始碼中翻了翻,看看哪些地方用了JNI。
其四:透過閱讀這本書,筆者更加透徹的理解了“熵” 的原理,堅定了“The Truth Is Out There”的信念。被平平攤開在桌子上(注意,沒有對其施加任何壓力,只是讓其自然攤開——當時筆者在看第471頁)的這本《Java程式設計思想 第2版》影印版,首先在24小時之內自行進化成為“0-470頁”和“471-末頁”上下兩冊;筆者試圖對其進行粘和,可是其在粘和後1小時之內繼續分冊,分冊數呈線性增長趨勢;就此以後,企圖粘和這些實體的任何試驗均以失敗告終。所以kingofark的結論是“你觀察它,它就變複雜了”(這也算X檔案吧!?莫特探員救我!)。
該書的練習中,時常會看到作者提出諸如prove這樣的要求。筆者認為,作為練習的解答者和初學者,不僅要show,還要prove,所以除了編出程式碼顯示出執行結果,不妨由此自己多做些引申。你不僅可以用javap檢視被disemble出來的code,還可以用java –verbose檢視詳細的執行情況,也可以用j細細瞭解執行的實時狀況。心裡很有底的prove,正說明了你對java背後機制的掌握——這不是開始深入進去了嗎?
另外,筆者感覺該書中的許多範例都是相當好的,非常值得細細體會和把握。
……哦,英文不行?那就讓我們一起期待侯捷先生譯的《Thinking In Java 2/e中文版》吧J
[二]:《Java高效程式設計指南》,Joshua Bloch 著,聞山 等譯,機械工業出版社
[推薦度]:0
[推薦理由]:
譯文行文不流暢(但絕非國內最差,甚至都算“還可以”),許多句子雖然說並不是完全不能理解,但卻要耗費些許時間去分析和猜測句子結構——就國語水平從小學就很差的筆者而言,還不如直接看原版英文來得快。
譯文中出現的翻譯謬誤不能說不嚴重,僅就目錄中的標題而言:
“Item24:Make defensive copies when needed”(kingofark譯:在需要的時候實施保護性複製)
被譯為:
“6.2 使用保護性複製”
“Item32:Avoid strings where other types are more appropriate”(kingofark譯:當使用其它型別更為恰當的時候,就避免使用strings)
被譯為:
“7.4 儘量避免使用串”
原作者Joshua Bloch特別在前言裡面提到,該書按照《Effective C++》格式給出一條條原則,其原版英文書也確實是這麼做的,使用了“Item: …”的方式在標題中給出了這些原則。
大家看出在簡體中譯本里面的問題了嗎?
假如有一本《kingofark高效生活指南》,裡面提到
“Don’t wee-wee in public(不要在公共場合當眾撒尿)”,
譯為“不要撒尿”
可不可以呢?
如果有人憋尿得了尿毒症,豈不是要找kingofark扯皮?
如果有人教你“不要撒尿”,你聽不聽呢?……反正kingofark是不敢聽信的。
如果有一本教你“不要撒尿”的生活指南,你看不看呢?……反正kingofark是不敢看的。
高效?搞笑?!指南?災難?!
最後想告訴那些願意看書的人:筆者透過在上搜尋,到了該書原文的第3、5、6、7章pdf——還是蠻多的嘛J
[三]:《Java程式實用手冊 第二版》,Will David Mitchell 著,裘嵐 譯,電子工業出版社
[推薦度]:9
[推薦理由]:
那天,筆者剛剛在書店看到本書的第一版,想來想去還是決定買一本,萬沒想到下次來買的時候,標明“第二版”的書都出來了——奇怪的是,從該書的說明頁(就是宣告版權、標價的那一頁)看來,仍然是原版第一版。
筆者沒有通讀該書,但感覺全文風趣輕鬆、譯文較為流暢(有些地方比較不順),行文敘事之中體現出作者豐富的和獨到的見解——這是一個好徵兆。在技術層面上,筆者也還沒有找到什麼“馬腳”。該書的內容可謂豐富:的發現、防止與清除,deger的使用、測試、錯誤資訊,以及豐富有用的附錄。光從涉及的內容來看,筆者認為這正是一本java程式設計師應該學習的東西。
令筆者印象深刻的是第7章“心理訓練”、第12章12.6節“錯誤資訊的內容”、附錄C“程式設計的24條法規”,以及附錄E“宏”。
[第7章“心理訓練”]
正文簡單的談到寫註釋、起名稱以及個別獨立的問題(7.2 不要混合使用深度搜尋和廣度搜尋),讓人覺得題不符實。倒是7.4節“環境”著實讓筆者忍俊不禁。7.4節中,作者指出“除錯時所處的環境非常重要”,給出了9條“幫助你改善身邊的環境”的意見:
(第4條)“關閉計算機螢幕上的電子提示。……”
(第5條)“如果接受一封巨大的電子郵件,請別人替你完成這件事”
(第7條)“找一個可以上升和降至一半的旗杆及一面旗幟,在旗幟上寫下:‘降半旗時請不要打擾我。’人們會尊重你的決定。”
這些似乎有些偏執、自私甚至搞笑的意見,乍看上去,或許只得你一笑一惡;然而筆者認為,作者很形象的說明了“自己營造好的工作環境”的重要性,
於國內,這些條目大有借鑑學習之處——觀之國內情勢,全天工作開啟qq與無關人員者,大有人在;心浮氣燥,整天收信者,大有人在。其實說來說去,還是那句話,好的習慣和端正的態度重於一切——要不然怎麼總是那麼多“IT皮包公司”慘淡經營?
[第12章12.6節 錯誤資訊的內容]
12.6.1 發生了什麼事?
12.6.2 為什麼發生
12.6.3 其後將發生什麼現象?
12.6.4 現在可做什麼?
12.6.5 將來使用者能做什麼?
12.6.6 現在使用者從何處可以得到幫助?
12.6.7 使用者如何才能幫助開發人員改善情況?
12.6.8 最近在使用者的中發生過類似問題否?
12.6.9 使用者應該如何向技術人員描述問題?
12.6.10 聊天室和幫助室
12.6.11 人員將為使用者提供什麼補償?
12.6.1至12.6.11詳細敘述瞭如何處理面向使用者的錯誤資訊,並在12.6.9的12.6.9.1“為什麼不使用FAQ?”中獨到的提出:
“(為什麼不使用FAQ系統?)除了FAQ系統可能使使用者感到乏味和不值得這一事實之外,看起來只有半數機會可以找到答案。多數使用者都希望向某個談論問題,原因只有一個,因為這才是討論。”——不管同不同意作者的觀點,筆者都不得不佩服作者對待作為產品的軟體細緻入微的考慮(作者在12.6.9.2中給出了很有啟發性的建議)。
軟體作為一個產品,其服務是全方位的,你需要為使用者考慮周到,這是天經地義的。想到國內,筆者又想發牢騷:人家老外總是做得特好——我們讚歎啦、不服氣啦、不以為然啦、瞧不起啦……其實這有什麼呢?要我說人家就四個字:認真負責。我們有嗎?
12.6.12 至12.6.18 講述了開發者遇到錯誤報告時,在技術方面的應對措施。
12.6.19 “螢幕或者報告中應該顯示什麼內容”一節精煉的給出:
“訊息應該回答使用者的如下問題:
l 發生了什麼?……(略)
l 接下來發生什麼?……(略)”
[附錄C“計算機程式設計的24條法規”]
這24條或許算不上什麼經典之作,有些也是大家熟悉的條款。筆者認為這樣的條目多多益善,列印出來貼一張在顯眼的地方,絕對不會沒有好處。
[附錄E“Word宏”]
這一章給出了Word宏程式碼,“可以將一個普通的字處理程式變為一個不錯的Java編輯器。”或許現在缺乏Java編輯器的人不在多數,但這倒是一個使用宏的上佳示例,還是非常有價值的(尤其你可以藉此向朋友展示你這個“搞的人”是如何“神奇的”使用WordJ)。書中給出了關於處理書籤和跳轉、隱藏的文字、個人註釋、綠色的關鍵字、程式設計幫助的宏,並提供了可以得到更多宏的網址。
推薦度9,筆者未看到更多同型別的書。這本書並不完美,但顯得重要、必要。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752043/viewspace-992056/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Java遊戲程式設計讀書筆記(轉)Java遊戲程式設計筆記
- 閱讀圖靈iOS開發相關書籍讀後感圖靈iOS
- 聶微東:《暗時間》讀書筆記與讀後感筆記
- 學習雜感--寫給大學的同學們 (轉)
- Effective Java 讀書筆記Java筆記
- 讀書筆記:RUP (轉)筆記
- (轉)龐氏騙局 Ponzi SchemeScheme
- 薦書派 | 遊戲開發者尋求靈感時必讀這六本書遊戲開發
- 讀後感
- java讀書筆記---垃圾回收Java筆記
- Effective Java 讀書筆記(2)Java筆記
- TIJ讀書筆記(二) (轉)筆記
- TIJ讀書筆記(一) (轉)筆記
- iPhoneWebApp開發雜感iPhoneWebAPP
- Java併發程式設計實戰——讀後感Java程式設計
- 程式設計師必讀的書籍和期刊雜誌程式設計師
- 《Head First Android》讀後感,電子書PDF下載Android
- 海氏工作評價系統(轉載)
- 讀書筆記-----Java中的引用筆記Java
- Effective Java讀書筆記(目錄)Java筆記
- head first java讀書筆記Java筆記
- 讀後感1
- 讀後感2
- 讀後感3
- 學Java,Java書籍的最佳閱讀順序Java
- 讀書軟體做自己的 (轉)
- 《阿里巴巴 Java開發手冊》讀後感阿里Java
- 黑客馬拉松之外的雜感黑客
- 一些雜感雜想(一)談談加班、團隊
- Java複雜資料型別用法 (轉)Java資料型別
- Java PDF書籤——新增、編輯、刪除、讀取書籤Java
- 《SVG 精髓》讀後感SVG
- 《精通 Django》 讀後感Django
- 讀後感---程式猿.
- 感覺 《JAVA 與模式》 一書中的描述似乎有錯誤Java模式
- 楊氏矩陣:查詢x是否在矩陣中,第K大數矩陣
- 讀Cookie安全後的讀後感Cookie
- 程式設計師職業規劃之道讀後感 by khotyn(豆瓣書評)程式設計師