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

內容不少，所以還是拆成兩篇，還沒看過第一篇的，可以到 書摘《約耳續談軟體》 上篇 看。

Part 5 對程式編寫的忠告

Chapter 20 證據式時程安排

你投入一樣的成本，當然會想把時間花在收益最大的事情上。可是不知道事情要做多久，就算不出需要多少成本。 _{p. 165}

為什麼開發者不能訂出時程呢？原因有二。一、這是件很討厭的事情；二、沒有人相信時程是實際可行的。如果時程不正確，何必還要麻煩去編一個出來呢？ _{p. 165}

以敏捷的精神來說，預估的重點一直就不是在於準確，而是在於建立共識。

當我看到一個以天、甚至以星期來計算的時程，我就知道這個時程行不通。你必須把時程拆得很細，拆成能用小時來計算的任務。最長不能超過 16 小時。 _{p. 166}

不要直接把估計值累加起來算出上市日期，那種算法看起來正確，其實只會得出完全錯誤的結果。你要用蒙地卡羅法 (Monte Carlo method)，模擬出很多可能的未來。 _{p. 168}

想知道更多，可以讀《與熊共舞》。

另外，每一輪模擬都要去看最後才完成的開發者，因為那個人完成的日期，也就是整個團隊完成的時間。 _{p. 170}

這讓我想起《目標》一書中，提到的童子軍行軍的速度不是由走最前面的人決定，是走最後的那個人決定。

如果把功能分成不同的優先度後排序，就能輕易看出，消減低優先度的功能對時程有多少幫助。 _{p. 172}

Simplicity--the art of maximizing the amount of work not done--is essential. 當 PO 什麼都想要時，很難做到啊。

只有實際做事的程式員才能估計時程。任何由管理階層寫下時程，再交給程式員執行的系統，注定都會失敗。 _{p. 175}

在找到錯誤時立即修正，而且修正的時間要算在原本的任務上。 _{p. 175}

不要讓經理糾纏開發者讓估計時間縮短。 _{p. 175}

強迫自己選擇削減功能，可以讓你製作出更強大更好的產品，不但功能組合更加，而且出貨時間還能提前。 _{p. 177}

這很考驗產品經理的功力，沒弄好就是不成熟的半成品...

Chapter 21 策略書之六

90 年代後期，微軟和貧果等少數公司發現 (只是比別人早一點點)，摩爾地率意味著他們不應該太在意效能和記憶體用量...只要先做出酷炫的東西，再等硬體趕上就好。 _{p. 180}

花費許多工夫去最佳化程式碼，讓它緊密更快的開發人員，會在一覺醒來之後，發現這些努力可以說是白費了。 _{p. 181}

就長遠來看，忽略效能並拼命增加酷炫功能的開發人員，將會擁有更好的應用程式。 _{p. 181}

上面幾句我是認同，但個人覺得有幾個前提，第一，功能有真正地解決問題；第二，效能雖然不好，但要堪用，慢到太離譜還是會被頻繁客訴的。

Chapter 22 你的程式語言能這樣做嗎？

一旦把 map 和 reduce 視為任何人都能用的函數，而且大家也都在使用這些函數，只要找一個超級天才，把最困難的程式寫好，讓 map 和 reduce 函式能在巨大的全球電腦平行陣列上執行，那些只執行迴圈的就程式，全部還是能正常運作，只是速度快了非常多倍。 _{p. 191}

Chapter 23 讓錯的程式看得出錯

三種程式員的成就層級：

一，你不知道乾淨和髒有什麼分別。

二，你對乾淨有粗淺的認知，主要以市府符合編程規範為準。

三，你開始能秀出藏在表面下不對勁的蛛絲馬跡。你會察覺這是問題，並且找出來加以修正。

其實還有更高的層次，而且這也就是我真正要說的：

四，你有計畫地架構程式碼，藉助能察覺問題得靈眼，讓程式碼更正確。 _{p. 196}

這種讓錯誤程式看起來錯的作法有個前提，就是要讓對的東西在螢幕上緊靠在一起。 _{p. 203}

找出能讓錯誤程式看起來是錯的編程規範。讓正確的資訊集中在程式碼裡相同的地方，方便你看出某些問題並立即修正。 _{p. 205}

我是故意使用種類 (kind) 這個詞，因為 Simonyi 在他的文章中誤用了型別 (type)，結果好幾世代的程式員都誤解了他的意思。 _{p. 206}

應用匈牙利命名法非常有用，特別是當初 C 語言盛行，而編譯器尚未提供很有用的型別系統時。 _{p. 207}

這件是唯一的教訓是讓你知道，如果你寫出沒人能懂的艱深難解學術文章，你的想法可能會一再被誤解，結果變得非常荒謬，完全違背你的本意。 _{p. 208}

我沒有用過應用匈牙利命名法，只有在學 MFC 時，有用過約耳認為是錯的系統匈牙利命名法，當時已經是有 Visual C++ 的年代，確實覺得系統匈牙利命名法是脫褲子放屁，但自己的一些習慣確實接近應用匈牙利命名法。

Chapter 6 開創軟體事業

Chapter 24 ERIC SINK ON THE BUSINESS OF SOFTWARE 一書的前言

人們之所以喜歡成長中的企業，原因和喜歡園藝是一樣的。把種子埋進土裡，每天澆水，清除雜草，然後看著小苗長成巨大濃密的植物。 _{p. 217}

某一天，你會把「當有人買你的軟體就發電子郵件通知」的功能關掉。這是一個重要的里程碑。 _{p. 218}

Chapter 25 MICRO-ISV: FROM VISION TO REALITY 一書的前言

第一點：如果無法解釋以下的事情，就不要創立事業：他能消除什麼痛苦？替那些人解決？為什麼你的產品能消除這個痛苦？還有客戶怎麼會付錢解決這個問題？ p. 221

第二點：不要自己一個人創業。 _{p. 221}

第三點：一開始不要期望太高。 _{p. 221}

Chapter 26 飆出高音

軟體公司真正的目標，應該是把資本轉換成能用的軟體。 _{p. 223}

因為複製軟體不需要花錢，這表示程式員的成本會由賣出的所有軟體拷貝共同分攤。軟體可以提高品質，而不增加每個售出單位的成本。 _{p. 225}

基本上，設計增加價值的速度比增加成本更快。 _{p. 225}

工作品質與所用的時間根本沒有關聯。 _{p. 228}

不過，要說這些資料顯示出，程式員的生產力有 5~10 倍的差距，我不認為有什麼誇張之處。 _{p. 229}

協調溝通很花時間的，盡可能使用最小的團體，的確會有所助益。所以人越說法確實是種迷失。 _{p. 229}

使用很多平庸程式員來代替數位優秀程式員，真正的問題在於，無論他們工作多久，做出來的東西永遠比不上優秀程式員。 _{p. 229}

品味、快樂、情感訴求。這些就是在軟體產品、電影以及消費電子產品業界一鳴驚人的要素。即使你的產品把問題解決了，如果沒把這些東西做對，可能還是無法非常成功，也無法讓公司裡每個人都變成富豪。 _{p. 232}

Part 7 經營軟體業務

Chapter 27 超級辦公室

有許多證據顯示，形式正確的辦公空間，可以提高程式員的工作效率。私人辦公室的效果特別強烈。 _{p. 238}

有些超級明星的產能堪稱出色的程式員的十倍。當我們擁有非常華麗又有窗戶的私人辦公室時，在招募這種人才時會容易許多。 _{p. 238}

我絕對沒有在暗示什麼 XD

Chapter 28 巧婦難為無米之炊

我在這裡學到一個軟體架構上的重要經驗：你最重要、最關鍵的東西所依靠的工具，必須比想像中在低一個抽象層次。... 最關鍵的賣點在於最酷炫的 3D 繪圖效果。那麼你不會使用外頭找得到的 3D 程式庫。而是自己寫一個出來，因為這對你要做的事來說，實在太重要了。 _{p. 245}

簡言之，你要掌握核心的關鍵技術。

Chapter 29 簡單

當大家要求簡單時，究竟是什麼意思呢？當然是單鍵操作，不過，得具備他們最喜愛的所有功能。 _{p. 249}

製作簡單的 20% 產品，是一個很好得自行創業策略。因為你可以運用有限的資源，做出產品並且建立信徒。 _{p. 250}

這種方法雖然在自行創業時行得通，但是不能作為優良的長期策略。因為裡頭並沒有什麼東西，能防止另一家兩人新創公司，仿製你那簡單的應用程式。 _{p. 250}

在 Fog Creek 裡做過的所有事情中，就屬發行有更多功能的新版本，最能提高收入。完全沒有別的方法。 _{p. 251}

如果你用「簡單」來形容某個產品很容易使用，因為它得程式模型非常吻合使用者模型。很好，你抓到重點了。 _{p. 251}

但如果你認為簡單表示「功能不要太多」，或是「只做一件是而且做得很好」，那麼，我得稱讚你的正直，不過，這種刻意把功能拿掉的產品，是撐不了多久的。 _{p. 251}

Chapter 30 洗刷刷、洗刷刷

決定用三個星期，把程式碼完全整修一遍。洗刷刷、洗刷刷。我以重構 (Refactor) 的精神，為此行動列了一些規則：

• 不要加入新功能，連很小的功能都不會加。
• 提交 (check-in) 的程式碼必須隨時都能完全正常運作。
• 我只想做合乎情理的轉換。這些轉換必須是近乎機械式的反應，而且可以說服自己，不會因此改變程式碼的行為。 _{p. 255}

必要時，我隨時可以停下來推出產品。 _{p. 258}

Chapter 31 實施 BETA 測試的 12 項提示

開放式的 beta 測試行不通。你可能會得到太多的測試者，還有大量的測試資料湧入，本本無從處理，以至於得不到好的測試資料。 _{p. 259}

不要認為能在八到十周之內，完成一輪完整的 beta 測試循環。 _{p. 259}

不要把技術 beta 測試和行銷 beta 混為一談。 _{p. 261}

Chapter 32 邁向卓越客戶服務的七個步驟

幾乎所有的技術支援問題，都有兩種解決方法。表象而即時的辦法，只是為了解決客戶的問題。但是當你再多想一點，通常都會發現更深層，能讓該問題不再發生的解決方案。 _{p. 263}

技術支援人員必須能直接接觸開發團隊，這一點非常重要。這表示你不能把這件事外包出去。 _{p. 264}

每件事都用兩種方法修正的第二種含意，就是執行到最後，會把所有常見和簡單的問題都解決掉，剩下來的都是非常罕見的怪問題，。這是件好事。 _{p. 264}

當客戶遇到問題，而你把問題修好了，客戶的實質感受會比完全沒有遇到問題時更加滿意。 _{p. 267}

在這個星球上待了 40 年，我簡直不敢相信，「這是我的錯」幾個字竟然能在短短幾秒內，完全改變了我的情緒。 _{p. 268}

還有一點。你可能認為認錯是一個嚴重禁忌，有可能害你被控告。這是無稽之談。想避免被控告，就別讓人們對你發脾氣。而最好的辦法就是承認錯誤，並且解決那該死的問題。 _{p. 270}

和客戶吵架，你永遠不會贏。 _{p. 271}

許多稱職的人員會厭倦客戶服務的前線工作，我覺得這很正常。為了彌補這一點，我僱用這些人員之前，一定會安排好明確的職業前景。 _{p. 274}

Part 8 發行軟體

Chapter 33 選擇交貨日期

每次時程延誤時，就把不重要的功能砍掉，以確保出貨日期不變。 _{p. 277}

密集發行可以快速取得客戶的回饋意見。 _{p. 279}

如果只是為了「開始傾聽客戶」，就讓一套貧乏的商業程式上市，只會聽到這些客戶說：「這沒什麼用」。 _{p. 280}

開發過程中最困難的部分，就是要維持相容性。 _{p. 282}

如果你做了很多驗證和單元測試，而且在撰寫軟體時很小心，可能就會達到某種狀態。在這種狀態下，任何一版每日編譯的結果都有很好的品質，隨時都可以出貨。這當然是要努力達到的境界。 _{p. 282}

請記住可用性的基本原則：應用程式的行為，必須與使用者的預期相符，才算是好用的程式。如果你每個星期都在改變，程式的行為就沒那麼好預測，可用性也隨之降低。 _{p. 283}

Chapter 34 駱駝與橡皮鴨

錯、錯、錯。你並不是要讓賣的套數最多，而是要讓利潤最高。 _{p. 288}

這就是區隔 (segment) 的威力，你依照客戶願意支付的金額，把他們分成不同客群，然後由每個顧客身上，獲提最大的消費者餘額。 _{p. 293}

區隔雖然是個「擷取消費者餘額」的有用工具，但對產品長期的形象卻有相當負面的影響。 _{p. 296}

如果客戶互相交談，他們就會試著找出其他人拿到的價格，於是你會發現，自己不得不讓每個客戶都拿到最低價格。 _{p. 296}

你真的該關心的，是讓整體 (包括未來) 的收益最高。技術上來說，你要讓所有未來收益流入的淨現值 (NPV) 最大化 (而且現金儲備 (cash reserve) 必須一直為正值)。 _{p. 298}

這實在像個笑話。大公司想要保護自己，不要買到昂貴的東西，於是設架了重重障礙，以確保採購決不會出問題。結果卻讓昂貴商品的價格更高漲，由 1,000 美元增加為 75,000 美元。而增加的價錢，大部分都是用來克服他們自己所設下的障礙。 _{p. 300}

你可以安排焦點小組 (focus group) 並詢問人們，不過他們會撒謊。 _{p. 301}

於是當你詢問人們願意付出的價格時，每天得到的答案都完全不同，而且相差非常多。事實上，要確定有多少人會購買某物，唯一的方法就是拿出來賣，然後看有多少人真正出手。 _{p. 302}

只要曾經做過以人為對象的實驗，就知道結果變異極大，完全無法重現。要讓自己對實驗結果有信心，唯一的辦法就是小心翼翼地避免重做相同的實驗。 _{p. 302}

Part 9 修訂軟體

Chapter 35 五個為什麼

由於懲罰實在太低，所以很多網路供應商乾脆打廣告，聲稱提供 100% 的正常運行時間。 _{p. 308}

但是 SLA 也有一些問題。最大的問題是缺乏統計上的意義，因為停機的機率太低。 _{p. 309}

你必須要事先考慮到所有會出錯的地方，而這實在是不太可能達成的。真會造成大麻煩的，都是無法預期的意外，而不是那些可以想得到的狀況。 _{p. 309}

這幾年使用雲端的經驗，雲端出包時，那真的會是大災難，但跟客戶道歉的是我們...

極高的服務可用性 (availability) 代價非常昂貴。眾所周知的「六個九」服務可用性 (99.9999% 的正常運行時間)，相當於每年停機時間少於 30 秒。 _{p. 310}

黑天鵝是個孤立點，是一個超出正常預期領域的獨立事件。 p. 310

測量每年停機時間的分鐘數，並不能預測明年的停機時間。 p. 310

經過內部討論，我們都同意，不應該實施在統計上無意義的測量，卻希望這種無意義的數字能改善現況。我們真正需要的，是一個持續改進的程序。我們決定不為客戶設立 SLA，而是建立了一個部落格，及實際記載每一次的斷線事件，並且提供完整的事後檢討。 _{p. 312}

作者的產品使用對象是工程師，我覺得這樣確實很好，但不是每種產品使用者都想看這樣的內容...

Chapter 36 安排你的優先順序

請容我先談談兩種不要排序的方法。第一種：如果發現自己只是因為大應某個客戶，才去時做某個功能，腦袋裡應該要自動亮起警告的紅燈。 p. 313

客製化開發是個曖昧不清的世界。 _{p. 314}

介於客製化軟體和熱縮封膜軟體之間的是顧問軟體，你假裝自己正在做熱縮封膜軟體，實際上卻在進行客製化的開發。 _{p. 314}

如果你覺得讓最大的客戶「點菜」指定功能，是配製開發資源的最佳方式，那就去做吧。不過，你很快就會發現，有錢的大客戶所要的功能，和大眾市場所需的功能大不相同。 _{p. 316}

不必決定時做那些功能的第二種方法。就是不要只因為事情無法逃避而去做。無法逃避這種理由並不充分。 _{p. 316}

「重要」並不是非黑即白的二分法，而是應該具有類比 (analog) 的特性。所謂的「重要」，會有各式各樣不同的層次。如果你每件事都想要做，那麼什麼事都做不了。 _{p. 318}

這一章最後的排序方法其實很好，但很難擷取成幾句話，我推薦去買來看。

後記

第一次看這本書時，後面幾個章節其實比較無感，畢竟那時還是無憂無慮的學生，頂多擔心自己的資格考會不會沒過。但工作幾年後再回來看這幾個章節，真的是超級有感，點頭如搗蒜，是一本很有趣的好書，推薦給大家。