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

閱讀時間約 15 分鐘
raw-image
內容不少,所以還是拆成兩篇,還沒看過第一篇的,可以到 書摘《約耳續談軟體》 上篇 看。

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

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

後記

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

Spirit
Spirit
在業界打滾多年,本來想開發遊戲,想想還是打遊戲比開發遊戲輕鬆,曾想當敏捷傳教士,但後來發現,好的產品品質跟健全心態的團隊比用什麼流派重要,所以,這幾年比較隨心所欲,但不隨波逐流,仍想做出值得驕傲的好產品。
留言0
查看全部
發表第一個留言支持創作者!
Spirit 的其他內容
書摘《約耳趣談軟體》 上篇
閱讀時間約 14 分鐘
《鳳凰專案》讀後感
閱讀時間約 6 分鐘
書摘《約耳趣談軟體》 下篇
閱讀時間約 14 分鐘
《人月神話》讀後感
閱讀時間約 3 分鐘
書摘《約耳續談軟體》 上篇
閱讀時間約 17 分鐘