書摘《約耳趣談軟體》 下篇

整理時發現內容真的有點多，為了盡量控制在 10 分鐘左右的閱讀時間，就分成兩部了，還未看過第一部的，可以到 書摘《約耳趣談軟體》 上篇 看一下喔！

Part 2 開發人員管理

Chapter 20 面試人員教戰守則

想傭有優秀的程式設計人員，第一件事就是要雇用隊的程式設計人員。這表示你必須找出「誰是對的人」，而這件事通常要在面試過程中完成。 _{p. 160}

可能有人說這不是廢話，但事實上要做到很難。

我會傾向放棄錯誤很多的履歷，因為馬虎草率的履歷代表工作也無法盡心盡力。 _{p. 160}

機械式地所有模糊不清都翻譯成「不」，一切就海闊天空了。 _{p. 163}

因為否決一個好人選比接受一個壞人選結果要好太多了。糟糕的人選會耗用大量金錢和精力，還要浪費別人的時間去修正他們所產生的錯誤。 _{p. 163}

你要找的人必須：聰明、能把事情做好。 _{p. 163}

這幾年不斷地面試新人，回頭再看這一章特別有感。

最重要的是避免違法的問題。任何有關種族、宗教、性別、國籍、年齡、兵役資格、退役情況、性向，或身體殘疾的問題，在美國都是不合法的。 _{p. 173}

不確定台灣是不是，但我個人也不問，這些跟一個好的工程師沒有任何關聯。

Chapter 21 激勵是有害的

把你的頂尖員工當成幼稚園小朋友對待，並不是罕見的特殊現象。幾乎每家公司都有同類型祭屋母又貶低人的獎勵方案。 _{p. 176}

績效評估對士氣的作用並不是相對的：負面評價隊士氣傷害很大，可是正面評價並不會改善士氣或生產力。 _{p. 177}

Chapter 22 不用測試人員的五大 (錯誤) 藉口

QA 部門應該有獨立並擁有權力，絕對不可以對開發團隊負責，事實上，QA 的主管應該有否決權，可以阻止發行不合格的軟體。 _{p. 180}

程式設計人員是沒辦法當個好的測試人員，小心因此而損失了更難找的優秀程式設計人員。 _{p. 185}

Chapter 23 人的工作切換有害無益

工作切換會需要很長的時間。因為程式設計這種工作必須同時在腦袋裡記住很多事情。此外，當記住的東西愈多，寫程式時的生產力也愈高。 _{p. 190}

好的產品經理會認為自己的責任是消除一切阻礙，好讓大家都能夠專注在一件事情，並把它完成。 _{p. 190}

Chapter 24 你絕對不應該做的事之一

他們做了一個每家軟體公司都可能犯的最糟策略錯誤：他們 (Netscape) 決定把程式從頭寫過。 _{p. 191}

他們會認為舊城是一團亂的真正原因，其實是一個很基本的程式設計原理：讀程式比寫程式困難。 _{p. 192}

你一定要記住，想要從頭重新開始時，請不要抱著這次會做得比第一次好。首先，你的程式團隊根本不可能和當初相同，所以並不會真的有「更多的經驗」。其實只會把大部分的舊錯誤重新再犯一次，並且再多增加一些舊版本所沒有的新問題。 _{p. 195}

不是沒有成功的例子，但真的不多

Chapter 25 揭露冰山的秘密

客戶不知道他們要什麼，別再期望客戶知道他們要什麼。 _{p. 198}

這句話，我覺得換個說法會比較合適，客戶知道他們的 domain know how，但他們不知道怎麼用軟體來處理這些 domain know how。

不過，切記軟體的設計才是你的工作。如果你能搞懂該應用領域，而設計出一套好的使用者介面，客戶會很高興。 _{p. 199}

Chapter 26 抽象滲漏原則

所有重大的抽象機制在某種程式上都是有漏洞的。 _{p. 207}

唯一能適當處理漏洞的方法，就是弄懂該抽象原理以及所隱藏的東西。所以抽象機制雖然替我們節省了工作的時間，不過，學習的時間是無法省的。 _{p. 210}

Chapter 27 程式設計領域的帕麥爾斯頓勳爵

抽象滲漏原則卻表示，即使他們建立了這些理應讓程式更易設計的抽象機制，而優秀程式設計人員所需的各種知識仍是持續增加。 _{p. 213}

只有極少數人能清楚一個以上的世界，因為要學的實在太多，除非在這些世界工作過幾年，否則是不會全部都懂得。不過，你卻必須學會。 _{p. 215}

排除公司政策，我個人是不找全端工程師...因為大多都是「號稱」全端工程師。

Chapter 28 量測

似乎每次想要測量知識工作者的績效時，情況就會急速走樣，然後你就會得到 Robert D. Austin 所說的測量機能障礙 (measurement dysfunction) 現象。 _{p. 222}

簡單說就是知識工作者很聰明，你想要什麼數字，你就會得到數字。喔~ 對了，要程式設計師打卡是一件很蠢很蠢的事情。

Part 3 如果你是約耳既定主題的隨機思考

Chapter 29 Rick Chapman 在尋找愚蠢

如果你想要在軟體業成功，必須要有一個完全了解並熱愛程式設計的管理團隊。不過相對的，這個團隊也必須了解並熱愛商業。要找到對兩邊都很有天賦的領導者並不容易。 _{p. 231}

Chapter 30 這個國家的狗做些什麼工作？

在電腦業界中，「吃自己的狗食」(Eating your own dog food) 是個怪用法，表示真正在使用自己產品。 _{p. 236}

有時當你下載了某個軟體，卻發現它爛得無法置信，或是費盡工夫才能完成該軟體應該可以簡單做好得事。而原因很可能就是開發人員並沒有用過該軟體。 _{p. 237}

Chapter 31 小員工也能做大事

找出那些願意又有能力改善的人，想辦法讓他們支持你。即使是再爛的團隊還是會有聰明人在，只是缺乏寫出好程式的經驗。幫助他們脫離困境，安排他們學習。 _{p. 241}

不要開著你的電子郵件和即時通訊。必要時可以每小時收一次信，切記不要一直開著。 _{p. 242}

Chapter 32 兩則故事

相較之下，在微軟事情都是由最基層完成，大多數經理的工作好像只是到處閒逛，把家具搬開不要擋道路，好讓大家可以專心工作。

真的？我懷疑...

Chapter 33 大麥克對上原味主廚

截止到目前為止的概要如下：

• 有些事需要天份才能做得好。
• 天份很難複製。
• 有人嘗試複製天份，讓有天份的人建立規則，讓普通人照著做。
• 結果所得到的產品品質很低。 _{p. 254}

這些公司出色的創辦人應該都能適應新世界，畢竟他們都是有才能的電腦科學家，什麼東西都學得會。但是他們所建立的公司卻不是如此，因為公司用規則手冊取代了才能，而規則手冊是無法適應新時代。 _{p. 256}

這個故事的教訓是什麼？小心方法論。方法論可以讓每個人的表現提升到不佳但可接受的程度，同時也會產生很多約束，並且激怒更多的聰明人。 _{p. 256}

Chapter 34 事情沒有像表面看起來那麼簡單

「事情沒有像表面看起來那麼簡單」再加上「降低風險」只會導出一個結論：你必須先做設計再去實作。 _{p. 260}

無論如何，我不認為極致軟體製成真的在提倡零設計。他們只是說：「不要做無謂的設計」，而這一點是沒有問題的。不過，大家聽進去的並不是這麼回事。大部分的程式設計人員都盡可能地找尋藉口，以避免在實作前先做基本設計。 _{p. 260}

Chapter 35 為非我發明症辯護

非我發明症 (Not-Invented-Here; NIH) 被公認為典型的管理症狀，指某個團隊拒絕使用不是自己創造的技術。 _{p. 263}

任何人只要注意過去三十年間電腦程式設計的進展，就會知道重用 (reuse) 是所有現代電腦系統的聖杯。 _{p. 263}

如果你曾經把關鍵的業務交給外包，就會瞭解外包其實是個地獄。 _{p. 265}

如果是核心的事業功能，不管是什麼都要自己來做。 _{p. 266}

Chapter 36 策略書之一：Ben and Jerry 模式與 Amazon 模式

Amazon 型的公司募資的速度比任何人花錢都快。這是有原因的，因為他們要時間競賽。如果他們身處在一個有網路效益卻沒有競爭者的產業，最好能以極快的速度成長，因為這時候的每一天都很重要。 _{p. 271}

經驗告訴我們，你可以讓大家有個好的工作環境，或是允諾大家以後一定會發大財。一定得選一樣做，否則是請不到人的。 _{p. 273}

Chapter 37 策略書之二：雞生蛋蛋生雞問題

所謂的廣告就是說謊又不被抓到。大部分的公司做宣傳活動時，都只是把公司最差的事實反過來講 (也就是「說謊」)，深入且徹底的撒謊。讓我們稱之為「反覆主張證明法」。 _{p. 277}

如果你身在平台創造產業，可能會面臨一般稱之為「雞生蛋蛋生雞」的問題。除非擁有好的軟體，否則沒人會買你的平台，可是你的平台要有很多用戶，才會有人替你寫軟體。 _{p. 278}

對於如何破解雞生蛋蛋生雞的問題，你應該開始有些概念了吧。就是提供一個向後相容模式，依你的需要提供一卡車的雞或蛋，然後坐下來大賺鈔票。 _{p. 283}

Chapter 38 策略書之三：讓我換回去！

當你想讓人們由競爭者的產品改用你的產品時，必須瞭解「進入障礙 (barriers to entry)」，而且還要瞭解得比你想像中深入，否則大家是不會換過來的，而你就只能一直等了。 _{p. 285}

解決顯而易見的進入障礙固然非常重要，不過，自認已經處理好明顯的障礙時，必須繼續找出那些不明顯的障礙。而這就是這個策略略微妙之處，因為不明顯的事物也會阻止大家切換。 _{p. 287}

Chapter 39 策略書之四：腫脹軟體與 80/20 迷思

首先，如果程式設計人員不用考慮程式的大小，就可以更早完成工作。而這表示你可以得到更多功能，使用這些功能會讓你的生活過得更好，即使不用也沒有什麼傷害。如果你的軟體廠商在出貨前停下來，花兩個月把程式縮小到一半大小，你所得到的淨利益是微乎其微的。………不過新版軟體多等兩個月的損失是看得道的，而軟體公司放棄兩個月銷量的損失更是可怕。 _{p. 293}

結論是：如果你的策略是「80/20」，是很難賣出軟體的。這就是現實。這個策略和軟體業本身的一樣老，就是不能奏效。 _{p. 294}

我覺得不是盲目相信或不相信 80/20，而是要有數據有效率地投入資源開發有用的功能。

Chapter 40 策略書之五：開放源碼的經濟學

我注意到開放源碼軟體有一件事很有意思，就是大多數砸大錢發展開放源碼軟體的公司，並不是突然愛上言論自由放棄資本主義，而是認為這是個好的商業策略。 _{p. 295}

不論是專屬軟體還是開放源碼軟體，除錯絕對不會是免費的。 _{p. 297}

Chapter 41 莫菲定律發威的一週

當你向某家其實只是把服務外包的公司購買服務時，這樣隔了一層，是很難會有好的客戶服務。如果外包在外包出去，就幾乎無服務可言了。 _{p. 307}

也許這是目前公司 CEO 堅持不與 Google 的台灣在地經銷商簽約的原因了。

脆弱的系統可能表現完全正常，等到相鄰的系統故障時就會出事。 _{p. 308}

Chapter 42 微軟如何輸掉 API 戰爭

大家會買作業系統的原因，是因為可以執行有用的應用程式。因此，最有用的作業系統就是擁有最有應用程式的作業系統。 _{p. 310}

由此可合理推出一個結論，如果你想要販賣作業系統，最重要的就是讓軟體開發者願意替你的作業系統寫軟體。 _{p. 310}

iOS 其實就是這樣崛起的，現在 Apple 想用相同的 CPU 架構，讓 iOS 上的應用在 macOS 上執行，同樣的套路。唯一的差別是，Apple 不賣作業系統。

大家是為了要執行應用程式才買電腦的，而 Windows 好的桌面應用程式比麥金塔多太多了，所以很少人願意成為麥金塔的用戶。而這正是 Windows API 成為微軟珍貴資產的原因。 _{p. 311}

今年農曆新年最後自己組裝一台電腦，而不是選 Mac studio，原因是用模擬模式玩遊戲真的不太行... 但 WWDC 的展示 (我覺得就是官方支援的 Wine)，也許之後我真的可以告別 Windows 電腦了。

Windows 測試團隊非常巨大，而他們最重要的責任之一，就是要保證不論裝了什麼程式，每個人都要能安然無事地升級作業系統 ……… 事實上，如果你在登錄資料庫的 AppCompatibility 區到處看看，就會看到一大堆需特別處理的應用程式，Windows 會模擬各種舊問題和古怪的行為，讓這些程式能繼續執行。 _{p. 313}

老實說這點我是蠻佩服的，很多老遊戲確實也因為這樣在新的 Windows 仍然可以玩。

另一個陣營我稱之為「MSDN 雜誌陣營」，是以某一本開發人員雜誌來命名，這本雜誌充滿了讓人興奮的文章，都在教你用各種在自己軟體裡結合微軟產品的神祕方法來害死自己。 _{p. 314}

Windows 開發的複雜困擾了外界的開發人員，他們被微軟整個平台打敗了，因此，轉往 Web 平台了。 _{p. 316}

我個人不認為轉往 Web 的主因是微軟失去向後相容的信仰 (這一節的標題)，它是原因，但不是主因。

物件導向程式設計是很方便的好東西，但並不能像它所承諾地大幅提升生產力。真正讓程式設計人員大幅提升生產力的，其實是那些會替你自動管理記憶體的程式語言。 _{p. 317}

所以 Web 使用者介面已經有 80 分了，即使不仰賴新的 Web 瀏覽器，還是有機會達到 95 分。這對大多數人來說已經夠好了，當然對開發人員來說也夠了，而且他們也經把幾乎所有重要的新應用程式，都寫成 Web 應用程式了。這表示微軟的 API 突然間已經不那麼重要了。Web 並不需要 Windows。 _p.324

Part 4 對於 .Net 有點多的評論

Chapter 43 微軟瘋了

有時候這些聰明的思想家就是停不下來，一直創造出荒唐又無所不包的高層次宇宙景象，這些東西什麼都好，就是沒有實際的意義。 _{p. 331}

他們努力了幾近十年，試圖讓客戶同意以訂閱的方式購買軟體。不過這是行不通的，因為客戶並不想要這種模式。 _{p. 333}

Chapter 44 我們的 .Net 策略

我承認，.Net 違反了絕對不要從頭重寫的規則。但微軟有兩個條件可以這樣做。首先，他們擁有全世界最好的程式語言設計者，過去 20 年間軟體開發的生產力提升，有九成都是這個男人貢獻的。他是 Anders Hejlsberg ……… 其次是他們有本錢投入了無數工程師，花了三年時間來做這件事 ……… 記住，微軟可以做不表示你也能做。微軟創造他們自己的重力，正常的規則是對他們無效的。 _{p. 336}

Chapter 45 先生，可以賞我一個連結程式嗎？

我只是想把所有用到的東西連結成單一各靜態的執行檔，不用先安裝任何東西就能執行。 _{p. 341}

最近 Java 也推出類似的東西，讓 Java 應用程式可以更小更快地在雲端環境裡啟動，不用完整的 JRE 環境。

後記

這本書裡很多的內容是寫於千禧年世代，現在回頭看很多內容的發展方向已經大不相同，像是訂閱制慢慢開始興起，App 在手機上崛起，Web 大鳴大放，但讀起來還是很有滋味，很推薦給大家。