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

用 Google 找此書的封面，意外找到我還在痞客邦時的舊文章，裡面滿滿的就回憶，主要是研究所到遊戲橘子這段時間的雜記之類，這本書其實讀過很多次，最早是從學校圖書館借出來看的，後來趁出版社兩本書套裝優惠時就買回來收藏，那時又看了一次，這次為了寫書摘再看了一次，真的是很有趣，最近換出版社重新翻譯出版，有興趣的是可以買回家收藏喔。

Part 1 人員管理

Chapter 1 我的 BILLG 審查初體驗

其實 Bill 並不是真的要審查你的規格，他只是想要確認你能掌握規格。他的標準做法就是愈問愈難，直到你投降承認不知道，然後就可以大罵你準備不足。沒人知道他最難的問題過關之後，會發生甚麼事，因為史無前例。 _{p. 8}

這裡的 Bill 指的比爾蓋茲。

這似乎並不能解決那 11 層管理層所帶來的難解問題，還有那沒完沒了、永無止境的會議文化，以及不顧一切想創造所有可能產品的頑強固執。而二十年來，草率快速的人員聘用過程，也讓微軟員工的平均腦力一路下降。 _{p. 9}

Chapter 2 尋找優秀的開發人員

優秀的軟體開發者根本不會在人力市場上出現。 _{p. 11}

平均來看，優秀的軟體開發者在整個職業生涯中，可能只應徵過四個工作。 _{p. 11}

哇~ 我已經用掉四次了，之後只能靠別人找我了 XD

可靠而能幹的人。在人力市場裡，這族群的人數比優秀人才更多，但比不稱職的人少，以整體來看，在你那一千份履歷中只算是少數。 _{p. 13}

有些招募經裡很討厭雇用實習生。他們認為實習生不成熟且技術不足，就某種程度上來說是事實。實習生並不如有經驗的員工那麼熟練 (不，很難說吧？！)，你得先對他們多投資一點，得要一些時間才能讓他們跟上節奏。不過，在我們這個裡愈有個好處，就是真正優秀的程式員通常十歲就開始寫程式了。 _{p. 15}

我個人是喜歡實習生的，只是要安排人帶實習生。10 歲... 我應該只會用倚天系統和玩 DOOM 吧！13 歲才開始寫程式... 難怪不夠優秀 XD

也就是說，從事軟體開發這一行與法律或醫學領域不同，這些孩子們在他們大學二年級或三年級時，就已經是個很不錯的程式員。 _{p. 16}

所以我們為他們安排實際的工作——相當困難的工作。我們的實習生向來都要處理正式上線的程式碼。有時，他們還會處理全公司最酷的新東西，連長期僱員都會有點嫉妒，不過這就是人生啊。 _{p. 17}

平均起薪必須考慮到新人試用失敗的風險。可是我們已經讓這些孩子預演過了，並不會有不夠優秀的風險。我們知道他們的本事。 _p.18

我只是想開始和新一代優秀程式員建立關係，雖然這會成為一個為期6年的超長管道。我的眼光可是很遠的。 _{p. 19}

任何神智清醒的程式員都不應簽訂競業條款，不過，大部分人都會簽，因為他們永遠不會想到真的會強制執行，或是因為他們沒有閱讀合約的習慣 _p.21

我也認為這條款不合理，但幾乎所有科技公司都有這一條款

Chapter 3 開發者實戰指南

《Peopleware》是一本偉大的書。書中最重要且最受爭議的主題在於，如果希望程式員有生產力，就必須給他們大而安靜的空間 (可能就是私人辦公室)。 _{p. 23}

我個人雖然不排斥 open space，但真要我選，我還是喜歡獨立的空間，有個白板，可以自由地走動思考... 但實務上大概只有主管才有這種空間

如果其他條件都相同，開發者會選擇一個把自己當明星的組織。 _{p. 29}

經理可以建議，大家也樂意聆聽。不過，他們得格外小心別讓自己的「建議」被解讀為命令，因為對任何特定的技術問題而言，管理階層所知道的都不如現場的工作人員，如果你聘用優秀人才時更是如此。 _{p. 30}

開發者希望是因為自己的技術受雇並被視作專家，並且與許在自己專精領域內做決策。 _{p. 31}

大多數程式員並不是在找一份用來付房租的表演。他們不是要一份單純的工作，而是希望自己的工作室有意義的。 _{p. 34}

我以前覺得是，但這幾年我開始問為什麼你想當軟體工程師了... 這題如果回的不太理想，通常也不會是優秀的工程師。

身為招聘人員，你的工作就是找出貴公司的理想面，並確保能讓面試者知道。 _{p. 34}

如果以前從來沒有聽到抱怨薪資，現在卻突然開始有了，這通常是一個跡象，表示人們並不真正熱愛自己的工作。 _{p. 35}

這邊我要幫員工說句話，通常會開始在意薪資，在台灣，很有可能是想買房子或是開始繳房貸了 XD

Chapter 4 三種管理方式 (導論)

如果你想要領到一個團隊、一家公司、一支軍隊，甚至是一個國家，首要問題就是讓大家都朝著同一個方向前進。這話說得很客氣，意思就是「讓別人做你想要的事」。 _{p. 37}

反向解讀：主管失敗的地方，讓大家做不想做的事 (只有你想做的事)

Chapter 5 指揮與控制管理法

首先是人們並不怎麼喜歡，至少自認聰明的軟體開發者都不愛這套，畢竟他們是真的很聰明。 _{p. 40}

指揮和控制有個更實際的缺點，管理階層並沒有那麼多時間，可以實行這麼細微的枝節管理 (micromange) _{p. 40}

這種打了就跑的枝節管理，問題在於持續的時間太短，無法看到自己決策的結果究竟對還是錯。 _{p. 40}

高科技公司中個別貢獻者的資訊，一定比「領袖」更多，所以這些人才是做決策的最佳人選。 _{p. 40}

很想說些什麼，但很多主管很愛這一套啊~ 還是別說太多吧，只能期許自己別變成這樣的主管。

尤其當軟體開發團隊裡的成員很優秀，在哪裡工作都可以時，扮演士兵只會讓他們非常厭煩，結果團隊裡完全留不住人。 _{p. 42}

Chapter 6 經濟學 101 管理法

這個作法有個大問題，就是內在動機會被外在動機取代。內在動機是你自己想把事情做好的渴望。 _{p. 44}

經濟學 101 管裡的另一個大問題在於，人們習慣找出局部的最大值。他們會找到某種方式，讓你所給予的東西極大化，而不是真正達成你要的結果。 _{p. 45}

當你使用經濟學 101 管理法時，其實是在鼓勵開發者去玩弄系統。 _{p. 45}

開發者可能不擅長找出自己開發的 bug，但很擅長找出別人的問題 (笑~)。

開發人員就是這麼的聰明。無論你嘗試測量什麼，他們都會找到方法最大化測量結果，而你永遠不會完全得到你所要的。 _{p. 46}

KPI 或 OKR，別太認真，開發人員都知道上面在想什麼... (非開發人員其實也...)

Austin 博士的結論是你絕對做不到，這種方法永遠無法奏效。不管如何努力地調整測量指標來反映你認為需要的成果，最後一定會有反效果。 _{p. 46}

Chapter 7 認同管理法

目標是要讓大家認同你想達到的目的，並且利用者種認同進行管理。這比其他方法都棘手得多，而且需要某些強力的人際關係技巧才能達成。 _{p. 49}

你必須使盡所有的社交技巧，讓員工認同組織的目標，讓他們擁有強烈的動機，還要提供足夠的資訊讓他們駛向正確方向。 _{p. 49}

這和 書摘《全員敏捷》裡面提到的很多概念是不謀而合。

Part 2 給未來程式員的建議

Chapter 8 Java 學校帶來的危害

我真正想說的是，Java 這個程式語言整體來說不夠困難，無法用來區分出優秀或平庸的程式員。他或許是個還不錯的語言，不過今天不談這個。我甚至會說 Java 不夠難是個特色而非錯誤，但他的確有這個問題就是了。 _{p. 55}

我想現在約耳對於 JavaScript，或是 Swift 或是更新的語言，他恐怕也是這樣說的。我個人覺得，一個很難的語言適合磨練心智，但不適合開發大多數 Web 與 app 的產品。我最擅長與偏好的語言是 Java，但很感謝北科資工選擇 C++ 與大量作業給我紮實基礎，這樣說可能更適合總結這章的內容。

不懂指標就永遠不能接觸 Linux 核心。如果不能真正理解指標，你就無法讀懂任何一行 Linux 核心，事實上，對其他作業系統也是一樣的。 _{p. 58}

真正會接觸到 Linux 核心的工作是不少，但不用接觸到指標的工作更多，就看個人的選擇了。當初研究所在看 Linux 的 TCP/IP 相關實作時，確實需要懂指標。

指標和遞迴需要相當的推理能力和抽象思考，而且最重要的是，要能夠同時由多個不同的抽象層級來觀察問題。因此，理解指標和遞迴的能力，與成為優秀程式員的能力有直接的關聯。 _{p. 59}

個人覺得，工作這麼多年，我覺得能聽懂非技術人員說的話也是重要的能力。別笑，還真的很多人沒這項能力。

Chapter 9 在耶魯大學的演講

你會一次又一次地看到程式員重新定義問題，好讓問題有系統地解決。問題在重新定義之後，往往會變成另一個可以解決的小小問題。他們不會去解決原本的問題，因為問題本身非常棘手。 _{p. 66}

西裝客知道修正錯誤的效益是遞減的。只要軟體能到達某種品質等級，能解決某人問題，讓他願意付，自己能從中獲益就可以了。 _{p. 66}

事實上你將會看到，死硬派的技術狂通常會放棄各種有用的品質衡量方法，只留下一件能機械式地證明的事情，也就是程式的行為是否遵循規格。 ^{p. 67}

寫出完整規格是不可能的，因為必須像電腦那樣思考，才有辦法針對所有出錯的可能，寫出對應的規格。

這是矽谷式的管理風格。經裡的作用是把擋路的家具移開，讓真正的天才做出亮麗的成果。 _{p. 73}

我注意到在微軟哩，真正好的產品經理都有很好的寫作能力。 _{p. 77}

Chapter 10 給電腦科系學生的建議

假如你喜歡寫電腦程式，恭喜你，你是少數能從事所喜愛的工作的幸運兒。大部分的人都沒這個福氣。 _{p. 80}

平庸程式員和優秀程式員之間的差別，並不在於他們會多少種語言，也不再於他們喜歡 Python 還是 Java。重點是能夠和他人溝通自己的想法。優秀的程式員藉由說服他人而獲得影響力。 _{p. 81}

如果你有能力寫作，不論是在何處工作，很快就會發現自己會被要求寫規格文件。這意味著你已經發揮自己的影響力，還讓管理階層注意到你了。 _{p. 81}

寫程式也有無聊的事情。每個工作都有無聊的時候，我才不會請一個只想做好玩事情的人呢！ _{p. 84}

Part 3 設計的衝擊

Chapter 11 字型平滑化，去鋸齒與次像素渲染

在大多數與品味相關的問題上，只要調查偏好就會發現，大多數人並不真的知道該如何選擇，於是就會選擇似乎最熟悉的一種。這個原則由銀餐具到字體，甚至圖形設計都適用：除非人們受過訓練知道如何挑選，否則就只會選出最熟悉的。 _{p. 93}

這其實不是件壞事，使用者可以透過熟悉的事物快速學習一個新的應用程式。

Chapter 12 逐吋的競賽

當你解決了越來越多的細節，當你把產品的細微處擦亮，細心修潤病磨出光澤，就會發生某些神奇的事。 _{p. 98}

還記得之前在遊戲橘子的時候，我們的部門每兩周就有一次 polish 的活動，試著找出產品不好的地方然後改進。

Chapter 13 大局觀

這個機制有一個不幸的副作用，它會讓大腦養成壞習慣，以為自己能很有條理地理解試務。它總以為自己認得清大局，其實有時候什麼也沒有。 _{p. 100}

我最受不了的就是那種養成壞習慣，只要事情不知道該怎麼做，就要開會的團隊。 _{p. 101}

你用隱喻來讓使用者了解你的程式模型。當你讓外觀、感覺，還有行為 (這是最重要的)，都像現實世界裡的物品時，使用者就更有機會知道該如何使用，而這個應用程式也就更容易操作了。 _{p. 103}

Chapter 14 選擇=頭痛

你提供愈多的選項，人們就愈難選擇，於是就覺得愈不快樂。 _{p. 106}

事實上，開發者為了確保這些選項的排列組合都沒有錯，更不快樂。

這突鮮了微軟和開源運動共有的一種軟體設計風格，這兩者都希望能達成共識，也都想要讓每個人都快樂，但卻都基於「很多選項讓人快樂」這個需要重新思考的錯誤概念。 _{p. 108}

Chapter 15 不只是可用性

應用程式如果具備某些大家很想要的重大功能，即使很難用，還是會大受歡迎。反之，一個全世界最容易使用的應用程式，如果沒有任何人想要的功能就會失敗。 _{p. 110}

如果其他條件相同，可用性就變得很重要了。 _{p. 111}

先試著解決「對的問題」，然後用好的方式解決問題。

如果不考慮文化和人性，軟體實做出來的社會性介面必然怪異且令人尷尬，無法真正發揮作用。 _{p. 113}

事實上，轉移攻擊最好的方法之一，就是讓他們自以為已經得逞。這相當於讓軟體裝死。 _{p. 115}

Chapter 16 用軟體建設社群

設計決策對於有所發展或翻展失敗的社群型態同樣重要。當你讓某些事物容易，人們就會經常去做、當你讓某些事情困難，做的人就會相對變少。 _{p. 118}

不守規矩的人才不會在乎告示上寫了什麼。因此，告示最終的結果，就是讓誠實的公民覺得自己被指控，卻無法喝止任何反社會分子。 _{p. 127}

在某些情況下，告示的作用是讓提供服務的一方在拒絕時，有一個法源上的依據，但不守規矩的人仍然會盧就是了

Part 4 管理大型專案

Chapter 17 火星耳機

Ars Technica 在 Eric Bangeman 寫道：「微軟 IE 團隊必須走在一條細線上，一邊要緊密支援 W3C 標準，另一方面又要確保能正確顯示針對較走版本 IE 所編寫的網站」。這說法不對，那並不是一條細線。那條線的寬度是負值，根本沒有地方可以走。他們做了會很慘，但不做也是一樣慘。 _{p. 134}

每個現役的軟體開發人員，至少都應該要知道「標準」是如何運作，以及應該如何運作，還有我們是怎麼搞成的一團亂。 _{p. 134}

我們熟知的標準很少是大家坐下來談，然後就成了大家都遵守的標準，大多數是市場競爭後留下的勝者，TCP/IP 是市場最大的七層通訊協定的參考實作版本，BlueRay 是打敗 HD-DVD 之後變成影視圈的標準，USB 贏了 IEEE 1394。因此，在勝負未定前押寶，押對了就跟著喝酒吃肉，押錯了就只能喝西北風，LTE 贏了 WiMAX 於是成為 4G 標準，就是這麼回事。

修改新發明的裝置，讓它在遇到舊耳機時，表現像是舊的裝置，不僅容易多了，而且較為合理。 _{p. 139}

因為你想進步，相要增加新特色和功能，所以新裝置也需要用到新的協定。合理的作法是讓兩個裝置在一開始先行溝通，決定雙方是否都能使用最新的協定。 _{p. 139}

注意，這個想法是把多對多測試，換成「多對標準」以及「標準對多」的測試，如此就可以大幅減少測試數量。更別提不再需要針對特定瀏覽器，為你的網頁撰寫特別程式碼，以解決個個瀏覽器的問題。因為在這個柏拉圖的世界裡不會有錯誤。

這是理想。

實際上，這種理想的 Web 有一點點問題，就是沒辦法用「標準」來測試網頁。因為沒有可參考的實作，能夠保證測試通過後，所有瀏覽器都能用。這種東西根本就不存在。 _{p. 142}

「標準」當然是個偉大的目標，不過，在成為標準狂之前，必須明白人類並不完美，所以標準有時候會被誤解，有時不太清楚，甚至模擬兩可。 _{p. 144}

在現實世界中，人是不完美的，一套標準不能只靠一份規格書，你還得有一個超級嚴格的參考實作，每個人都得用這個參考實作來測試。否則你會有 17 個不同的「標準」，其實等於完全沒有標準。 _{p. 144}

IE 8 無法正確顯示大部分的網頁，直到你放棄，並且按下「仿照 IE 7」按鈕。理想主義者不在乎：他們希望有人去修改這些網頁。其中有些網頁是無法改變的，他們可能被燒錄成光碟，也有一部分的作者已經過世。而大部分的網頁創造成，可能根本不知道發生什麼事。很多人也不知道四年前付錢請設計者做的網頁，為什麼現在不能用了。 _{p. 149}

向下相容真的是一件很難的事，但當你開發的 API 有人在使用了，就真的不要輕易改規格，特別在 B2B 的世界裡，你的甲方不見得願意花錢，再找個開發者去修改他們的 app，只因為你修改了 API 的規格。

Chapter 18 為何 Microsoft Office 檔案格式如此地複雜？(以及一些變通辦法)

它們必須在很舊的電腦跑得很快 _{p. 152}

這些是二進位格式，所以載入一筆紀錄通常就是把一串位元組由磁碟直接複製到記憶體，直接成為可以使用的 C 資料結構。 _{p. 152}

它們在設計上就是要用程式庫 _{p. 153}

它們在設計時並未考慮到交互操作性 (Interoperability) _{p. 153}

要等到 Internet 讓文件交換首度普及，像 SGML 和 HTML 之類可交換的標準化檔案格式構想，才能真正盛行起來。而這離 Office 二進位格式發明已經有十年了。 _{p. 153}

檔案格式必須反映應用程式所有的複雜性 _{p. 154}

它們必須反映應用程式的歷史 _{p. 154}

最早讀到這一章時，是開源陣營不斷地批評 Microsoft 不願意開放 Microsoft Office 檔案格式，讓它們的 Office 軟體無法正確讀取 Microsoft Office 的檔案，開放後又說裡面夾了一堆垃圾，因為它們的 Office 本來就沒打算 100% 複製所有的功能。

Chapter 19 想賺錢就別怕髒

問題是市場上付錢要的，正是解決難題而非容易的問題。 _{p. 160}

良好的設計似乎是最容易複製的東西，不過，看看微軟試圖複製 iPod 的結果，證明這並不是那麼簡單的。偉大的設計是一個難題，而且真的能提供歷久不衰的競爭優勢。 _{p. 161}

後記

在找到自己的舊部落格後，發現裡面其實有些有趣的題目，當時寫的比較簡單，似乎可以整理整理重新寫成一篇比較完整的文章。