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面板，但有人覺得沒必要的差別。事實上，我曾參加一個會議，一邊是設計所的代表，一邊是電子系的代表，從對話跟需求，很明顯就會知道為什麼很多沒有美術人員的軟體團隊，開發出來的軟體是如此醜！是，我可以再說一次：醜！
好啦！說了一堆，在他最後的幾章，談論到創立軟體公司的建議，不過，在台灣，有些因素完全不同，所以...再看看吧！說不定寫書還比當工程師賺錢(大誤)。總之，這是一本值得推薦的書，有趣又務實！
留言列表
