Tag Archives: 電腦

Seven Databases in Seven Weeks 2nd Edition – Luc Perkins

很多年來我一直只懂SQL,沒有學習其他database,早十年NoSQL還是剛冒起,我還有點看輕它,覺得它冇用。俗語有云,當你手拿著鎚子,所有的問題都變成釘子。只懂SQL,很自然習慣把所有問題都用Relational Database去解決,儘管要花更加多的氣力,有時殺雞亦要用牛刀,因為只得一把刀。

這本書2018年出版,已經是第二版,很多年前第一版時已經想看。只不過是短短三年,書中有些code已經過時了,新版本database的syntax有點不一樣,不過基礎理論沒有改變,仍然合用。NoSQL有太多選擇,想學習也老鼠拉龜無從入手。這本書介紹最熱門的七個database,從傳統SQL的Postgres為起點開始,然後逐一講解其他NoSQL DB的優劣trade-off,什麼情況適合應用。比起每次只教一種database的書,讓讀者有宏觀的視野。

因為一本書要教七個DB的關係,這本書的內容非常壓縮,簡單的基本操作甚至略過不談,直接叫讀者去看官方document。每個DB的教程分為三部份,讓讀者可以連續七個星期,每個週用三日學完。我一口氣一次過看完,一章大約要用四個小時,不過我只是跟著example打code玩下個DB,沒有個每日的功課,若果做埋功課,大約要兩倍時間。

第一章Postgres是溫習SQL,我以前用開MySQL同SQLite,也算是學新野。第二章教HBase是columnar database,沒有隨意search的功能,要靠index去讀data,但是非常scalable,是Google Cloud Bigtable的開源版。第三章教MongoDB是document DB,search JSON的功能很強大,不用寫schema很方便。第五章教couchdb,與MongoDB一樣都是寫JSON object,但couchdb的read要事先建立views,另外監視change的功能也很好用。

第六章教是我最有興趣的Neo4J,但書中教了graph DB的很皮毛,連Cypher語法如何閱讀也沒有教,我要上網再找資料自學。Graph DB同SQL很大分別,完全是另一個類型的應用,學了大開眼界。第七章教AWS DynamoDB,個database本身很平平無奇,強大是AWS後台的支援,連著AWS其他功具一起教,學習寫data pipeline,提升用DB的另一個層次,真正的big data。最後一章教redis,簡單易用夠方便,我認為redis應該早些教,in memory key-value store都啱做一些quick and dirty job。

這是一本不適合新手的入門書,教的東西很廣闊但很膚淺,主要是給讀者一個perspective,之後讀者就要靠自己去看document了。若果要看完一本書就能立即上手揼project,拖著一步步教導如何建站,這本書並不適合你。反而這本書更像是sampler,淺嚐每種DB的味道,並例一起觀察它們的異同,然後覺得那個DB有用,就再上網去找資訊深造。讀這本書有一個好處,讀完後基礎理論打了底,讀official document快很多,可以直接跳過不用看其他書,反正去到最後都係要翻查參考official document。

Introduction to Computer Theory – Daniel I.A. Cohen

9788126513345_1

在很多大學中,電腦系不是附屬於工程學院,便是附屬於科學院。我以前讀的大學很奇怪,電腦系是附屬於數學院,當年我不明白原因,電腦可以用來計數,但電腦和數學有什麼關係呢?我是讀電腦工程系出身的硬件人,當年與電腦科學的同學談起,聽他們說電腦理論很難明高呼救命,天真的我以為讀電腦科學不就是學寫程式嘛,有多難?直至很多年以後,某次去印度工幹買了這本《電腦理論入門》,丟在書架上又過了幾年,然後某天心血來潮打開來看看,前後繼繼續續花了兩年多才看完,終於我明白原來電腦理論不等於電腦,而是數學上如何械械式解答問題的定律。

這本Daniel I.A. Cohen的《Introduction to Computer Theory》,是電腦理論的經典課本。某種意義上,這本書非常沉悶,全本書就好似中學讀數學不停學proof。從最簡單的regular expression開始proof,一路到finite automata,到context-free grammer和pushdown automata,最後就是頂頂大名的萬能電腦原形Turing Machine。證明什麼類形的電腦可以接受什麼類形的language,某notation又可以如何與某graph等同互換。最精彩的章節是詳細解釋Turing Machine,以前上堂聽過這個term,記得教授說過TM是萬能電腦,看完這本書後,終於明白為什麼TM可以計到任何可以計得到的數,即可以解答任何能找出答案的問題。再一次佩服Alan Turing的天材,TM的構造極其簡單,可是沒有任何機械能超越TM的解題能力。

最初開始讀這本書時,我不明白language同電腦有什麼關係,不就是一串串不同的string,起個state machine去判斷一個input是否屬於language之內,程序上是有點麻煩不過也不是很複雜,要用咪call library囉。去到context-free grammer開始看到有點關係,至少寫compiler的第一步就是要parse個syntax tree。一直以無比的耐心閱讀著,逐步逐步follow書中的proof,然後有一天開竅了,忽然間看到language和solve problem之間的關係,任何能夠解答的問題都是一個數學題,電腦就只是從機械化地處理input,然後給一個output的系統,output可以是答案,但更多時間只是一個yes/no answer,又或者更基本的halting problem。找出一個問題的答案,只是最表面那層,找出一問題有沒有可能有答案,如果有答案的話,有限時間內能否找到,那些bounding的meta問題,才是電腦理論的核心。至於如何寫個行得快些慳位些的algorithm去解題,已經是應用層面上技術性的次要問題。

若果不打算理會那些proof,這張圖表大慨是全書內容的總結。老實說那些proof讀完大部份都忘記了,能夠記得大慨就只有這圖表的內容。不過讀proof的最大得著,是讀proof會潛移默化你腦袋的思路,看完知道的東西和未看差不多,但再遇同類問題時會有一份直覺。

初版pdf下載,我看的是第二版實體書。

Mobile Unleashed – Daniel Nenni and Don Dingee

mu

考考你,你知道你手機入面的CPU是那間公司製造的嗎?多得Intel多年來咚咚棟冬的廣告,一般人都知道電腦的CPU主要由Intel製造,但說起手機,只會聯想起蘋果和三叔,完全沒有聽過ARM這間公司。現今的智能手機,甚至早年的2G手機,手機CPU市場佔有率,ARM差不多是百份百,可說是獨市生意。《Mobile Unleashed》這本書,講述ARM的發跡史,如何從十二人的小團隊,三十年間發展至二百億市值的高科技王國。這本書不單是ARM的歷史,更加是整個手機業界的歷史。

ARM全名Advanced RISC Machine,原本個A字代表Acron電腦公司,ARM只是其研發部的一個實驗項目。當年IBM如日中天雄霸整個電腦市場,其他電腦公司一邊抄考IBM電腦賣錢,另一邊則希望開發新產品打破IBM的壟斷。RISC就是這樣的環境下開發出來的CPU架構,與Intel的x86系列CISC CPU完全不同的設計概念,犧牲複雜的功能換取精簡的指令架構。當Intel搶佔商用家用電腦市場,其他RISC晶片廠商如SUN和MIPS,則憑著RISC架構的高運算速度,在server市場開拓出另一片天空。而ARM的RISC晶片,論功能不夠x86強,論速度不及其他RISC廠商,只有一項優點就省電。

不過當年電腦不能移動,反正都是插著電源,省電完全不是賣點,ARM晶片完全沒有生意。Acron準備解散團隊止蝕,這時命中註定的救星出現,蘋果要開發平板手提電腦(還不是iPad,二十年前那個叫Newton),需要開發更省電的CPU,於是找上門來。商討後ARM從Acron獨立出來,蘋果佔一半股權,Acron和VLSI佔另一半。雖然新公司有蘋果這個大客支持,可是實際上還是窮得要命,相傳ARM的初代CEO上任第一個工作,就是四出尋找平價二手家俱。Newton是蘋果第一次後教主時代的滑鐵盧,走得太前技術完全未成熟,功能未如人意成本天價,最終全球只賣出六萬部。

Newton雖然失敗了,但為ARM爭取多幾年的時間,繼續改良CPU的技術,終於等到流動電話時代的來臨。最初1G電話用Analog技術,上了年紀的都記得當年大大舊的水壺電話。2G GSM改用Digital技術,對於CPU的需求增加了,但手機的電池容量有效,省電便成為最重要的決定性因素。ARM的第一個大客是Nokia,雖然Nokia現在執了笠,當年可是手機的一哥,比今天蘋果還厲害,高達過半的市場佔有率。之後ARM逐一攻陷其他手機廠商,差不多所有手機都是用ARM。與Intel自已生產CPU不同,ARM其實是一個IP智識產權公司,ARM開發CPU的程式,然後授權給其他公司生產,每台電話都收取專利稅。每粒CPU的利潤雖然不如Intel多,但與廠商共同建立開發生態環境eco-system,在有錢齊齊搵的大前提下,各手機廠商都樂於和ARM合作。雖然人人都用ARM,但有不少生產商可供選擇,不怕有像Intel壟斷市場後,獨市生意抬高價值的問題。

蘋果今日貴為全球最有錢公司,但當年教主第一次出走後幾乎破產。教主回歸蘋果重新掌舵,展開救忙大行動,賣掉了ARM的全部股份,把資金投放在iPod開發上。當年蘋果出手救了ARM,現在輪到ARM救蘋果。蘋果手提開發部早對ARM十分熟悉,iPod很自然源用ARM的晶片。iPod取很空前成功,然後就是Newton的終極完全版,遲來了二十年的iPhone,從此改寫了手提電話的歷史。三星與ARM亦很有淵源,早在2G手機年代便已用ARM,更把ARM用自家mp3機和DVD機上,從低能手機過渡至智能手機,很自然繼續便用ARM。有玩開Andriod旗艦機的朋友,都聽過Qualcomm的Snapdragon晶片,裏面的程式都是ARM授權生產。當年Qualcomm發明CDMA通訊技術,是整個3G/4G手提通訊的理論基礎,它從radio晶片做起,一路從外至內把radio與CPU整合。

說來諷刺,最初Qualcomm是原本與Intel合作,不過Intel嫌手機市場太細,賺不到錢索性退出市場,把Qualcomm拱相讓給ARM。當年蘋果整初代iPhone,同樣也是打算和Intel合作,Intel亦用同一個理由推掉,結果Intel白白錯過整個手機市場。不過看ARM的歷史,學懂了一件事,在高科技行業的世界中,技術實力固然是必要的本錢,但一間公司最後能否成功,最重要還是要講運氣。ARM轉捩點的幾單大生意,不論是蘋果還是Nokia,基本上ARM都不是首選。可是首選交不出貨,ARM冷手執過熱煎堆,然後一切才成為歷史。今年九月日本軟銀集團,宣告全面收購ARM,目前還等候政府批準合併,不知道ARM的未來會如何,一代手機王朝會否從此衰落?

21st Century C, 2nd Edition – Ben Klemens

這本書不適合學寫程式的初心者看,不過今時今日有更多更新更易學的語言,相信沒有初學者會揀學從C開始下手。這本書寫給兩類人看,一類是我這種十幾年前學過下C,放低很久現在要更新知識,另一類是有其他程式語言底子的人。這本書與我初學寫程式那個年代的課本很不同,其編排完全輕視C語言的文法和格式(syntax)。其他傳統C課本大半本書講syntax,呢本書就用最尾一個附錄單簡介紹下就算。反正那些東西不用死背,可以落手落腳時才邊做邊學,有IDE auto-complete又有網上參考,又真係唔應該浪費墨水。

這本書一開始花三分一本書講與C沒有直接關係的東西,不過現今寫C程式一定有用的工具軟件,如gcc,git,makefile等,還有一些更深入的Linux題材如整package,乜野係process,點寫dynamic library等。以前學寫C,課本連如何compile個program也不會教你,一開始老鼠拉龜不知如何下手。學這些東西說難不難,說易不易,不過這本書把它們放在一起,有齊從零到軟件出街一條龍所有必要步驟,十分方便。課本講的主流opensource應用工具,不過知道工具的類別和名稱後,不艱search更加好用的point tool。

好了,論到主菜上碟,終於入正題講C。一黎就出最堅係,講pointer。夫pointer者,C之上乘內功心法也,只要精通了pointer,你就等於學了C的精髓,可以寫出超快的程式,pointer是其他程式語言所沒有,最接近assembly的存在。接下來作者講新一代C-99的語法,主力指出上古時代那些課本教壞人的寫法。嚴格來說不可說教壞人,只是當年的compiler有技術限制,不能不那樣寫code,現在的compiler強勁多了不再有那些限制,不求甚解的人照跟舊寫法,其他有更方便更易讀的寫法。最後三分一本書不知作者玩野定show off,教了大一堆超強macro,可以讓C模仿新一代高階程式語言,連OOP都可以在C做到,只能寫個服字給他。不過我始終是舊時代的C人,對macro十分抗拒,因為macro好鬼死難debug。其實點解要用macros寫那麼複雜的語法呢,為什麼不索性用C++算數?

讀過了這本書,就升級成為新一代的C人,識寫新C。

Programming Linguistics – David Gelernter and Suresh Jagannathan

早前因工作上的需要,要設計一個新的程式語言,在網上找參考資料時,遇上了這本早已絕版的奇書。差不多每篇有關程式語言設計的論文,必定引用這本書。這引發我的好奇心,於是我大學的圖書館中,找來這本書借來一讀。不看猶自可看罷方知自已井蛙觀天,雖然自中學以來寫了程式超過二十多年,卻從來沒有思考過何謂程式這個最基本的問題。一直還以為自已寫程式功夫不錯,原來不過是學到幾個招式套拳的外功,這本書說的卻是寫程式的易筋經心法。讀過這本書,面對任何程式語言,也都可以一理通百理明。

一般教寫程式的書藉,通常從程式的文法和應用例子作教材,學生跟著練習題去學,慢慢便可以寫出像樣的程式,可是始終有點兒像鸚鵡學舌,沒錯能夠寫程式,但卻不明白程式是什麼。但這本書沒有教任何一種特定的程式語言,而是從語言學的角度,去分析歷史上重要的程式語言,到底新的文法帶來什麼的轉變,而同時亦指出不論什麼轉變,也都是萬變不離其中的基本觀念。

書本一開始便澄清什麼是程式,程式不是軟件或硬件的分別,甚至電腦本身是否存在也不重要,程式是一個抽像的機器,只是知訊的某一種狀態。程式語言只是代表程式的符號,任何程式語言在抽像的層面也是共通和等同的,只是不同語言設計的重點取向,有意無意左右了程式編寫員的思考模式。整本書的靈魂便是第二章中,提出的完美程式機器的模型。不論任何程式,也可以用時間(函數)和空間(記憶)去表達,而這兩者是可以互相轉換。靜止的程式源碼和運行中的程式,在抽像層面是同一樣東西,不過是時間和空間的關係改變了。

接下來的所有章節,都是回顧程式語言的發展,把每一個重要里程碑的語言,用完美程式機器去分析作比較。書中提及的程式語言,隨了做學術研究外,現今已沒有什麼人用。反觀現在最流行的幾種語言,本身並沒有獨創性可言,只是在走前人開發出來的路。這本書寫於一九九零年,超過二十年前。可是過去二十年,程式語言的發展卻停滯不前,只是不斷建立更多的程式庫,但最在基本的程式語言的思考方法上,與二十年前比較沒有多少突破。

始終這是一本大部頭的學術書,我很難在此以有限的文字,用三言兩語把書中慨念表達清楚。我特別想說的是,當我讀到完美程式機器的理論,我感到叮一聲開竅的感覺,多年來寫程式不明所以的地方,就在這一刻豁然領悟了。若果寫程式也有禪的話,這無異便是頓悟的境界。讀電腦的朋友,靠寫程式維生的朋友,這是一本會改變你想法的書。這書本學校不會教亦無法教,因為要寫程式多年,心中產生無數問號,才可以看懂程式的玄妙。

The Ten Commandents for Effective Standards – Karen Bartleson

說在前頭先申報利益﹐這本書在Amazon原價二十大洋﹐我那本是去科技會議免費送的。一百頁也不到薄薄的一本書﹐要花二十美元實在太貴﹐不過不用錢看看又無妨。這本書的題材可說是前無古人只此一家﹐目標讀者是科技人員﹐特別是參與制定標準技術規格的人。這是一本很實用常識性的書﹐在科技行業工作了一段時間﹐接觸過無數的技術規格後﹐不多不少也會懂得書中的內容﹐只是這本書很方便地以十戒方式列舉出來。

作者任職半導體科技公司Synopsys﹐參加過很多標準技術規格的委員會﹐見盡不少成功和失敗的技術規格。她綜合多年的工作經驗中﹐寫成這本小書回饋科技界。公司出錢印製﹐當成禮物送給客戶﹐反正客戶全都工程師﹐工作與技術規格息息相關。一來作者可以出書成名﹐公司好過送無用的螢光筆拍子簿﹐書中的資料對讀者也有著實用﹐真是一箭三鵰的高招宣傳手法。

標準技術規格的重要性﹐相信不用多費唇舌介紹了。沒有技術規格﹐不同公司的科技產品東西互不相容﹐市場混亂消費者不知所措。簡單如供電插頭和電話線﹐到電腦USB或DVD的格式﹐甚至無線電話訊號﹐整個互聯網本身﹐也是因為有通用的技術規格﹐我們日常生活才能運作正常。試想如果完全沒有技術規格﹐Nokia的電話只能打給Nokia的電話﹐會是一個怎麼樣的世界。當不同公司的產品需要相容時﹐就必需要制定一個技術規格。通常在幾間大公司帶頭下﹐在不同的委員會機制如ITU﹐IEEE﹐ISO下﹐組成一個規格委員會。然後各公司在技術或市場考慮上磋商﹐開發一套大家共同認可的技術規格。

不是所有技術規格都必然成功﹐也有很多沒有人用沒有人理﹐被歷史遺棄的技術規格。作者總結多年觀察﹐寫成技術規格十戒﹐預防失敗的技術規格﹐以免浪費人力物力。

第一戒﹕在規格上合作﹐在產品上競爭﹐做大市場塊餅
第二戒﹕要小心把專利和規格分清楚﹐不然會有很多法律問題﹐甚至喪失專利權
第三戒﹕要知道何時停止﹐若技術走入死胡同﹐便不要再浪費時間
第四戒﹕規格要真正公開透明﹐不然沒有第三者廠商會支持
第五戒﹕規格委員會中﹐沒有完全中立的委員﹐說到底技術規格是因應市場需求﹐廠商最終目標是賣產品賺錢
第六戒﹕借用現行有效的規格委員會機制﹐一來公信力高消費者有信心﹐二來不用浪費時間決定機制
第七戒﹕技術規格是要解決真實的問題﹐一開始沒有問題根本就不需要規格
第八戒﹕製定規格有很多不同方法﹐要懂得每個方法的優劣
第九戒﹕不要從頭造起﹐採用並改良廠商捐出來的技術規格。正所謂萬事起頭難﹐再者如廠商沒有興趣﹐大慨這個規格也不會有市場
第十戒﹕要明白技術規格中﹐除了技術考慮外﹐更重要的還有商業考慮﹐說到為什麼會有技術規格﹐還是因為廠商要賣產品賺錢啊﹗

Debugging – David J. Agans

Debugging除蟲(Debug)是每個寫程式或做設計的人也必須要懂的基本求生技巧。沒有人可以落筆永不犯錯﹐所以去找出錯誤並加以修正是必經的階段。這個除蟲的過程很多時間痛苦而漫長﹐特別是那隻蟲在別人的傑作裏面。我自小玩寫程式和砌電腦﹐大學時讀工程系﹐出來做時是當工程師﹐無不是和蟲打交道。不是自賣自跨﹐我對抗蟲害經驗豐富﹐除蟲快而準。很多時候我覺得除蟲不單要腦筋好﹐還要有點除蟲的藝術才能夠有效率。但說起來我除蟲好像沒有什麼特別方法﹐也沒有什麼可靠的系統可言。就像語文那樣是與生俱來的能力﹐自己懂如何去做﹐但很難教別人如何除蟲。Debugging這本書正好填補這個空位﹐很有系統地歸納出除蟲九大定律。

這書的作者畢業於MIT﹐在科技行業工作多年﹐是很有經驗的工程師。他見市面上完全沒有關於除蟲的書﹐於是把多年的除蟲心得整理寫下來﹐希望可以幫助後輩掌握除蟲技巧。書中依次例出除蟲九大定律﹐每一定律也有詳細解說﹐並且附以作者經驗的真實案例去說明應用。最後幾章將所有定律融會貫通﹐展視給讀者由發現問題到找出錯誤﹐如何把定律綜合整個除蟲過程。最後一章很特別﹐從helpdesk的角度出發﹐把定律在他們的眼中演譯一次。對在helpdesk當技術支援的人故然有用﹐對打電話去helpdesk救助的人﹐即是其他所有人也有幫助。知道helpdesk如何運作﹐配合他們想要的資料﹐才能更快解決問題。

我把除蟲九大定律翻譯出來﹐給大家作一個簡介﹕
1. 徹底明白系統的運作。如不明白﹐請先把使用手冊由頭到尾讀一次。
2. 讓系統失靈。系統失靈是除蟲的第一條線索﹐看不見失靈就找不到蟲。
3. 不要靠估﹐要看清楚那兒出錯。除蟲的精髓不在於要估得準﹐
而是如何去減少估錯的機會﹐一估錯就會浪費很多時間行錯路。
4. 分而攻之。把蟲出沒的笵圍收窄﹐如是者就會找到蟲的位置。
5. 每次只改一樣。一次過改太多﹐不單不能除蟲﹐還有可能產生新的蟲。
6. 所有事也要有記錄。沒有詳細的記錄﹐就沒有足夠的資料去除蟲
7. 看看有沒有插電掣。最安全的地方就是最危險的地方﹐
最白痴最顯眼的錯誤﹐往往最容易被忽略看不見。
8. 不要鑽牛角尖﹐想不到就要虛心問人。
9. 試清楚修正是否有效。很多時候以為找到蟲錯誤修正好就完工﹐
只不過恰巧那些好彩沒有遇上問題﹐蟲還是好端端在那兒等下次再咬人。

雖然我在看這本書時﹐不禁想這除蟲九大定律只不過是簡單常識﹐任何寫過程式的人也必定無師自通學會。可是回顧一下我的除蟲經驗﹐久不久我自己也會一時大意違反這些定律﹐弄得團團轉不知如何去解決。現在有人很有系統地寫了出來﹐不單讓我更深刻記得這些除蟲定律﹐還可以讓我很精確地把除蟲技巧教人﹐不會自己懂但找不到言語形容的煩惱。這本書奉送除蟲九大定律的海報﹐我特別印了出來貼在我的工作間。當自己找不到蟲毫無頭緒時﹐抬頭細看這九大定律﹐回想自己違反了那條﹐警惕自己改過﹐很快就可以找到害蟲。當別人問我有關除蟲的問題時﹐我可以很省氣力地著其中一條回答他。不論是除蟲新仔還是經驗老手﹐這本書應被奉為除蟲寶典﹐任何設計程式或硬件的人也應該要讀一遍。

Rapid Development – Steve McConnell

Rapid Development 這書本不是為興趣而讀﹐而是因工作上的需要而讀。我在新的工程企劃中﹐要領導一個得幾個新人的小組﹐負責開發計劃中的其一個子系統。我出來做事這幾年來一直也是做細的那個。雖然在技術專長上受到肯定﹐也做過些獨立完成的工作﹐但要話事還第一次﹐可以說毫無管理經驗。我老細也是工程司出身﹐明白我適應上的難處﹐於是借了這本書給我看﹐他說這是他的管理天書。這不是一般的管理書藉﹐而是特別寫給軟件開發管理。雖然我們公司是做硬件不是做軟件﹐但在電腦搞鍵盤的工作性質也很相同。這本書的適合科技公司的中下管理層看﹐熟讀書中的理論和應用實例﹐可以增加幾個人至幾十個人團隊的工作效率。整本書有五百多頁﹐反正計劃開始時很清閑﹐我在公司有空時看幾章﹐不到一個星期就看完了。

以前在大學時也有上過管理課﹐不過課本上的東西﹐早在畢業時還了給教授。很多時候只記得大慨意思卻忘記細節﹐讀這本書正好重溫不少有用的知識﹐這本書很有系統地由最基本的理論開始﹐由計劃議案﹐團隊組成﹐風險評估﹐死線時限﹐對外對內的溝通方法﹐到市場部對開發部間的政治也有詳細解說。書後的附錄還有一系列的工具箱﹐詳細列出有什麼管理手段可以增加效率﹐並每種手段的優劣和適合在什麼時候用。每章隨了理論外還有生動的例子﹐是作者跟據他多年的工作經驗改篇﹐我讀到的時候也有點身同感受﹐那些情況好像似層相悉。

看這本書的最大收獲﹐是學懂了那套管理語言﹐才能夠有效地思考計劃的問題。很多時候有直覺告訴我不對路﹐但沒有理論基礎就無法清楚地指出問題所在。看完書我還可以現學現賣﹐引用書中的理論﹐告訴老細若計劃遲已經有延誤﹐假話可以後來追上進度是不切實際。一個開發工程有三項要求可以互相交換﹐一是省人手﹐二是多功能﹐三是快完成﹐但在三項中只可以同時選擇兩項﹐若要三項全選則連是神仙也無能為力。對上老細的老細也是明事理的人﹐為要保存原本的功能和死線﹐只好增加人。這本書只有一點我十分不認同﹐就是作者好像常常有意無意提及加班。我認為加班不是應該是常態﹐在趕死線前趕幾個星期沒有問題﹐計劃完了通常可以放回補了的時間。一個職員如果在工時內做不完要做事﹐要長時間要加班趕工﹐只可以說明這個人的能力出了問題。若他的能力沒有問題﹐而是管理層不停把過量的工作硬塞給他﹐則是管理層的管理能力有問題。但如果計劃剛剛開始時﹐就已經把加班計算入開發所需的時間內﹐那這個計劃一定不能準時完工。這是妄想三個要求也同時想選擇﹐如果死線不能改﹐就要多加點人手或減點功能﹐面對現實是成功的第一步。

這好本書我當然要還給老細﹐不過我認為這是一本很有用的參考書﹐每次開計劃期也應該拿來翻翻﹐重溫一下基礎理論避免幹蠢事﹐所以我自己上網買了本二手放在書架。若他日我升多一級有兩層手下﹐我也會推薦這本書給剛剛升上去的小組長看。不過如果再升上去﹐這本以開發工作實戰為主的書則沒有太大用了。行政人員才不會去理﹐這些雞毛蒜皮的要落手落腳做的事呢。