顯示具有 書籍閱讀及推薦 標籤的文章。 顯示所有文章
顯示具有 書籍閱讀及推薦 標籤的文章。 顯示所有文章

2009年6月2日 星期二

兩本Android的書閱讀心得

因為我的英文不太好,在去學習一項技術的時候
我總是習慣先去找本中文的書來看,有點基本概念後再去翻原文的說明文件
這邊想分享一下兩本關於Android的書後心得


第一本是旗標的Google Android 程式設計與應用
這本書是以Android 1.1版舉例,雖然現在是1.5版,除了安裝那章節之外到還能用。
當中是拿Google官網的NotePad等範例來說明,要說感想的話大概就是『夠廣不夠深』,裡面探討了很多方面的話題像是3D影像、Vedio播放等等,但是都是蜻蜓點水式的帶過而已,所以個人認為想拿這本來入門並不適合,很多地方都沒有說明清楚,要做為深入研究這本又力道不足,拿來當課外讀物看看Android有哪些東西到是不錯。






第二本是文魁的『Google!Android 手機應用程式設計入門』(名子都好像),這本拿來入門就很不錯了,很多細節都講得很清楚,觀念也都有釐清,只可惜探討範圍不夠廣,整本書扣掉Google Map的部分總共也才兩種程式範例,但是觀念部分都有提到,包括Android程式的生命週期流程、函式運作的細節等等,他用很簡單的例子去作舉例,閱讀起來很容易也不容易遇到障礙。
跟上一本比起來個人比較推薦這本。







最後,如果還想要有Android更深入的知識、建議還是直接看他的Dev Guide查Reference
http://developer.android.com/guide/index.html
很多範例都可以從裡面找到,以說明文件而言真的是非常豐富

題外話
其實各家官方文件都非常有閱讀的價值,我看過不少官方說明手冊像是微軟的MSDN、IBM、Flash Actionscript等等,裡面唯一算爛的大概只有台灣微軟的MSDN,我曾經用C#+DirectX寫過一些東西,很多進階的說明台灣微軟的MSDN都是一片空白不然就是直接連回英文版MSDN
幸好個人日文還不錯,不少問題在日本微軟的MSDN都找的到解決方法跟說明,真的是好的說明手冊讓人上天堂,不好的說明手冊讓人爆肝傷

2009年5月13日 星期三

Practical Java Programming Language Guide 一書讀後小感級推薦

之前翻實驗室書櫃的時候,挖到了不少寶物,以前的學長留下了不少好書
包括理財跟軟體相關,甚至連一些已經絕版的書都有,為了不浪費以前學長的美意
我把裡面的書全部挖出來研讀了一番,我把最近看完的幾本書的心得PO上分享
也對喜歡寫程式的人做個推薦,好書就該廣為流傳



『Practical Java Programming Language Guide 』一書介紹了不少寫Java該注意的事項
雖然有去念Java聖經書的應該都知道了裡面不少觀念,但是他將這些觀念整合起來,閱讀起來方便不少,由於他是比較進階的書籍,有java的background再來閱讀此書會比較好

書裡面很多都是基本概念,但是也有很多人平常不會注意的小細節他都點出來了
我把我覺得重要還不錯的部分弄成文章PO出來,詳細的內容還是須要請有興趣的人自己翻閱
才更能體會書中的奧妙,也請喜歡java的同好務必閱讀此書

裡面分成了六大章節



  1. 一般技術(General Techniques)

  2. 物件與相等性(Objects and Equality)

  3. 異常處裡(Exception Handle)

  4. 效率(Performance)

  5. 多緒(Multithreading)

  6. 類別與介面(Classes and Interfaces)


其中第四章Performance的部分個人認為很有價值,他分析了很多Java各種語法對效率上的影響
我整理了一些文章,有興趣的可以看看

2009年5月8日 星期五

重構-向範式前進一書讀後心得

前一陣子把這本看完後,原本打算寫這篇心得文(好像是變相推薦文)

但是因為事情比較忙,拖到今天才打出這篇



我在看完『重構-改善既有程式設計』之後,覺得意猶未盡,去找了很多相關的書籍

之後找到了他的延伸閱讀『重構-向範式前進』



裡面講解如何使用Refactoring去將現有的程式不止改善,更讓他成為Design Petterns

這裡真的很佩服作者 JOSHUA KERIEVSKY,他提出了那麼多重構的手法

有些雖然是平常我們就有再用,但是JOSHUA KERIEVSKY更給這些重構方法一個明確的定義步驟

有人說Design Petterns過於好高騖遠,因此對他抱持疑問,但是閱讀完這本書之後給了我一記強心針,設計是可以持續進行的

這點在我閱讀完極限軟體製程(Extreme Programming)後更是確信不疑(這系列出了很多書)
利用持續重構跟測試,一個程式碼終究可以被整骨成設計模式

『重構-改善既有程式設計』在基峯的閱讀指引是入門-專家,而『重構-向範式前進』則是進階-專家,代表著沒有相當backgroung最好不要從這本開始看

『重構-向範式前進』是『重構-改善既有程式設計』的延伸閱讀,所以最好看過這本書跟四人幫的Design Patterns 才有辦法對裡面的內容理解貫通

這本書提到了很多概念包括過度設計還是設計不足,提倡用持續重構的方式改善程式碼設計(這不就是XP的精神嗎)

因為人們很容易入Patterns Happy而無法自拔,而多做了過多的設計

我真的覺得這本書算是變相的XP宣傳,因為沒有持續重構跟測試,就沒辦法refactoring to patterns

裡面只提出了『重構-改善既有程式設計』的其中的12個程式碼的壞味道,以及27個重構手法,而很多重構技術如果是『重構-改善既有程式設計』裡面有的他就只會提是該書的哪一頁(所以看這本書的時候『重構-改善既有程式設計』要隨身攜帶比較好)

裡面重構的部分分成幾個章節

  1. 創建(Creation)

  2. 簡化(Simplification)

  3. 一般化(Generalization)

  4. 保護(Protection)

  5. 積累(Accumulation)


每節各有幾個不同的重構手法,主要分成三大手段:成為(To)、接近(Towards)、遠離(Away)

當程式碼設計不足的時候就讓他成為或者接近一個Patterns,當程式碼過度設計的時候就讓他遠離Patterns

除了這些之外,前面還講解了一些實例跟如何說服你的老闆接受你去重構等等

總合而言這本書是上選,個人還蠻推薦的,不過最好是已經看過重構跟設計模式相關書籍在來閱讀此書會比較好


有機會我來把這本重構法整理成文章PO上來跟大家分享,畢竟好的技術就應該廣為流傳

謎之音:你前面還有一本設計模式的文章要PO

2009年4月25日 星期六

重構一書閱讀小感

花了一個禮拜看完碁峯『重構-改善既有程式設計』

重構的定義:Refatoring:a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior of the software.

主要就是在說再不改變程式外在行為的前提下,修改軟體內部結構讓程式碼更容易使人了解閱讀

因為想要增進一些寫程式的技巧,最近一直在看這類的書

由於這本是我看的有關重構的第一本書,也很難說他好還是不好

我本身算是碁峯出版的信者,相關書籍我原先都會先考慮碁峯出的書

雖然作者會影響書的內容,但我覺得出版社的風格也會有相當的影響

不過碁峯最近幾本書個人認為實在編寫不太好,像『Visual C# 2008 程式設計經典』這本

反而沒有他前面幾本寫的好

『重構-改善既有程式設計』是比較舊的書了,市面上有關重構的書其實不多,真要看的話還必須找中國那邊出的或原文本
這本『重構-改善既有程式設計』個人認為寫的算中規中矩,對於沒有UML跟物件導向基礎的人來說會讀的相對吃力

裡面總結了程式碼的22個壞味道82個重構方法,內容還蠻多的,講解方面稍嫌生澀,並非那麼容易閱讀

裡面有句話我印像蠻深的

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.



大意就是說任何人都可以寫出電腦看得懂(可以Run)的程式,但唯有寫出『人』可以輕易看懂的程式,才是好的程式設計師。

這點實在讓我感同身受,至今我也看過也改過不少程式碼,想要把程式碼寫的讓人一看就懂實在不是件容易的事情。

為了那一點cpu cycle而將程式碼寫的非常難看,短期之內效能上可以非常好看

但是長期之下程式的維護成本將遠高過那一點點效能帶來的好處

一個程式主要的overhead集中在10%的不良演算法,除非有即時性(real-time)的考量

實在不該為了那一點點效能而讓整個程式發霉,整個軟體專案,Debug的時間常常是實際寫程式的好幾倍

還記得我之前寫過一個遊戲專案,技術的學習跟程式設計假設花了半個月,那我花在Debug的時間就是兩個月

這不成比例的時間配置就是沒有好好整理程式的下場,而且好的程式碼要最佳化也比較容易,他擁有更多可最佳化的的程式

真的要好好維護程式碼架構才真的是一個程式設計師該有的基本能力阿

2009年4月13日 星期一

設計模式-(序) 是設計更是藝術

序言


最近在研讀設計模式(Design Pattern),至從看了有關這類的書
再回頭看看我以前寫的程式,只能用不堪回首來形容
我覺得設計模式是每個物件導向程式設計師都該看的
在眾多設計模式的書籍當中,個人推薦這本:大話設計模式 出版(代裡)社:悅知


這本是之前去紀伊國屋看到的,由於紀伊國屋的東西都貴到昏倒
所以買這本的時候我很猶豫,加上我對悅知出品的印象都是:夠廣不夠深
就是悅知有關資訊的書籍都是探討範圍很廣,但是不夠深入(我是讀書狂,所以對出版社風格會有刻板映像)
但是這本推翻了我以往的想法,這本大話設計模式用對話跟日常生活例子為對象來延伸到設計模式,除了探討內容夠之外,容易閱讀是特點,這本大話設計模式我花了數個小時就閱讀完畢,而且也吸收豐富,相較於之前培生出版社那本,這本真是好物。

回到正題,就算不懂設計模式,程式寫多了也多多少少會用到類似的概念
Java或是.NET等都用到不少相關的設計模式,有拜讀過那些core的原始碼的話,一開始會像看天書一樣,有看沒有懂,但是了解其中的設計模式後,會發覺他是那麼的美麗。

設計模式:是設計更是藝術



一個設計好的程式,就像是美麗的女人般讓人百看不厭,以前從未注意過程式可以這樣散發如寶石般的光輝,想想之前我class隨便亂用,幾乎一個函式幾百行那種程式,真的只能用垃圾來形容。
程式寫多了,之後就只是語法上的問題,我甚至斷言照著書作人人都可以寫出一個系統。
尤記得我大學時候一位同學,他們的專題是作進銷存系統,雖然他們都不太會寫程式,但是靠著微軟VS2005的強大到也讓他們做出有模有樣的東西,但是一旦放上戰場,缺點立刻出來,根本就不堪用。
再舉一個比較近的例子,微軟最近在徵招實習生(未來生涯體驗),他們的主題網頁外觀華麗,但是根本經不起考驗,我因為也想報名,所以有去看他們的網頁,一開始我還讚嘆外觀設計的真漂亮,一旦報名按下去,缺點立刻浮現,也就是他們的網頁firefox不支援某些動作,逼得我一定要用IE去跑這是敗點一:瀏覽器的相容性沒做好。
再來就是註冊時明明沒叫我填身分證,登入時卻要填身分證(啥鬼),然後我身份證填好後不給我登入,造成我原本二月多要報名托到三月中,而且我可以登入還是因為我發現身分證少填就可以登入,敗點二:程式邏輯沒設計好,驗證也做不完全。

其他零零總總的缺點,所以說程式人人會寫,有些套裝軟體甚至拉一拉就寫好一套系統(VS之類的),但是是不是經得起考驗的系統才是我們資訊人員的優勢所在,不然套件拉一拉程式就寫好了,工程師還有飯吃嗎?

記得當初上一堂課,助教要抓有沒有抄襲,他就把程式碼瀏覽過一遍之後,就抓出了誰抄誰,他說了一句話:"程式是個藝術,每個人風格皆不同,只要看了程式碼架構,大概就能猜出是誰寫的"
這句話在我碰觸過設計模式之後更是非常認同,程式如果沒設計好,寫出來的只是把螺絲起子,轉過螺絲後就毫無價值,但是設計好的程式就像把萬用刀,什麼事情都可以用,栓了螺絲還能用他做其他事情。

但是設計模式會造成程式效能的降低(function call增加),如何在這之間做取捨,就是程式設計師的功力了。
用我喜歡的RPG來舉兩個極端的例子,一支效能到極限但是沒有設計過的程式就像是萬靈藥,可以解除所有異常狀態(問題),但是用過一次就消失不能再用了。
而一個設計到毫無破綻,但是效能普普的程式,就像是僧侶,可以作到萬靈藥的作用但是一次只能做一件(解毒、治療、增加力量etc),而且還要考慮僧侶有沒有MP(現在的問題適不適合),但是僧侶沒有使用上的限制,只要有MP(設計模組正好能解決問題),就能一再使用。

說了那麼多,主要是在說程式是否能夠Reuse,一隻好的程式除了效能好之外,他還必須能夠重複使用來增加他的生命週期,如此一來才能說他是個有設計的程式。

copy不等於reuse


很多人都學過物件導向程式目標就是寫出內聚力強、耦合力弱的程式,但是會真正去實踐他的人卻不多,我認識許多人都有錯誤的概念,認為寫程式寫到後面就是copy&paste,這種是最要不得的概念,就因為程式沒設計好才會用複製貼上取代程式碼的覆用,當copy&paste用多了的時候,哪天要改就會花費非常大的成本,假如這隻程式用在一百個地方,就要改一百次(老闆會寧用fire這種人請另一個高明的來重構),這時候其實可以考慮用提煉函式的方法解決,但這是重構(Refactor)的部分了,在此不贅言。



接下來我打算花幾個篇幅連講解設計模式的基本23個pattern,希望我能完成