img006.jpg

  9/15圖書館通知我推薦的6本書已經購入,這是其中一本,9/20從圖書館的未上櫃新書架上借出來(其實一口氣把6本新到書籍全借出來了,好重),因為正好在看另外一本書,所以在學校只翻過它一次,大概看了一下Chapter 1,覺得還不錯,禮拜五就把它從學校帶回家,晚上看棒球比賽時,不經意地把它拿起來翻,可能是因為這些文章當初都是放在作者個人的部落格上吧!文筆蠻幽默的,每一章的長度都不長,越看越有趣,一不小心就翻完了。至於Joel是誰?他是Fog Creek Software的創辦人,就文中的說法,Fog Creek是一間位在紐約但規模不大的軟體公司,啥?一個小軟體公司的創辦人談軟體,那有什麼值得看的?事實上,他的部落格蠻有名的,而且他曾在微軟擔任VBA (Visual Basic for Application,一種能讓你在Office裡面寫些小程式或稱作巨集的東西,簡化一些瑣碎的麻煩事)的產品經理,不論我個人對微軟這家公司的看法,VBA不是小東西,他能寫出500頁的規格書,在Bill Gates親自主持的BillG會議上,只被Bill罵四次髒話(據說被罵次數越少越好,這不是廢話嘛XD),最後讓產品上線(Chapter 1),不得不佩服他。

  事實上,我覺得他以過來人的身分,對微軟這家公司的評論倒是非常務實的(好壞都有),例如Chapter 18,他對於Office二進制檔案的看法:為什麼用二進制檔?為什麼會格式這麼複雜?複雜到開放原始碼陣營即便用反向工程(微軟直到2008年初才公布規格書,那時Office已改用新的XML格式儲存檔案),也無法保證能把檔案讀進來後,顯示的和在Office上的一模一樣。有些事情的背後是一些歷史包袱,例如要在只有20MHz 80386和1 MB記憶體的電腦上執行Excel,如果檔案不需解析就能直接載入到記憶體中,那速度會快上許多,但缺點是很難看懂,而且當初並沒有其他程式會讀取Office的檔案,為何要對一個不存在的資訊交換需求設計檔案格式呢?基本上,我同意他說的說:要讀Office的檔案,請用微軟的SDK,快又方便!

  喔~對了,他也提到匈牙利命名法(Chapter 23 讓錯的程式看得出錯),事實上以前我寫程式也用過匈牙利命名法(寫過MFC程式的人應該知道我在說什麼),但就像他說的,我用的是惡名昭彰的那個版本(變數字首加上type),後來覺得麻煩沒有必要,於是就沒再繼續用,但久而久之,我的某些命名法竟然和他說的原始版匈牙利命名法(變數字首加上kind)有相似之處,因為這樣確實容易檢查程式錯誤,真是意外的相似!另外,他對於標準的看法(Chapter 17 火星耳機)真是精闢,所以看到ACID 100/100的瀏覽器,也不保證你寫的網頁一定會如你想的顯示,除非你對HTML和CSS標準的解讀和瀏覽器對HTML及CSS標準的解讀是一樣的,不然很可能就會出現怪異的樣子,所以寫Web應用程式且為瀏覽器相容性爆肝的工程師,辛苦你們了XD。標準的解讀會不一樣?你在開玩笑吧!不,只要是寫成文字的東西,A和B的解讀就可能會不一樣,不只HTML和CSS,連硬體的規格都是如此,不然硬體為什麼需要相容性測試呢?

  這本書還有很多有趣的東西,例如:如何尋找優秀的開發人員(Chapter 2),依照他的說法,我應該買張WWDC 2011的門票,然後在茫茫人海中找他聊天,並訴說我在北科資工是如何被OOP荼毒XD,那我應該就可以進到他那個有提供私人辦公室的公司了(Chapter 27)。如果畢業後想當程式開發人員,可以看一下Chapter 8~10,裡面提到一些建議:學會寫作(正在磨)、學會C (我知道為什麼while (*s++ = *t++) ;可以複製字串,且不會當掉)、學會個體經濟學(下學期吧XD)、別因非CS的課無聊而放棄(這...有點難,如果真的很無聊XD)、修需要寫大量程式的課程(我已經修了,而且還成了會出很多程式作業的助教),和別擔心工作都會外流到印度(現在是擔心外流到大陸吧XD),如果真的在WWDC遇到他,我會跟他建議,來台灣的北科資工找工程師吧!這裡的程式訓練很紮實,而且絕對不是Java學校(Chapter 8)。

  其實,整本看完除了他對辦公室的看法印象深刻外,他是我少數看到在書中談到UI設計和Usability的軟體工程師,也是少數會去注意Microsoft和Apple在字型平滑化上理念不同所帶來的差異(可以試著安裝Windows版的Safari,然後用Safari、IE、Firefox或Chrome開啟同一個網站,最好是英文網站,除了字的間距不同外,把網頁顯示比例拉到200%以上,就會很明顯感受到字的邊緣,處理方式是如何不同了),這也許也是為什麼iPhone 4會使用解析度4倍的Retina面板,但有人覺得沒必要的差別。事實上,我曾參加一個會議,一邊是設計所的代表,一邊是電子系的代表,從對話跟需求,很明顯就會知道為什麼很多沒有美術人員的軟體團隊,開發出來的軟體是如此醜!是,我可以再說一次:醜!

  好啦!說了一堆,在他最後的幾章,談論到創立軟體公司的建議,不過,在台灣,有些因素完全不同,所以...再看看吧!說不定寫書還比當工程師賺錢(大誤)。總之,這是一本值得推薦的書,有趣又務實!

創作者介紹

Spirit的異想世界

dbi1463 發表在 痞客邦 PIXNET 留言(0) 人氣()