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

這本書和《約耳續談軟體》，以及 Teddy 學長的《例外處理設計的逆襲》，應該算是我開始想寫技術部落格的原點吧，這幾本書都是原先的網路文章，最後收集成書。中文翻譯本原本應該是絕版書了，最近看到另一個出版社重新取得授權出版 (譯者也換人了)，於是又把這兩本書從書架上拿下來拍拍灰塵 (笑~)，看看當年畫的筆記，也挺有意思的。

Part 1 位元和位元組：程式設計實務

Chapter 1 選擇一種語言

當我們需要一套能在 Mac、Windows 和 Linux 上執行的 GUI 時，最常選擇的是 Java。雖然得到的 GUI 不盡完美，畢竟還是個能用的語言。 _{p. 3}

這可能是作者少數關於 Java 的正面說法，後面應該就沒了。文章發布於 2002 年，當時用 Java (AWT/Swing) 開發出來的 GUI 確實很醜，但後期 JavaFX 進步很多，在水果公司我就是用 JavaFX 做了跨平台的精美產品。

其實，我很少基於語法來選擇程式語言。我承認自己喜歡用「{};」的程式語言。 _{p. 4}

握手，我也是 (突然發現不能用英文版本 XD)

.Net 似乎提供了多種語言供我們「選擇」，但是可以選擇的卻是我們不太在意的—— 語法。 _{p. 4}

Chapter 2 回歸原點

我認為人們所犯的嚴重錯誤，雖然是錯在最高的架構層，但追根究底下來，原因在於不夠瞭解或想錯某些最底層又簡單的事情。 _{p. 5}

當你發現某件事應該要有線性效能，實際上卻是次方級的表現，就要尋找隱藏的 Shlemiel。它們常常躲在你的程式庫裡。看著一長串的 strcat 或是迴圈中的 strcat，並不會讓你立即喊出「n次方」，不過，兇手就是它了。 _{p. 8}

Shlemiel 是誰就留給大家去找書來看吧！

總而言之，在這往下到最底層的位元組世界中，生命只會變得愈來愈亂。是不是很慶幸不再需要用 C 語言寫程式呢？ _{p. 13}

我認為電腦科系一年級學生應該由基礎開始學起，使用 C 語言，並由 CPU 開始一路建立觀念，這才是最重要的。很多電腦科系的課程編排認為 Java 很「容易」，不會被無聊的字串或記憶體配置搞得暈頭轉向，又能學習酷炫的物件導向技術，將大程式變得更模組化，所以很適合當作入門學習的電腦語言。但我對這種想法非常反感，這是一個醞釀中的教學災難。 _{p. 15}

不知道作者到 2023 年的現在還是一樣的想法嗎？作為本科生，特別是大學還學過如何設計 CPU 指令集與電路的我來說，不是不能理解作者的想法，但目前多數的應用，到底是開發時程重要還是效能優化重要呢？或 DX 才更重要呢？

Chapter 3 約耳測試：邁向高品質程式碼的 12 個步驟

一般來說，愈晚修正錯誤，修正時所付出的成本 (時間及金錢) 愈高。 _{p. 21}

擁有時程的另一個重點是，可以強迫自己決定要製作那些功能，並剔除最不重要的功能，以避免功能過度膨脹 (featuritis 又名 scope creep)。 _{p. 23}

這一點其實很難說，我有遇過時程迫在眉睫，仍活在自己的世界中的工程師。

我不知道原因，或許是大多數程式設計人員都討厭寫文件吧！ _{p. 23}

斯斯有兩種，文件也有很多種，所以當有人說程式即文件，或是測試案例即文件時，拜託，請先想想讀者是誰？讀者不是只有工程師，也不是每個人都能讀 given-when-then 然後還能想像出整個使用情境。

我們都知道知識工作者進入「沉浸狀態」(flow，也稱作 in the zone) 時，工作效果是最佳的。這時他們會完全與環境脫離，全心專注在工作上。他們忘記時間並絕對專注地產出極佳成果。 _{p. 24}

另一個問題就是沉浸不容易維持。噪音、電話、同事的中斷 (特別是這一點) 都會讓你脫離沉浸。 _{p. 24}

我已經很少有辦法進入沉浸狀態了...

一流的開發團隊並不會虐待他們的程式設計人員。工具不佳所引起的挫折感雖然很小，累積起來還是會讓程式設計人員心情超級不爽。 _{p. 24}

Chapter 4 每個軟體開發人員絕對要會的 Unicode 及字元集必備知識

所謂的「純文字 = ASCII = 字元都是 8 個位元」的說法不僅不正確，還錯得離譜。 _{p. 32}

我只想拜託，不要再把中文字視作兩個字了，特別是設計輸入長度限制時...

有些人誤認為 Unicode 只是個 16 位元碼，裡面的每個字元都要佔掉 16 位元，所以總共有 65,536 個字元。事實上，這並不正確。這是 Unicode 的常見誤解，如果你也這麼認為的話，不用太難過。 _{p. 36}

不知道實驗室裡那本 Unicode 5.0 大頭書還在不在，不知道是哪位學長留下來的，我沒翻過那本書，只知道是很厚的一本書，對它充滿敬畏...

根本就沒有純文字這種東西。 _{p. 40}

假設你有一個字串，不管在記憶體或在檔案中，還是在電郵訊息裡，你都必須知道字串用的編碼方式，才能正確解譯出來，並呈現給使用者。 _{p. 41}

這一章蠻推薦大家讀的，以幽默的方式講解字元集的歷史。

Chapter 5 無痛功能規格 Part 1：何必麻煩呢？

規格最重要的功能是要設計程式。 _{p. 45}

希望我沒誤解作者，但自己個人經驗，寫文件真的是在幫助自己做設計。

天字第二號理由是「節省溝通時間」。當你寫了規格之後，對於程式應有的作用就只需要講解一次，團隊裡其他人只要讀規格就好了。 _{p. 48}

寫規格的天字第三號理由，就是「沒有詳細規格就無法訂出時程」。 _{p. 49}

以敏捷的角度解讀這句話，沒有 AC，團隊無法進行有意義的預估。嗯，這樣解讀比較好...

在很多程式開發組織中，出現設計爭議時，總沒有人願意作出決策 (通常都是因為一些「政治理由」)，所以程式開發人員只去作那些沒有爭議的項目。當時間消逝，所有困難的決定都會壓到最後才決定。這些專案很可能會失敗。 _{p. 50}

Chapter 6 無痛功能規格 Part 2：規格是什麼？

功能規格純粹由使用者的角度來描述產品如何運作。它不管東西是如何做出來的。……… 技術規格則是描述程式內部的實作。 _{p. 53}

恕我不敬，你的規格可能總是過時又不能反映產品現況，不過，我的規格可是時常更新。只要產品還在開發又有出現新的決策，我就會持續進行更新。 _{p. 65}

中間跳過一大段，但卻是很值得找來讀的一段。

Chapter 7 無痛功能規格 Part 3：不過…要怎麼做呢？

這本書 (《人月神話》) 的主要重點是，在進度落後的專案中增加更多程式設計人員，只會讓進度更加落後。這是因為當團隊有 n 位程式設計人員時，溝通路徑的數量會變成 n(n - 1)/2，也就是以 O(n²) 增加。 _{p. 67}

關於我對《人月神話》的心得可參閱書摘《人月神話》。

自此至今，微軟的產品經理就是在蒐集需求、定義程式應有作用並且撰寫規格。 _{p. 68}

我個人是蠻懷疑這句話是否還成立。

下面列出必須避免的三件事。 _{p. 69}

• 不要把程式設計人員升為產品經理
• 別讓行銷人員擔任產品經理
• 別讓程式人員對產品經理報告

我也可能堅持己見，獨斷短視地命令他們照我的方式進行；但這樣做的話，就沒有機會建立共識。而凝聚更是決策行事卻是做對的事情的最好方式。 _{p. 70}

Chapter 8 無痛功能規格 Part 4：提示

在有寫規格的團隊中，最大的抱怨就是「沒有人在讀」。 _{p. 71}

可是對人們來說，一定要先有動機才會瞭解你在講什麼。人們不會想被迫解讀某些東西，他們只想循序閱讀就能理解。對人們來說，你必須先提供整體概念才能填補細節。 _{p. 75}

千萬不要覺得簡單句子不夠專業，就使用誇大的正式語句。其實，寫得愈簡單愈好。 _{p. 75}

規格四：審閱多次並重讀幾遍 _{p. 77}

規格五：使用樣板是不好的 _{p. 77}

我的建議是「看起來一樣」並不重要。這會有什麼差別嗎？你家裡書架上的每本書都長得一模一樣嗎？難道你希望他們一樣嗎？ _{p. 77}

我終於找到了，之前公司在討論公司文件格式樣板時，我是少數反對的人，但當時忘記在哪看過類似的觀點。

Chapter 9 無痛軟體時程

明知道排出來的時程不準確，為什麼還要費心去做呢？大家都認為時程一定是錯的，而且時間過得愈久錯得愈離譜，何必白費功夫呢？ _{p. 80}

為什麼呢？這題是有有意義的答案喔。

把工作指派給不同的人。這就軟體開發來說完全行不通，程式設計人員是不能互換的。 _{p. 81}

有人可能會說，但敏捷鼓勵開發人員自己認領工作啊，是，但上面那句話是在傳統時程管裡的 context 下說的。

大部分程式設計人員並不知道如何估計工時，這也無妨，只要持續學習並隨時更新時程，時程就會確實作用 (你可能必須削減功能或延期，不過，時程本身還是能運作無誤，它只會一直提醒你該刪減功能或是必須延期了)。 _{p. 83}

麻煩的是遇到不願刪減功能也不願延期的人。

修正錯誤就像科學活動，不可能估計何時能發現並解決問題。 _{p. 85}

你或許可以懇求員工不計辛勞超努力工作，提高 20% 的新程式碼產量。砰！可惜除錯時間倍增了，真是瞭不起的自爆蠢方法。 _{p. 87}

Chapter 10 每日編譯是你的好朋友

這標題以 2023 年的標準，其實有點低，但如果你待的公司做不到，那請趕快跑。

這裡有個重要的觀察結果，就是寫程式時會一再重複這個循環，所以「編輯」→「編譯」→「測試」的循環進行得愈快，就愈有生產力，最快時就是能瞬間完成編譯。 _{p. 93}

如果每日編譯失敗，就要冒險停止整個團隊的作業。全部動作都停下來重新變異，直到問題修正為止。 _{p. 96}

有點懷念之前在水果公司，每當編譯或測試失敗時播放的：「阿尼你又掛了」的經典音效。

Chapter 11 絕不妥協的抓蟲行動

錯！只有當修正問題所得到的價值，超過修正所花的成本時，修正問題才是件重要的事。 _{p. 99}

當人們讀到這種文章，難免會得出類似的蠢結論：約耳不認為需要修正問題。事實上，我認為大多數修正好的問題，都有很明顯的回報。不過與其修正所有問題，或許去做其他事情反而能獲得更高的金錢回報。 _{p. 104}

我個人很有感。

Chapter 12 五個世界

我認為在這裡有五個世界： _{p. 106}

• 熱縮封膜 (Shrink-wrap) 軟體
• 內部用軟體
• 嵌入式軟體
• 遊戲軟體
• 用過即丟軟體

雖然這些軟體 (熱縮封膜軟體) 的使用者數量眾多，不過，通常都有替代商品，所以使用者介面必須比其他商品更容易才會成功。 _{p. 107}

或是更便宜... 這通常是最不希望競爭對手做的事。

對內部用軟體來說，其可用性並不重要，因為需要使用這些軟體的人並不會太多，而這些人沒有其他選擇也只能將就。 _{p. 109}

實際上，內部用軟體與熱縮封膜軟體有一個關鍵性的差異：內部用軟體在開發到某個程度之後，就不值得再投入資金，讓軟體更穩定或更好用。 _{p. 109}

這種軟體 (嵌入式軟體) 有個特性，它會被放在硬體裡而且幾乎無法更新………由於沒有第二次機會，因此，品質要求會比平常高出許多。_{p. 110}

我對此抱持高度懷疑，也許是現在都可以更新了，品質真的是...

遊戲軟體自成一類有兩個原因。首先遊戲開發的經濟學是打擊型。有些遊戲擊出安打，但更多的是三振 _{p. 110}

Chapter 13 紙上原型製作

紙上原型比任何用軟體做的原型都便宜多了，甚至可以進行真正的可用性測試，只要準備好紙、鉛筆、簡單和好用的橡皮擦。 _{p. 114}

當設計師以完稿品質在進行原型製作時，打掉重來的成本很高，但很多公司都這麼做... 所以，要嘛花很多成本，要嘛就略過可用性測試...

Chapter 14 別讓架構太空人嚇到你

當一直往上把事情弄得太抽象，就會像上太空一樣缺乏氧氣。 _{p. 115}

我並不是說這些架構有什麼問題。他們都是相當好的架構。讓我受不了的是圍繞在架構周圍那些驚人的超級宣傳。 _{p. 116}

Chapter 15 邊開火邊移動

只要一直前進，持續地寫程式並修正錯誤，時間就會站在你這邊。 _{p. 121}

對於我這種小公司，邊開火邊移動有兩個含意。你得爭取時間，而且每天都要往前進，遲早你會獲勝。 _{p. 122}

Chapter 16 工匠技藝

寫程式並不是量產，也不全然是工匠技藝 (雖然可以是)，它是一種設計。而設計是一種價值比成本增加得快的模糊區域。 _{p. 125}

當軟體是由真正工匠製作時，所有螺絲都會對的整齊劃一。…… 工匠技藝當然是非常昂貴的。 _{p. 129}

Chapter 17 電腦科學中三個錯誤的想法

可靠的軟體在使用網路時，絕對都得考慮這些問題 (可用性、延遲、可靠性)。而程式設計介面把這些都隱藏起來，對寫出爛軟體來說，真是助益匪淺！ _{p. 135}

Chapter 18 雙文化主義

UNIX 文化重視對其他程式設計人員有用的程式，而 Windows 文化則重視對非程式設計人員有用的程式。 _{p. 137}

UNIX 的程式文化格外重視可由命令列呼叫的程式，這種程式可以用參數控制各種動作，其輸出可以擷取成一般機器可讀的純文字格式。這種程式之所以會被重視，是因為可以讓其他程式設計人員輕易地整合進別的程式或較大的軟體系統中。 _{p. 138}

我在大一時曾跟一位推崇 Linux 的學長進行辯討論命令列是多麼的不友善...

典型的 UNIX 文件會寫得簡潔而完整...，這種風格假設讀者非常積極，可以自行推導未寫出的結論，並且有自信地信任這些推導。 _{p. 140}

我只好承認我不積極，覺得 UNIX 指令的文件很爛...

Chapter 19 由用戶端取得當機報告，一切全自動！

通常在測試實驗室裡永遠抓不到這種問題，因為我們無法重現客戶可能傭有的各種怪異 PC 組態。 _{p. 145}

於是我發現，其實不必收集這種資訊，只要知道當機時確切的程式碼行數，就足以解決幾乎所有的當機問題。 _{p. 147}

我怎麼突然想起 UberEat 最近的廣告，應該都買得到...

如果開發的是供企業內部使用的軟體，自動當機回報的效用可能不大。企業軟體通常是以遠高於現成軟體的代價來解決特定問題。一旦問題解決，就不值得未該特定專案花更多錢。 _{p. 153}

小結

突然發現，這篇已經非常長了，剛好，Chapter 19 是書中第一部的最後一章，我就把書摘分成多集，讓這一篇停在這裡，我會持續更新後面的部份的。

後記

在導讀中作者自己提到，這本書非常的主觀，一直被迫刪除每句話開頭的「我認為」，好讓文章更為簡潔。事實上自己寫的文章也是如此，畢竟不是在寫學術論文，所以不論是這篇書摘，或是我的文章，切記，這都是我的主觀認知，看完後應該要有自己的想法，不要照單全收啊！ (投資理財有賺有賠，申購前請詳讀公開說明書...)