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

閱讀時間約 14 分鐘
raw-image
整理時發現內容真的有點多,為了盡量控制在 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 大鳴大放,但讀起來還是很有滋味,很推薦給大家。

52會員
102內容數
這是從 Medium 開始的一個專題,主要是想用輕鬆閒談的方式,分享這幾年軟體開發的心得,原本比較侷限於軟體架構,但這幾年的文章不僅限於架構,也聊不少流程相關的心得,所以趁換平台,順勢換成閒談軟體設計。
留言0
查看全部
發表第一個留言支持創作者!