平常在學校老是裝Java之神招搖撞騙

別說你忘了他

「這段程式在寫什麼？」

「我忘了，要Trace一下看看...」

這段故事有沒有很熟悉？
上一次出現這台詞的時候，你是問的人還是答的人？
還是自問自答？

人類本來就很健忘，所以應該無時無刻留下提醒自己的紀錄
文字也好，uml也好，註解也好，便利貼也好，
總比看一行行的神秘符號來的好

剛開始工作時，我也沒寫註解的習慣，
仗勢自己的小聰明，只管Code能Run就好，管他啥註解跟文件的
不過久了後，覺得老是自己在整自己，昨日之我永遠比今天之我還聰明

試著寫一點註解以後，才發現這樣以後看起Code來快多了
我才了解到，與其浪費生命在Trace火星文，到不如多花時間留下點記憶

有些人會說，註解/文件寫的濫的要死，有跟沒有還不是一樣
不過我覺得這是做與不做的問題，而不是好跟不好的問題
註解/文件寫的好是一種藝術，那需要很多的經驗跟天份
但是，有或沒有是一種態度，程式人該有的責任

為自己的程式負責，能動的不代表完成

SCJP5.0猛虎出閘

「看，SCJP」我好友拿出張卡片

「嗯嗯．．」

「Java的國際證照，酷吧，跟你說$#@!!!$5.... 」他滔滔不絕的講著

「嗯嗯．．」.....有個愛炫燿的朋友真受不了

於是受個刺激(誘惑?)的我也買本書去考

考試買這本書到底有沒有用：

有

讀書心得：

• １到４章為基本語法－感覺還都能了解，只是很多小地方沒注意到，特別是三章物件導向，我才知道所謂的"物件"原來是這樣用
• ５章執行緒－如同惡夢般的mutilthread被講的很簡單
• ６章資源回收－讓用不到的物件早點超生
• ７章集合與泛形－看完後有恍然大悟的感覺，發現自己的程式能少用點陣列，有更適合的資料結構
• ８章ＩＯ－我後來才知道，看起來很複雜，其實一切都是DecatorPattern
• ９章其他－雖然考試不考，但是實際中很常用到，也很常遇到
• 模擬考題－想考高分就多做吧

結論：

看完後第一個感想：「XX娘的，原來我這麼不懂Java」

算是帶我重新認識Java的一本好書，從此以後我也對物件導向有比較深的了解
也是算開始"覺悟"到要擺脫結構化程式語言的開始

炫燿一下XD：

我是2007年8月考的，87分，但是說實在不重要就是 ~3~;

ＳＱＬ之美學

「ＳＱＬ不就是ＳＱＬ？哪來什麼美學」我看到本書的第一個想法

不過聳動的標題，還是促使我從架子拿下來翻幾頁，

「喔喔！？我好像遇過這件事？」

「原來學校教的離散數學跟檔案結構不是在騙我！？」

於是我把它買回家

本書內容：

ＳＱＬ的理論，但是是對於實作極度重要的理論
實作以戰爭比喻，而理論部分以兵法比喻
很多內容，會提出某SQL指令或Table設計，為何資料庫會這麼做，它到底在想些什麼，進而產生對應的效率問題

讀了多少：

全精讀完，讀懂約七成

重點心得：

1. 正規化的重要性，與Null的潛藏危險：『以正合，以奇勝』，正規化跟非Null是「正」，反正規化跟允許Null是「奇」，問題是何時該反正規化，而不是為何要正規化，正規化跟非Null是必備
2. 索引是雙面刃，在特定條件下會增加Select效率，但是一定會降低Insert效率
3. SQL的本質是集合理論，跟資料庫核心接近程度為資料＞關聯式(如join,union,group by)＞非關聯式(如 order by, case when )，Query指令越接近核心速度越快，所以當有複雜的查詢時，關聯度高子查詢要先放在內層
4. 最佳化處理器(SQL Optimizer)，跟前三點有正相關，跟理論背離的Query指令會無法達成最佳化，甚至有時候會搞砸更多事
5. 鎖定(Lock)是為了保持資料同步下正確，但是ＳＱＬ通常是處理＂整批＂資料；所以換句話說，反正規化，條件限制少的Query指令，或牽涉超出集合理論能做的部分，為了保持資料正確性，SQL會加大鎖定範圍
6. 效率跟前面有前五點必然相關，通常不佳的效率來自於反覆執行的小型指令
7. 階層式(hierarchy)結構或樹狀結構不適合關聯式資料庫，可以的話盡量用程式解
8. SQL結構彈性取決於與真實世界符合程度，而非過度動態的表格或高深莫測的語法

結論：

其實這本書不像封面看起來的無趣，只是有些地方必須要先學過相關的數學或電腦知識，在配上相關實務經驗，才會有豁然開朗的感覺

操作介面設計模式

「我忘記我選到什麼了？」

「我找不到確定鍵在那！」

「為什麼點這個沒反應？」

「這顏色好亂，我看的眼睛好累」

很多人都遇過，使用者抱怨介面太花，配置很亂，操作不夠Friendly
但如果遇到一個讀資工的宅男，要求介面簡直是緣木求魚，或者我該說雪上加霜？ XD

工作以後，我就一直被介面問題煩惱
也找過幾本書，但都只是只會其型，不知其意

直到我拿到這本為止

本書內容：

介面設計的型錄，多半以人的角度思考，並講解其原理

人類到底看見了什麼，人類到底想做些什麼

我看了多少：

全讀完，基本上不太可能看不懂，只是有沒有練熟的問題

重點心得：

1. 使用者做什麼：使用者為什麼要用這個程式，會做何種程度的嘗試，利用基本原則引導使用者熟練系統，因為文件沒人會去看
2. 組織內容：空間的規劃，不同類型的資料，在人類心中有各自適合的心智模型，再對應到介面上擺放方式
3. 到處走走：路徑的規劃，一步步走向正確的地方，不能讓使用者迷路，好的路標不是強迫到正確的位置，而是指出使用者前進的方向
4. 組織規畫：頁面的配置，視覺流的影響，物件型態(這裡指的是視覺外觀)的所造成的關聯性，應該有系統的分門別類，而不是雜亂無章，看網頁或視窗時，人不會照順序看，而是憑感覺
5. 做
   事：如何讓[按鈕]/[選單]/[連結]看起來是能用的，讓不同的元件負擔起不同責任，例如下拉式選單(DropDownList)負責"選擇"，按鈕
   (Button)負責"執行"，拖放(Darg-and-Drop)負責"移動"等等，還有得注意文字盒(TextBox)的使用，這東西通常很難用
6. 資訊圖形：千言萬語不如一張好圖，圖形的力量比想像中的還可怕，把形狀放大或是顏色改辦一下，對看的人而言就意義完全不同，利用大小顏色聚焦資訊，不重要不代表不需要

結論：

其實嚴格來說，這應該算是心理學家跟藝術家的事，而且是很抽象的東西，我們搞技術的人大部分都不擅長這些，但程式畢竟是要給人用的，既然如此，那我們就看些簡單的基本原理，然後用抄的就好，本書不但提共抄襲的好材料，又沒有困難的理論，值得一讀

深入淺出設計模式(Head First Design Pattern)

「什麼是Design Pattern？」同學問

「不知道ㄟ，教授沒教過，應該不重要．．．吧？」我回答

「很重要吧」

「沒差拉，考試又不考，Case Study啦～～」

那時的我，大學三年級

=============ｎ年後===============

「連Factory Pattern跟Observer Pattern都不會？」我歇斯底里的怒吼

「咦？這些是什麼東西？」學弟滿臉疑惑說道

「就是說$!@#%$~~~~~，瞭了嗎？」

「....？」

「....orz」我放棄了

但其實回過神來仔細想想，跟當年的我不也是這樣嗎

所以說，Design Pattern到底是什麼？

Ｗｉｋｉ說：是對軟體設計中普遍存在（反覆出現）的各種問題，所提出的解決方案
本書說：是種可再利用的經驗與智慧
良葛格說：是在解決問題的過程中，一些良好思路的經驗集成
我說：是經過無數血與淚所堆砌出的智慧結晶

在物件導向語言(C++,Java,C#.Net,VB.Net)中
它已經是個隨處可見的真理

我讀了多少：

次數多到不清，不過會用才是真的會

重點心得：

1. Obersver(觀察者)：愛稱為電台模式，通常是為解決一個Model對應到多個View之間的互動，寫Swing常用到 －－『甲愛貢，那Ａ謀企電台貢厚全台灣聽』
2. Decorator(裝飾者)：又稱之為裝甲模式，通常我用都會包太多層並難以理解，不過卻相當程度能動態調整　－－『你妝會不會化太濃了』
3. Factory(工廠)：我第一個用的Pattern，是拿來解決，不同資料來源搭配到同一個介面上的問題　－－『又到了開分公司的時候了』
4. Singleton(獨體)：個人覺得是最簡單也最困難的一個，我只拿來做紀錄Log到檔案用過
5. Command(命令)：愛稱遙控器模式，我常拿來做權限部分，拿來分離登入物件及功能 －－『不要亂拿遙控器，很危險的』
6. Adapter(轉接)，據說能解決銜接舊系統的問題，沒用過
7. Facade(表象)，愛稱幻覺，整理一駝亂的好幫手，趕時間或感覺Class拆太多的時候不錯 －－『雖然一切都是幻覺，但是真的嚇到我了』
8. Template(樣板)，整理很相似的Code時候用的，我不太常用
9. Iterator(反覆)，有效做重複的事，看到很多for - if - for -if 能考慮用這個，看起來沒什麼了不起，但常常意外的有效果 －－『下一位，下一位，下一位』
10. Composite(合成) ，樹狀結構跟XML的好朋友，在複雜的加總或計算中算好用 ，尤其是用for loop或SQL指令會做很亂的那種 －－『無.敵.合.體.』
11. State(狀態)，通常改變狀態代表邏輯行為也要改變，這個Pattern能讓人先專注在狀態變化，而不是行為 －－『Oh！It is another Final State Ｍachine！』
12. Proxy(代理人)，也是個看起來簡單但變化很多的Pattern，不是很常用
13. Model -View -Control (MVC) ，每個寫過網頁的都號稱會用MVC，但其實MVC沒這麼簡單，有時候把Code要放在 Model or View or Control 不是非常直覺的事，我很懷疑都沒人有這種煩惱嗎？

結論：

Design Pattern不是萬能的，但是看不懂可是萬萬不能，使用的太普遍了

生平不識模式趣，寫盡程式也枉然

推薦本書：

Design Pattern 一直被當作很難或很高深的理論(起碼對我而言)，但是Head First系列的變態作者，加上大師級的翻譯，就是有辦法寫到連我這笨蛋都看的懂，還帶我看到不一樣的世界，我衷心佩服且感恩
不管懂不懂Design Pattern，一定要看一次