我這樣減少了26.5M Java內存
http://wetest.qq.com/lab/view/359.html
Android 內存暴減的秘密
http://wetest.qq.com/lab/view/362.html
通常來說不管是做什麼性能優化，逃不出性能優化3步曲：
1. 找到性能瓶頸
2. 分析優化方案
3. 執行優化
上述三步看似第三步最能決定優化結果，而事實上，從筆者的幾次性能優化經歷來看，找到瓶頸確佔據了絕對的影響力！
● 能否找到瓶頸意味著優化做不做的下去。
● 找到的瓶頸性能越差意味著優化效果越明顯。
● 找到的瓶頸越多同樣意味著優化效果越好。
2018年1月14日 星期日
2014年5月6日 星期二
如何扮演程式經理的角色？ - How to be a program manager
如何扮演程式經理的角色？ - How to be a program manager
Scott Berkun, Making Things Happen
Steve Krug, Don’t Make Me Think
Joel Spolsky, User Interface Design for Programmers
Dale Carnegie, How to Win Friends & Influence People
Scott Berkun, Making Things Happen
Steve Krug, Don’t Make Me Think
Joel Spolsky, User Interface Design for Programmers
Dale Carnegie, How to Win Friends & Influence People
怎麼學習當個程式經理？
作為程式經理是一種學習：學習技術、了解人性、搞懂怎麼在組織政治裡有效率的做事。好的程式經理能把工程師的想法整合到設計裡，並像政治家一樣把人聚在一起並建立共識。當你在做這些事情的時候，可以讀一讀這些書：
Scott Berkun 的「Making
Things Happen」是唯一一本內容涵蓋了程式經理所要做的事情的書。所以從這一本開始吧。Scott 曾經在 Internet Explorer 團隊擔任多年的程式經理。
程式經理的一大部分工作是設計使用者操作介面。首先可以讀 Steve Krug 的「Don’t Make Me Think」，然後是我寫的「User Interface Design for Programmers」。
最後，我知道這聽起來很俗氣，不過 Dale Carnegie 在 1937 年寫的「How to Win Friends & Influence
People」真的是的超棒的人際關係入門書。這是我所指定的在 Fog Creek 裡受訓的經理人要閱讀的第一本書。這些人一開始總是在私底下竊笑，不過大家在讀完之後都會愛上這本書。
2014年5月4日 星期日
找尋偉大開發者 - Finding Great Developers
找尋偉大開發者 - Finding Great Developers (翻譯中)
偉大的開發者，事實上，每個領域最優秀的人才，根本從來不曾出現在人力市場上。
平均來說，偉大的開發者在他們整個職業生涯裡，總共也許只會應徵四份工作。
優秀的大學畢業生會被與業界關係良好的教授拉進暑期實習，他們很早就拿到合約，從不用煩惱找工作的事兒。如果他們離開原本那家公司，通常去跟朋友合作創業，或跟著頂頭上司跳槽到另一家公司去，或者他們真的決定想要，例如，替Eclipse工作，只因為Eclipse很酷，所以他們去BEA或IBM找Eclipse相關的工作，因為他們非常優秀，當然就拿到工作了。
如果你夠好運，真的真的很好運的話，他們會在公開的人力市場上露一次臉，他們的另一半決定要接受地點位於安克拉治(阿拉斯加的一個港口)的醫學實習，他們才會真的送出求職信到少數他們認為在安克拉治可以工作的地方。
但大部分時候來說，這些偉大的開發者(這幾乎成了贅詞)，嗯，很偉大(好吧，這真是個贅詞)，而且，未來的雇主通常很快的認識到這些人的偉大之處，意思是說，基本上他們想要就可以找到工作，所以他們實在不需要投一大堆履歷或申請一大堆工作。
這聽起來像你想要雇用的那種人嗎? 鐵定是的。
有個獲取潛在的傑出人才的好方法 --
在他們出現在人力市場上以前就先得到他們：從大學裡。
一些人力資源主管不愛雇用實習生。他們認為實習生尚未成熟且技能不足，在某種程度上這個想法並沒有錯。實習生不比資深員工來的有經驗。（真的嗎？）你需要在他們身上多投資一些，而且要花點時間讓他們上軌道。好消息是，在我們圈子裡，真正偉大的程式設計師通常從10歲開始寫程式。其他同年齡的小鬼們還在「踢足球」的同時（足球是許多不會寫程式的小鬼玩的遊戲，玩法涉及用腳踢一個叫做「足球」的球狀物體 -- 我知道這聽起來很怪）他們卻在老爸的工作室內試著編譯Linux Kernel呢。與其在操場上追逐女孩，他們在 Usenet上和網友論戰著程式語言若沒有 Haskell 風格的型別推斷是全然的墮落；與其在車庫裡練團，他們修改了韌體讓偷用未加密的無線網路頻寬的鄰居，看到的圖片會是上下顛倒的。姆哈哈哈！
所以，不像法律或醫學領域，軟體開發領域裡的學生們，在大二、大三時就已經是超「棒」的程式師了。
....
當動用到親自面談時，我們有很高的機會雇用這個人，該是啟動正式招聘的時候了。我們在機場碰面，並由穿著制服的轎車司機連同行李將他們送往市中心鬧區（可能是他們看過最豪華的）酒店。隨時有時尚名媛進出、別緻的衛浴裝飾可能是博物館的典藏展品，他們可能要花點時間在五星級酒店裡學著刷牙。我們在客房內留給他們一個包裹：一件T恤、Fog Creek員工寫的紐約必遊景點地圖、2005年實習生紀錄片DVD。房間內的DVD播放機放著前屆實習生的有趣畫面。
經過一天的面試，我們邀請這些學生留在紐約幾天免費遊覽（如果他們想看看這城市）然後再由豪華轎車接送機場飛回家鄉。
雖然只有三分之一的面試者通過這些階段到最後面對面的面試，但讓這些面試者有好的體驗是很重要的。
即使面試失敗回到校園，他們仍然會認為我們是個好公司，並告訴他們的朋友在大蘋果待的飯店有多豪華，增加他們同儕明年也申請實習的意願（儘管他們可能只想來紐約享受這趟豪華旅行）
軟體人員面試教戰守則(第三版) - The Guerrilla Guide to Interviewing (version 3.0)
軟體人員面試教戰守則(第三版) - The Guerrilla Guide to Interviewing (version 3.0)
每個被雇用的人選都應該至少和六個人面談，六個人裡至少要有五位會和應徵者共事的人(也就是其他程式員而非經理)。你知道那種只靠幾位老鳥(salty)經理和應徵者面談，一試定生死的那種公司嗎？這些公司裡頭不會有非常優秀的工作人員。要瞞過一場面試實在太容易了，特別是由非程式員面試程式員時更是如此。
如果六次面談中有兩人認為對方不值得用，就不要錄取。這表示當你不打算錄用某位應徵者時，在兩次面談後就可以技術性地結束「整天」的面試，這並不算是壞事。不過為了避免流於殘酷，最好不要事先告訴對方要面談的次數。我還聽過有些公司允許任何一個面試官把人選刷掉。我覺得這有點太過頭了；對我來說，或許可以容許讓資深人員刷掉應徵者，不過不會只因某個新進人員不喜歡而否決。
軟體產業的變化太頻繁又太快，所以你需要那種任何編程工作都可以勝任的人。如果基於某種原因，你發現一個非常非常擅長SQL，但是完全無法學習其他主題的白痴學究，不錄用。否則就會就是拿長痛去換短痛。
錯失好人選比錄用不適合的人要好太多了。不對的人會耗用很多錢和精力，還會讓其他人浪費時間去修正所有的問題。錄用錯人要開除得花上好幾個，而且會非常的困難(當他們決定對簿公堂時更是格外麻煩)。在某些情況下也有可能完全無法開除任何人。不好的員工會破壞好員工的士氣。而且他們可能是個爛程式員，同時卻又是個真正的好人或是極度需要這個工作，所以你根本不忍心開除他們，不然就是一開除就會犯眾怒，或是其他種種的窘境。反正很慘就是了。
反過來說，如果你否決了一個好人選，我是指我認為有些地方不太公平，不過如果他們真的這麼聰明就不用擔心，他們有很多好的工作機會可以挑。別害怕會因為拒絕太多人而找不到人用。這在面談過程中並不是你的問題。當然找到好的人選非常重要。不過當你實際面試某人時，要假裝門外還有900個人排隊等著和你面試。不管優秀人選似乎有多麼難找，也不要降低你的標準。
好了，我還沒有告訴你最重要的部份：如何知道是否要錄用某人？
原則上很簡單。你要找的人必須聰明，而且能把事做完。
你要如何在面談中察覺聰明這回事呢？頭一個徵兆就是你不必再三地說明事情。對話會很流暢地進行。應徵者經常會說出某些很有見地有思想或是心思敏銳的話。所以面談的重點之一就在於建立情境，讓受試者能向你展示他有多麼聰明。
愛吹牛的人是最差勁的面試官。這種人在面談時都在胡扯，應徵者只來得及說「是的，這實在是對極了，我衷心的同意你的看法。」吹牛專家什麼人都會錄用；他們認為應徵者一定很聰明，因為「他的想法和我很像！」
益智問答型的面試官是第二糟的。這種人認為聰明表示「知道很多事實」。他們只會問一堆瑣碎的編程問題，答對就加分。純粹好玩提一下世界上最爛的面試問題：「Oracle 8i裡的varchar和varchar2有何差別？」這是個爛問題。會知道這種芝麻小事的人和你真正想用的人完全不會有任何關聯。誰會在乎有什麼差別？你只要約15秒就可以在線上找到答案！記住，聰明並不等於「知道瑣碎問題的答案」。
總而言之，軟體團隊是要雇用有才華而非會某種特定技能的人。畢竟所有能用在工作上的特定技能，就技術而言都會在數年內過時，所以最好雇用能學習任何新技術的人，而不是此刻剛好知道如何讓JDBG和MySQL資料庫溝通的傢伙。
不過大體來說，要深入瞭解一個人的方法就是讓他說話，要提出開放性的問題與難題。
2014年4月20日 星期日
卓越客戶服務的七步驟 - Seven steps to remarkable customer service
卓越客戶服務的七步驟 - Seven steps to remarkable customer service
建議吹掉灰塵
某個顧客抱怨鍵盤不會動。原因當然是因為沒有接線。如果你問他們線有沒有接好，「他們會覺得被侮辱，氣沖沖地說『當然接了！我像個白癡嗎？』而不去檢查。」
Chen的建議是「換一種說法『好，有時候接頭會有點灰塵而鬆掉。你可以把接頭拔下把灰吹掉再插回去嗎？』」
「然後他們就會爬到桌子下，發現自己忘了接線(或是插錯洞)，就會吹一吹插回去然後回答『嗯，耶，這樣就好了，謝謝。』」
很多要求客戶進行某些檢查的動作都可以用這種方式表達。不要叫他們檢查某個設定，而是要他們把設定改掉再改回去，目的「只是要確定軟體有確實把設定存起來。」
建議吹掉灰塵
某個顧客抱怨鍵盤不會動。原因當然是因為沒有接線。如果你問他們線有沒有接好，「他們會覺得被侮辱，氣沖沖地說『當然接了！我像個白癡嗎？』而不去檢查。」
Chen的建議是「換一種說法『好，有時候接頭會有點灰塵而鬆掉。你可以把接頭拔下把灰吹掉再插回去嗎？』」
「然後他們就會爬到桌子下，發現自己忘了接線(或是插錯洞)，就會吹一吹插回去然後回答『嗯，耶，這樣就好了，謝謝。』」
很多要求客戶進行某些檢查的動作都可以用這種方式表達。不要叫他們檢查某個設定，而是要他們把設定改掉再改回去，目的「只是要確定軟體有確實把設定存起來。」
讓錯的程式看得出錯 - Making Wrong Code Look Wrong (命名規範)
讓錯的程式看得出錯 - Making Wrong Code Look Wrong
我是故意用種類(kind)這個詞，因為Simonyi在他的文章中誤用了型別(type)，結果好幾世代的程式師都誤解了他的意思。
如果你仔細讀Simonyi的文章，就會發現他所講的和我之前範例所用的命名規範是一樣的，
在我的範例中把us和s分別定義為不安全字串和安全字串。這兩者的型別都是字串。
如果你把某種字串指派另一種，編譯器並不會給任何警告，Intellisense也不會說些什麼。
可是他們的語意是不同的；他們解讀和處理的方式都不同，要把兩種字串互相指派時還要某些轉換函數做轉換，否則就會有執行時期的問題。
我是故意用種類(kind)這個詞，因為Simonyi在他的文章中誤用了型別(type)，結果好幾世代的程式師都誤解了他的意思。
如果你仔細讀Simonyi的文章，就會發現他所講的和我之前範例所用的命名規範是一樣的，
在我的範例中把us和s分別定義為不安全字串和安全字串。這兩者的型別都是字串。
如果你把某種字串指派另一種，編譯器並不會給任何警告，Intellisense也不會說些什麼。
可是他們的語意是不同的；他們解讀和處理的方式都不同，要把兩種字串互相指派時還要某些轉換函數做轉換，否則就會有執行時期的問題。
明確型別宣告(explicit typing, 要求程式員必須宣告型別)
2014年3月17日 星期一
爪哇學校的危害 - The Perils of JavaSchools
爪哇學校的危害 - The Perils of JavaSchools
有些小孩高中就在自己的Apple II上，用BASIC寫出很棒的乒乓遊戲。當這些孩子上大學修CompSci 101(一門資料結構的課程)，接觸指標這玩意之後，轟！他們的大腦馬上被炸成一堆豆腐渣，接下來都跑去修政治學，因為法學院似乎是個更好的主意。我看過CS科系退學率的各種數字，通常介於40%到70%之間。大學當局通常認視之為浪費，我則認為這是必要的排除手段，讓那些往後無法樂於編程職業或因此成功的人及早出局。
對許多年輕的CS學生來說，另一個難題是教授functional programming(包括遞迴編程在內)的課程。MIT對這些課程的要求很高，不但創造了必修課程(6.001)，還編寫出一本教科書(Abelson & Sussman的Structure and Interpretation of Computer Programs)，被數十甚至數百所一流CS學校拿來作為CS入門教材。
不瞭解function programming，就無法發明MapReduce這個讓Google具備驚人擴充性的演算法。Map跟Reduce是從Lisp和function programming來的。修過相當於6.001編程課程的人，如果還記得純functional programs沒有什麼副作用，不會影響並行的函式，因此可以輕易地平行化同步處理。在他們回想之際，MapReduce實是是顯而易見的演算法。Google發明了MapReduce而微軟沒有，這個事實可以解釋為何當微軟仍在嘗試讓基本搜尋功能能運作時，Google已經進到下個領域：建立Skynet這個世界上最大的平行處理超級電腦，我不認為微軟真正瞭解他們在這波競爭中落後了多少。
有些小孩高中就在自己的Apple II上，用BASIC寫出很棒的乒乓遊戲。當這些孩子上大學修CompSci 101(一門資料結構的課程)，接觸指標這玩意之後，轟！他們的大腦馬上被炸成一堆豆腐渣，接下來都跑去修政治學，因為法學院似乎是個更好的主意。我看過CS科系退學率的各種數字，通常介於40%到70%之間。大學當局通常認視之為浪費，我則認為這是必要的排除手段，讓那些往後無法樂於編程職業或因此成功的人及早出局。
對許多年輕的CS學生來說，另一個難題是教授functional programming(包括遞迴編程在內)的課程。MIT對這些課程的要求很高，不但創造了必修課程(6.001)，還編寫出一本教科書(Abelson & Sussman的Structure and Interpretation of Computer Programs)，被數十甚至數百所一流CS學校拿來作為CS入門教材。
不瞭解function programming，就無法發明MapReduce這個讓Google具備驚人擴充性的演算法。Map跟Reduce是從Lisp和function programming來的。修過相當於6.001編程課程的人，如果還記得純functional programs沒有什麼副作用，不會影響並行的函式，因此可以輕易地平行化同步處理。在他們回想之際，MapReduce實是是顯而易見的演算法。Google發明了MapReduce而微軟沒有，這個事實可以解釋為何當微軟仍在嘗試讓基本搜尋功能能運作時，Google已經進到下個領域：建立Skynet這個世界上最大的平行處理超級電腦，我不認為微軟真正瞭解他們在這波競爭中落後了多少。
利誘管理法 - The Econ 101 Management Method
利誘管理法 - The Econ 101 Management Method
一個大的問題是：這方法會導致內在動機被外在動機取代掉。
人們將會傾向去尋找局部的最大獲益，他們會找到一些方法，去尋求最佳化某些你正獎勵他們的特殊事情，而不是完成你真正意圖要達成的事。
當你使用利誘管理法時，你等於在鼓勵開發者玩弄制度。
假定你決定獎賞寫出最少臭蟲的開發者，那麼當測試人員要回報一個臭蟲時，就成了大問題了，開發著通常會說服測試員這並不是真的臭蟲；或者測試員會同意，在回報給臭蟲管理系統之前，先非正式地提報臭蟲給開發人員，那麼現在就沒有人會使用臭蟲管理系統啦，雖然記錄中的臭蟲數量降低，但實際的數量並沒有任何改變。
開發者在這方面可是相當有天分的，無論你想要測量什麼，他們總是可以找到方法最大化此數值，而你永遠也無法獲得真正想要的東西。
一個大的問題是：這方法會導致內在動機被外在動機取代掉。
人們將會傾向去尋找局部的最大獲益，他們會找到一些方法，去尋求最佳化某些你正獎勵他們的特殊事情，而不是完成你真正意圖要達成的事。
當你使用利誘管理法時，你等於在鼓勵開發者玩弄制度。
假定你決定獎賞寫出最少臭蟲的開發者，那麼當測試人員要回報一個臭蟲時，就成了大問題了，開發著通常會說服測試員這並不是真的臭蟲；或者測試員會同意，在回報給臭蟲管理系統之前，先非正式地提報臭蟲給開發人員，那麼現在就沒有人會使用臭蟲管理系統啦，雖然記錄中的臭蟲數量降低，但實際的數量並沒有任何改變。
開發者在這方面可是相當有天分的，無論你想要測量什麼，他們總是可以找到方法最大化此數值，而你永遠也無法獲得真正想要的東西。
讓你的履歷有可讀性 - Getting Your Résumé Read
讓你的履歷有可讀性 - Getting Your Résumé Read
大量散發的垃圾履歷，或是任何顯示你正在申請100個職缺的跡象，都只是讓你看起來自暴自棄而更使你顯得不夠格。你想讓自己看起來像一個搶手人才，正在決定要去那裡工作，因為你夠聰明可以在這方面做個選擇，所以你只需要申請一或兩個職位。
一封顯示你知道公司業務的個人化求職信是很有幫助的，表示你很在乎這個工作，值得給予一次面試機會。
我們真正尋找的是有熱情而且在任何他們想做的事上都會成功的人。我們喜歡對軟體有熱情的人。對我們來說，十幾歲時就寫出共享軟體是個跟進麻省理工學院一樣好的指標。這是你的生命故事，而在你申請工作時多半已經來不及改變了。
大量散發的垃圾履歷，或是任何顯示你正在申請100個職缺的跡象，都只是讓你看起來自暴自棄而更使你顯得不夠格。你想讓自己看起來像一個搶手人才，正在決定要去那裡工作，因為你夠聰明可以在這方面做個選擇，所以你只需要申請一或兩個職位。
一封顯示你知道公司業務的個人化求職信是很有幫助的，表示你很在乎這個工作，值得給予一次面試機會。
我們真正尋找的是有熱情而且在任何他們想做的事上都會成功的人。我們喜歡對軟體有熱情的人。對我們來說，十幾歲時就寫出共享軟體是個跟進麻省理工學院一樣好的指標。這是你的生命故事，而在你申請工作時多半已經來不及改變了。
2014年3月16日 星期日
開發抽象層 - The Development Abstraction Layer
開發抽象層 - The Development Abstraction Layer
程式員的工作層次（比方說，Emacs）實在太過於抽象了，抽象到做不了生意。在抽象層工作的軟體開發者，還需要一個實作層 -- 一個能將程式碼轉換成產品的組織。
桃莉巴頓（Dolly Parton）是在”唱好歌”那一個層次的，她也需要一個龐大的實作層，來幫她灌唱片、訂演唱會場地、賣票、音效、宣傳、收版稅。
任何成功的軟體公司都會包括薄薄一層的開發者，這些開發者散佈在巨大管理組織抽象層之上建立軟體。這個抽象層存在的目的，只是為了建立一種假象，讓大家覺得一個程式員的日常活動(程式碼的設計及撰寫，程式碼的簽入、除錯等等)，就是建立軟體產品並將之引入市場的一切。
這一點讓我得出本文最關鍵的重點：
身為軟體團隊經理，你的第一要務是建立開發抽象層。
大多數軟體經理新人都未察覺這個重點。他們只會一直想由好萊塢電影學到的傳統命令式管理模式。
在命令式的作法中，經理/團隊領隊會找出公司的目標，然後對副官下達適當命令把公司往讓方向移動。副官接下來會細分工作再命令下屬執行。這個過程會沿著組織圖往下重複進行，直到最後某個在最底層的人實際做事為止。在這種模式之下，程式員就是機器中的一根齒輪牙：一個執行管理階層命令中某一部份的打字員。
對一家軟體公司而言，管理的第一要務就是替程式員建立那樣的抽象層。
如果某個程式員正為椅子壞掉而操心，或是因為等Dell送新電腦來閒置，表示這個抽象層已經有了裂縫。
把你的開發抽象層想像成一艘具備超級馬力的美麗大遊艇。遊艇的維護無懈可擊。美食準時送上。包廂每天有兩次整理服務。導航地圖隨時更新。全球定位系統和雷達從不出問題，就算壞了艙內也有備份。而在艦橋上則是只需要考慮速度方向以及午餐吃鮪魚還是鮭魚的程式員。同時有一大隊身著漿硬白制服的專業人員在甲板下悄悄活動，維持所有事情的運作、填滿油槽、刮除藤壼、熨平午餐餐巾。這個支援團隊知道要做什麼，不過全都聽從臭屁老領隊(salty old fart)的指示。後者只要往某個方向輕輕點頭，整隊人就會完全協調演出，讓程式員能把遊艇的細節全部抽象掉，只要管速度和方向，以及午餐要吃些什麼。
最需要為建立程式員的抽象層負責的就是軟體公司的管理階層。我們建造遊艇，我們服務遊艇，我們就是遊艇本身，不過我們不駕駛遊艇。我們做的每件事都是要為程式員提供一個無縫隙的抽象層，讓他們能創造出偉大的程式，再讓那些程式抵達能因而獲益的客戶手中。
程式員需要Subversion儲存庫。建立一個Subversion儲存庫意味著你需要一個網路和一台伺服器，必須去採購、安裝、備份，還要配置不斷電系統；伺服器會產生很多熱，表示你得準備一個有額外空調的房間去放；而空調得連接到大樓外，表示大樓外牆外面要裝一個80磅的風扇；安裝這東西會讓屋主緊張，所以他們得帶自己的工程師來，協調要在哪裡安置空調設備(決策結果：要裝在往上到18樓的外牆上，可能是最不方便的位置)，而屋主也會拉律師進來，因為我們得付出許多才獲淮進行；然後當空調安裝人員出現了，還帶著有如芭比玩具組的吊索機具，讓我們的建築工頭緊張起來，不肯讓他們穿著半吋粉紅塑膠製的美泰兒(Mattel，譯註：著名玩具商)繫具爬出18樓窗外，於是有人得再把包商找來，搞清楚他們為什麼在施工12週後，會突然發現得為這該死空調再次修改合約，而且這東西早在耶誕節前就知道要裝但是剛剛才弄清楚。而這件事即使只讓你的程式員花一分鐘去想都嫌太多。
就你的團隊中的軟體開發者而言，這一切都必須被抽象化成只要在命令列鍵入svn commit。
這就是要有管理階層的原因。
管理階層就是為了那些沒有公司能避免的事，不過如果讓你的程式員為此而操心，那麼管理階層就算失敗了。這就像如果百萬富翁船主得下去引擎室建造引擎，這台一百英呎長的遊艇也算失敗了。
要讓一位程式員發揮最大的生產力，必須搭配一間安靜的個人辦公室、一台強大的電腦、無限制的飲料，華氏68到72度的室溫、螢幕上沒有反光、一張極舒適而不會感覺到的椅子、一位替他們帶來信件和訂購的書籍手冊的管理者，一位讓網際網路讓氧氣般隨時可用的系統管理者、一位能找出他們自己看不到的臭蟲的測試人員、一位讓他們的畫面美麗悅目的繪圖設計師、一組讓大眾想要他們產品的行銷團隊、一組確保大眾能拿到這些產品的業務團體、幾位協助客戶使用產品，並讓程式員瞭解導致客服電話的問題，極具耐心的技術支援聖人、以及其他十幾位支援及行政人員，而這些在一家典型的公司裡總共會佔用八成的薪資支出。羅馬軍隊中每位士兵配置四名僕人的比例並非巧合。這並不是墮落。現代軍隊的比例可能高達7:1。
沒有人期望桃莉巴頓知道如何接上麥克風。她背後有一個無法想像，由經理人、音樂家、錄音技師、唱片公司、巡迴演出經紀人、美髮師、宣傳人員組成的基礎結構，這全部的一切只是要在她唱歌時建立那種抽象性，好像數百萬人會聆聽只是因為是她在唱歌。這所有讓桃莉巴頓得以實現的支援人員和管理階層所能做的最佳工作，就是提供最完美的抽象：那種桃莉巴頓為我們而唱的完美假象。這就是她的歌。當你用你的iPod聆聽她的歌，其實是有個巨大的基礎結構讓這件事實現，不過這個基礎結構所能完成最棒的事就是完全消失。只剩下桃莉巴頓獨自對我們唱歌這個完美的抽象意念。
===
由程式員驅動，在組織上讓程式員坐上駕駛座，同時卻有優異的抽象層能在甲板下完成所有把程式碼轉成產品的苦工。
程式員的工作層次（比方說，Emacs）實在太過於抽象了，抽象到做不了生意。在抽象層工作的軟體開發者，還需要一個實作層 -- 一個能將程式碼轉換成產品的組織。
桃莉巴頓（Dolly Parton）是在”唱好歌”那一個層次的，她也需要一個龐大的實作層，來幫她灌唱片、訂演唱會場地、賣票、音效、宣傳、收版稅。
任何成功的軟體公司都會包括薄薄一層的開發者，這些開發者散佈在巨大管理組織抽象層之上建立軟體。這個抽象層存在的目的，只是為了建立一種假象，讓大家覺得一個程式員的日常活動(程式碼的設計及撰寫，程式碼的簽入、除錯等等)，就是建立軟體產品並將之引入市場的一切。
這一點讓我得出本文最關鍵的重點：
身為軟體團隊經理，你的第一要務是建立開發抽象層。
大多數軟體經理新人都未察覺這個重點。他們只會一直想由好萊塢電影學到的傳統命令式管理模式。
在命令式的作法中，經理/團隊領隊會找出公司的目標，然後對副官下達適當命令把公司往讓方向移動。副官接下來會細分工作再命令下屬執行。這個過程會沿著組織圖往下重複進行，直到最後某個在最底層的人實際做事為止。在這種模式之下，程式員就是機器中的一根齒輪牙：一個執行管理階層命令中某一部份的打字員。
對一家軟體公司而言，管理的第一要務就是替程式員建立那樣的抽象層。
如果某個程式員正為椅子壞掉而操心，或是因為等Dell送新電腦來閒置，表示這個抽象層已經有了裂縫。
把你的開發抽象層想像成一艘具備超級馬力的美麗大遊艇。遊艇的維護無懈可擊。美食準時送上。包廂每天有兩次整理服務。導航地圖隨時更新。全球定位系統和雷達從不出問題，就算壞了艙內也有備份。而在艦橋上則是只需要考慮速度方向以及午餐吃鮪魚還是鮭魚的程式員。同時有一大隊身著漿硬白制服的專業人員在甲板下悄悄活動，維持所有事情的運作、填滿油槽、刮除藤壼、熨平午餐餐巾。這個支援團隊知道要做什麼，不過全都聽從臭屁老領隊(salty old fart)的指示。後者只要往某個方向輕輕點頭，整隊人就會完全協調演出，讓程式員能把遊艇的細節全部抽象掉，只要管速度和方向，以及午餐要吃些什麼。
最需要為建立程式員的抽象層負責的就是軟體公司的管理階層。我們建造遊艇，我們服務遊艇，我們就是遊艇本身，不過我們不駕駛遊艇。我們做的每件事都是要為程式員提供一個無縫隙的抽象層，讓他們能創造出偉大的程式，再讓那些程式抵達能因而獲益的客戶手中。
程式員需要Subversion儲存庫。建立一個Subversion儲存庫意味著你需要一個網路和一台伺服器，必須去採購、安裝、備份，還要配置不斷電系統；伺服器會產生很多熱，表示你得準備一個有額外空調的房間去放；而空調得連接到大樓外，表示大樓外牆外面要裝一個80磅的風扇；安裝這東西會讓屋主緊張，所以他們得帶自己的工程師來，協調要在哪裡安置空調設備(決策結果：要裝在往上到18樓的外牆上，可能是最不方便的位置)，而屋主也會拉律師進來，因為我們得付出許多才獲淮進行；然後當空調安裝人員出現了，還帶著有如芭比玩具組的吊索機具，讓我們的建築工頭緊張起來，不肯讓他們穿著半吋粉紅塑膠製的美泰兒(Mattel，譯註：著名玩具商)繫具爬出18樓窗外，於是有人得再把包商找來，搞清楚他們為什麼在施工12週後，會突然發現得為這該死空調再次修改合約，而且這東西早在耶誕節前就知道要裝但是剛剛才弄清楚。而這件事即使只讓你的程式員花一分鐘去想都嫌太多。
就你的團隊中的軟體開發者而言，這一切都必須被抽象化成只要在命令列鍵入svn commit。
這就是要有管理階層的原因。
管理階層就是為了那些沒有公司能避免的事，不過如果讓你的程式員為此而操心，那麼管理階層就算失敗了。這就像如果百萬富翁船主得下去引擎室建造引擎，這台一百英呎長的遊艇也算失敗了。
要讓一位程式員發揮最大的生產力，必須搭配一間安靜的個人辦公室、一台強大的電腦、無限制的飲料，華氏68到72度的室溫、螢幕上沒有反光、一張極舒適而不會感覺到的椅子、一位替他們帶來信件和訂購的書籍手冊的管理者，一位讓網際網路讓氧氣般隨時可用的系統管理者、一位能找出他們自己看不到的臭蟲的測試人員、一位讓他們的畫面美麗悅目的繪圖設計師、一組讓大眾想要他們產品的行銷團隊、一組確保大眾能拿到這些產品的業務團體、幾位協助客戶使用產品，並讓程式員瞭解導致客服電話的問題，極具耐心的技術支援聖人、以及其他十幾位支援及行政人員，而這些在一家典型的公司裡總共會佔用八成的薪資支出。羅馬軍隊中每位士兵配置四名僕人的比例並非巧合。這並不是墮落。現代軍隊的比例可能高達7:1。
沒有人期望桃莉巴頓知道如何接上麥克風。她背後有一個無法想像，由經理人、音樂家、錄音技師、唱片公司、巡迴演出經紀人、美髮師、宣傳人員組成的基礎結構，這全部的一切只是要在她唱歌時建立那種抽象性，好像數百萬人會聆聽只是因為是她在唱歌。這所有讓桃莉巴頓得以實現的支援人員和管理階層所能做的最佳工作，就是提供最完美的抽象：那種桃莉巴頓為我們而唱的完美假象。這就是她的歌。當你用你的iPod聆聽她的歌，其實是有個巨大的基礎結構讓這件事實現，不過這個基礎結構所能完成最棒的事就是完全消失。只剩下桃莉巴頓獨自對我們唱歌這個完美的抽象意念。
===
由程式員驅動，在組織上讓程式員坐上駕駛座，同時卻有優異的抽象層能在甲板下完成所有把程式碼轉成產品的苦工。
2014年3月14日 星期五
開發人員完全指南 - A Field Guide to Developers
開發人員完全指南 - A Field Guide to Developers
程式員在組織中是怎麼被看待的？
他們是明星還是打字員？公司經理是由工程師或曾任程式員的人組成的嗎？開發者能乘坐頭等艙去參與研討會嗎？（我不在乎這是否像是在浪費錢，明星就該坐頭等艙，要逐漸習慣這樣的思維！）當他們飛抵機場準備來參與面試時，將會有輛轎車來接送呢？還是得自己想辦法到達公司？基於相同的背景條件下，開發者傾向於選擇將他們當成明星的組織。假若你們公司的執行長是個壞脾氣的銷售員，他不能理解為何這些嬌貴的開發人員會持續的爭取類似腕墊、大螢幕跟舒適椅子等等之類的東西，他們以為自己是誰呀？那麼你的公司或許需要好好的調整態度，如果你不尊重他們，你將永遠無法獲得優秀的開發人員。
他們的同事是哪些人？
程式員在面試的那天還會密切注意他們所遇見的任何人。他們友善嗎？更重要的是：他們都聰明機靈嗎？我曾經在Bellcore暑期實習過，我遇到的每個人都一遍又一遍地告訴我相同的事：能遇到這兒的人們是他們在Bellcore工作時最美好的事。
這告訴我們，不要讓無法駕馭、怪脾氣的開發人員參與任何面試活動，相反的，記得找具有親和的、社交能力強、個性溫和等特質的人一起參與。隨時提醒自己，當你的求職者們回到家並且要決定到哪兒上班時，若是他在你的公司遇到的每個人都是陰沈憂鬱地，則他們絕不會有正面印象。
另外，原本Fog Creek公司預想的徵人規則（這概念是從微軟偷來的）為「聰明、可將事情做好」，但就在我們正式讓公司營運之前，我們理解到還應該加上第三個規則：「不要討人厭的怪喀（譯註：jerk,粗魯、不顧別人感受、讓人厭惡的人）」。回想起來，想在微軟獲得一份工作，不是怪喀向來不是個必要條件；雖然我很肯定他們會客套地說：能對他人友善是件重要的事，但真實情況為：他們絕不會只因某人惹人嫌就開除掉他，事實上，當個怪喀有時還會是個進入高階管理階層的先備條件。從管理角度來看這似乎是無害的，但從招募的角度來看卻是有害的：有人願意在一家容忍怪喀的公司上班呢？
程式員在組織中是怎麼被看待的？
他們是明星還是打字員？公司經理是由工程師或曾任程式員的人組成的嗎？開發者能乘坐頭等艙去參與研討會嗎？（我不在乎這是否像是在浪費錢，明星就該坐頭等艙，要逐漸習慣這樣的思維！）當他們飛抵機場準備來參與面試時，將會有輛轎車來接送呢？還是得自己想辦法到達公司？基於相同的背景條件下，開發者傾向於選擇將他們當成明星的組織。假若你們公司的執行長是個壞脾氣的銷售員，他不能理解為何這些嬌貴的開發人員會持續的爭取類似腕墊、大螢幕跟舒適椅子等等之類的東西，他們以為自己是誰呀？那麼你的公司或許需要好好的調整態度，如果你不尊重他們，你將永遠無法獲得優秀的開發人員。
他們的同事是哪些人？
程式員在面試的那天還會密切注意他們所遇見的任何人。他們友善嗎？更重要的是：他們都聰明機靈嗎？我曾經在Bellcore暑期實習過，我遇到的每個人都一遍又一遍地告訴我相同的事：能遇到這兒的人們是他們在Bellcore工作時最美好的事。
這告訴我們，不要讓無法駕馭、怪脾氣的開發人員參與任何面試活動，相反的，記得找具有親和的、社交能力強、個性溫和等特質的人一起參與。隨時提醒自己，當你的求職者們回到家並且要決定到哪兒上班時，若是他在你的公司遇到的每個人都是陰沈憂鬱地，則他們絕不會有正面印象。
另外，原本Fog Creek公司預想的徵人規則（這概念是從微軟偷來的）為「聰明、可將事情做好」，但就在我們正式讓公司營運之前，我們理解到還應該加上第三個規則：「不要討人厭的怪喀（譯註：jerk,粗魯、不顧別人感受、讓人厭惡的人）」。回想起來，想在微軟獲得一份工作，不是怪喀向來不是個必要條件；雖然我很肯定他們會客套地說：能對他人友善是件重要的事，但真實情況為：他們絕不會只因某人惹人嫌就開除掉他，事實上，當個怪喀有時還會是個進入高階管理階層的先備條件。從管理角度來看這似乎是無害的，但從招募的角度來看卻是有害的：有人願意在一家容忍怪喀的公司上班呢？
求職信排序 - Sorting Resumes
求職信排序 - Sorting Resumes
熱情。 我們尋找求職者對電腦充滿熱情與真正喜歡寫程式的證據.
典型的證據是：
1. 電腦相關工作或寫程式的經驗可以回溯到年紀很小的時候. 偉大的程式設計師很可能花一個暑假在電腦營，或為他的牙醫叔叔建立一個線上預約系統，而不是在香蕉共和國(註：成衣連鎖店)打工折衣服。
2. 課外活動. 喜歡寫程式的人通常會利用閒暇時間投入他自己的程式計畫(或是在開放源碼的專案中有所貢獻).
3. 在他們的求職信上，說明他們如何的被電腦程式的結構與闡釋感動落淚
英文。對我們來說用英文技巧來評分履歷是一個難以下的決定，因為電腦程式設計是不會說英文的移民一樣可以做的好的一門領域。與程式設計師工作的多年經驗教會我，能清楚地溝通他們的想法的程式設計師遠比只能跟編譯器溝通的程式設計師更加有效。為程式寫文件是很關鍵的，撰寫其他人能審閱的規格與技術設計文件也是關鍵的，甚至對那些你們只是坐著討論如何做較佳的會議也是關鍵的：對解釋想法有困難的聰明程式設計師無法提供更多貢獻。在這個類別，我們也只考慮履歷是否清爽易懂。一個充斥文法錯誤的無組織履歷只會啟動一個大紅標幟：這是一個思想毫無組織的人或一般的懶人；這對許多工作來說也許沒關係但是對軟體開發者來說不行。特別是我們常常完全剔除充滿英文錯誤的履歷。就算對一個非英文母語的人來說，找一個人檢查你的履歷也不是困難的事，這件事也不做常表示你對你做的事非常缺乏對品質的關心。.
他們花時間認識 Fog Creek 並寫一篇為我們量身訂做的求職信表示他們對自己的能力有很大的信心，所以他們只申請少數的職缺，而不是寄一大堆給上千家公司。同時發出一堆的履歷是絕望的徵兆。更重要的是，一個量身訂做的求職信是一個徵兆：如果我們真的錄取這個應徵者，他們很可能會接受。這增進我們的投資報酬率。如果我只有夠面試六個人的時間，面試者其他條件均相同，我較願意面試六個真的想要為 Fog Greek 工作的人，不是一般也同時應徵其他工作的聰明人。
記得這件事真的是非常非常重要：
這些類別─熱情、只挑選少數公司、英文能力、頭腦、經過汰選、硬底子與多樣性─並不是雇用人的標準。做為標準這些都太不足了。有太多的優秀人才在考試中拿低分或差勁程式設計師在考試中拿高分。在你動紙去咆哮約耳如何認為你應該只雇用來自長春藤名校或約耳有某種成績情結，不論如何，重要的是瞭解這清單並不是雇用某人或拒絕某人的理由清單。這所有的只是一個目標導向且公平的方法可以為一大疊求職信做排序來找出最有可能來你公司工作的候選人優先安排面試，然後決定他們是否值得錄取。記得這件事真的是非常非常重要：這些類別─熱情、只挑選少數公司、英文能力、頭腦、經過汰選、硬底子與多樣性─並不是雇用人的標準。做為標準這些都太不足了。有太多的優秀人才在考試中拿低分或差勁程式設計師在考試中拿高分。在你動紙去咆哮約耳如何認為你應該只雇用來自長春藤名校或約耳有某種成績情結，不論如何，重要的是瞭解這清單並不是雇用某人或拒絕某人的理由清單。這所有的只是一個目標導向且公平的方法可以為一大疊求職信做排序來找出最有可能來你公司工作的候選人優先安排面試，然後決定他們是否值得錄取。
熱情。 我們尋找求職者對電腦充滿熱情與真正喜歡寫程式的證據.
典型的證據是：
1. 電腦相關工作或寫程式的經驗可以回溯到年紀很小的時候. 偉大的程式設計師很可能花一個暑假在電腦營，或為他的牙醫叔叔建立一個線上預約系統，而不是在香蕉共和國(註：成衣連鎖店)打工折衣服。
2. 課外活動. 喜歡寫程式的人通常會利用閒暇時間投入他自己的程式計畫(或是在開放源碼的專案中有所貢獻).
3. 在他們的求職信上，說明他們如何的被電腦程式的結構與闡釋感動落淚
英文。對我們來說用英文技巧來評分履歷是一個難以下的決定，因為電腦程式設計是不會說英文的移民一樣可以做的好的一門領域。與程式設計師工作的多年經驗教會我，能清楚地溝通他們的想法的程式設計師遠比只能跟編譯器溝通的程式設計師更加有效。為程式寫文件是很關鍵的，撰寫其他人能審閱的規格與技術設計文件也是關鍵的，甚至對那些你們只是坐著討論如何做較佳的會議也是關鍵的：對解釋想法有困難的聰明程式設計師無法提供更多貢獻。在這個類別，我們也只考慮履歷是否清爽易懂。一個充斥文法錯誤的無組織履歷只會啟動一個大紅標幟：這是一個思想毫無組織的人或一般的懶人；這對許多工作來說也許沒關係但是對軟體開發者來說不行。特別是我們常常完全剔除充滿英文錯誤的履歷。就算對一個非英文母語的人來說，找一個人檢查你的履歷也不是困難的事，這件事也不做常表示你對你做的事非常缺乏對品質的關心。.
他們花時間認識 Fog Creek 並寫一篇為我們量身訂做的求職信表示他們對自己的能力有很大的信心，所以他們只申請少數的職缺，而不是寄一大堆給上千家公司。同時發出一堆的履歷是絕望的徵兆。更重要的是，一個量身訂做的求職信是一個徵兆：如果我們真的錄取這個應徵者，他們很可能會接受。這增進我們的投資報酬率。如果我只有夠面試六個人的時間，面試者其他條件均相同，我較願意面試六個真的想要為 Fog Greek 工作的人，不是一般也同時應徵其他工作的聰明人。
記得這件事真的是非常非常重要：
這些類別─熱情、只挑選少數公司、英文能力、頭腦、經過汰選、硬底子與多樣性─並不是雇用人的標準。做為標準這些都太不足了。有太多的優秀人才在考試中拿低分或差勁程式設計師在考試中拿高分。在你動紙去咆哮約耳如何認為你應該只雇用來自長春藤名校或約耳有某種成績情結，不論如何，重要的是瞭解這清單並不是雇用某人或拒絕某人的理由清單。這所有的只是一個目標導向且公平的方法可以為一大疊求職信做排序來找出最有可能來你公司工作的候選人優先安排面試，然後決定他們是否值得錄取。記得這件事真的是非常非常重要：這些類別─熱情、只挑選少數公司、英文能力、頭腦、經過汰選、硬底子與多樣性─並不是雇用人的標準。做為標準這些都太不足了。有太多的優秀人才在考試中拿低分或差勁程式設計師在考試中拿高分。在你動紙去咆哮約耳如何認為你應該只雇用來自長春藤名校或約耳有某種成績情結，不論如何，重要的是瞭解這清單並不是雇用某人或拒絕某人的理由清單。這所有的只是一個目標導向且公平的方法可以為一大疊求職信做排序來找出最有可能來你公司工作的候選人優先安排面試，然後決定他們是否值得錄取。
Rick Chapman在尋找愚蠢 - Rick Chapman is In Search of Stupidity
Rick Chapman在尋找愚蠢 - Rick Chapman is In Search of Stupidity
如果你問我並讓我偏私的回答，我會說除非有個程式師掌舵，否則沒有軟體公司會成功的。到目前為止的證據都可以支持我。
不過這些要命的錯誤中有許多也是程式師搞出來的。Netscape重寫瀏覽器而不去改善原有的程式碼庫，這個不朽的神經病決定花了他們好幾個年的Internet時間，在這期間他們的佔有率由大約九成掉到4%左右，而這是程式師的點子。當然啦，該公司裡面非技術又無經驗的管理階層完全不知道這為什麼是個爛點子。還是有很多程式師為Netscape徹底重寫辯解。「舊的程式真的很爛耶，約耳！」是，嗯哼，這種程式師應該因熱愛乾淨的程式而被讚賞，不過絕對要禁止他們接近任何商業決策100呎的範圍內，因為對他們來說，乾淨的程式碼顯然比讓軟體出貨重要多了。
所以我會對Rick稍微讓步地說，如果你想要在軟體業成功，必須有一個完全瞭解並熱愛程式設計的管理團隊。不過這個團體也必須瞭解並熱愛商業。要找到對兩邊都很有天賦的領導者並不容易，不過只有這樣才能避免這些被Rick親切地列在書中的錯誤。所以讀吧，笑一笑。如果你的公司是某位豬頭在經營，就把履歷整理一下開始在Redmond(譯註：微軟公司所在)找房子吧。
如果你問我並讓我偏私的回答，我會說除非有個程式師掌舵，否則沒有軟體公司會成功的。到目前為止的證據都可以支持我。
不過這些要命的錯誤中有許多也是程式師搞出來的。Netscape重寫瀏覽器而不去改善原有的程式碼庫，這個不朽的神經病決定花了他們好幾個年的Internet時間，在這期間他們的佔有率由大約九成掉到4%左右，而這是程式師的點子。當然啦，該公司裡面非技術又無經驗的管理階層完全不知道這為什麼是個爛點子。還是有很多程式師為Netscape徹底重寫辯解。「舊的程式真的很爛耶，約耳！」是，嗯哼，這種程式師應該因熱愛乾淨的程式而被讚賞，不過絕對要禁止他們接近任何商業決策100呎的範圍內，因為對他們來說，乾淨的程式碼顯然比讓軟體出貨重要多了。
所以我會對Rick稍微讓步地說，如果你想要在軟體業成功，必須有一個完全瞭解並熱愛程式設計的管理團隊。不過這個團體也必須瞭解並熱愛商業。要找到對兩邊都很有天賦的領導者並不容易，不過只有這樣才能避免這些被Rick親切地列在書中的錯誤。所以讀吧，笑一笑。如果你的公司是某位豬頭在經營，就把履歷整理一下開始在Redmond(譯註：微軟公司所在)找房子吧。
雙元文化主義 - Biculturalism (Windons, Unix)
雙元文化主義 - Biculturalism
Unix文化重視對其他程式師有用的程式，而Windows文化重視對非程式師有用的程式。
--
我們寫程式究竟是為程式師還是為了一般使用者？除了這個問題之外其他的都只是詮釋。
--
因為可以進入程式庫除錯所以Unix比較好。因為張阿姨可以看到提示確認她的電子郵件真的送出去了，所以Windows比較好。事實上沒有誰比誰更好，他們只是擁有的價值不同：Unix的核心價值是製作有助於其他程式師的東西，而Windows則把製作有助於張阿姨的事視作核心價值。
----
Raymond說「典型的Unix文件會寫得簡潔而完整...這種風格假設讀者夠積極，可以推導未寫出的推論，並且有自信信任這些推導。小心的閱讀每一個字，因為一件事很少會講兩遍。」天啊，我認為他其實是在教年輕的程式師寫出更不人性的man說明文件。
這對一般使用者而言是絕對行不通的。雖然Raymond可能說這是「過於簡化的屈就」，不過Windows文化瞭解一般使用者不讀文件，即使不得不看也是愈少愈好，因此你必須不斷重複的解釋... 事實上在良好的Windows說明檔中，必須每個主題都能讓一般讀者直接看懂，不必先看懂其他任何的說明主題。
----
Unix的程式文化格外重視可由命令列呼叫的程式，這種程式可以用參數控制各種動作，其輸出可以擷取成一般機器可讀的純文字格弋。這種程式之所以會被重視式，是因為可以讓其他程式師輕易地整合進別的程式或較大的軟體系統中。舉個很小的例子，Unix文化中有一個Raymond稱之為「沈默是金」的核心價值，是說當程式成功地完成你所交付的事時應該不要有任何輸出。不管是在命令列輸入300個字元的命令建立檔案系統，還是建立並安裝了一套複雜的軟體，或是把載人火箭送到月球，全部都一樣。只要成功執行就不要有任何輸出。使用者看到下一個命令列提示就會推論一切正常。
由於你是為其他程式師寫程式，所以這才會是Unix文化的重要價值。就如同Raymond所說的：「喋喋不休的程式不太能和其他程式好好合作。」 相較之下在Windows文化中是為張阿姨而寫程式的，而張阿姨搞不清楚程式是因為執行成功而沒有任何輸出，還是因為出錯了所以無法顯示任何訊息，或是因為誤解你的要求而沒有輸出。
同樣的狀況，Unix文化欣賞保持文字介面的程式。他們不是很喜歡圖型介面，不過在純文字介面程式上漂亮地塗一層GUI口紅可以例外，另外他們也不喜歡二位元檔案格式。因為文字介面比較好用程式控制，而圖型介面除非提供其他機制(如內建腳本語言)，否則幾乎不可能用程式控制。我們在這裡又再次看到，Unix文化重視有助於其他程式師的程式，而這一點很少會是Windows程式設計的目標。
Unix文化重視對其他程式師有用的程式，而Windows文化重視對非程式師有用的程式。
--
我們寫程式究竟是為程式師還是為了一般使用者？除了這個問題之外其他的都只是詮釋。
--
因為可以進入程式庫除錯所以Unix比較好。因為張阿姨可以看到提示確認她的電子郵件真的送出去了，所以Windows比較好。事實上沒有誰比誰更好，他們只是擁有的價值不同：Unix的核心價值是製作有助於其他程式師的東西，而Windows則把製作有助於張阿姨的事視作核心價值。
----
Raymond說「典型的Unix文件會寫得簡潔而完整...這種風格假設讀者夠積極，可以推導未寫出的推論，並且有自信信任這些推導。小心的閱讀每一個字，因為一件事很少會講兩遍。」天啊，我認為他其實是在教年輕的程式師寫出更不人性的man說明文件。
這對一般使用者而言是絕對行不通的。雖然Raymond可能說這是「過於簡化的屈就」，不過Windows文化瞭解一般使用者不讀文件，即使不得不看也是愈少愈好，因此你必須不斷重複的解釋... 事實上在良好的Windows說明檔中，必須每個主題都能讓一般讀者直接看懂，不必先看懂其他任何的說明主題。
----
Unix的程式文化格外重視可由命令列呼叫的程式，這種程式可以用參數控制各種動作，其輸出可以擷取成一般機器可讀的純文字格弋。這種程式之所以會被重視式，是因為可以讓其他程式師輕易地整合進別的程式或較大的軟體系統中。舉個很小的例子，Unix文化中有一個Raymond稱之為「沈默是金」的核心價值，是說當程式成功地完成你所交付的事時應該不要有任何輸出。不管是在命令列輸入300個字元的命令建立檔案系統，還是建立並安裝了一套複雜的軟體，或是把載人火箭送到月球，全部都一樣。只要成功執行就不要有任何輸出。使用者看到下一個命令列提示就會推論一切正常。
由於你是為其他程式師寫程式，所以這才會是Unix文化的重要價值。就如同Raymond所說的：「喋喋不休的程式不太能和其他程式好好合作。」 相較之下在Windows文化中是為張阿姨而寫程式的，而張阿姨搞不清楚程式是因為執行成功而沒有任何輸出，還是因為出錯了所以無法顯示任何訊息，或是因為誤解你的要求而沒有輸出。
同樣的狀況，Unix文化欣賞保持文字介面的程式。他們不是很喜歡圖型介面，不過在純文字介面程式上漂亮地塗一層GUI口紅可以例外，另外他們也不喜歡二位元檔案格式。因為文字介面比較好用程式控制，而圖型介面除非提供其他機制(如內建腳本語言)，否則幾乎不可能用程式控制。我們在這裡又再次看到，Unix文化重視有助於其他程式師的程式，而這一點很少會是Windows程式設計的目標。
2014年3月10日 星期一
不用測試人員的五大(錯誤)藉口 - Top Five (Wrong) Reasons You Don't Have Testers
不用測試人員的五大(錯誤)藉口 - Top Five (Wrong) Reasons You Don't Have Testers
1. 問題是懶惰的程式師弄出來的。
2. 我的軟體放在網路上。即使有問題也馬上就能修好。
3. 客戶會替我測試軟體。
4. 有資格可以勝任的人都不想做測試人員。
5. 我請不起測試人員！
1. 問題是懶惰的程式師弄出來的。
2. 我的軟體放在網路上。即使有問題也馬上就能修好。
3. 客戶會替我測試軟體。
4. 有資格可以勝任的人都不想做測試人員。
5. 我請不起測試人員！
給資訊科系學生的建議 - Advice for Computer Science College Students
給資訊科系學生的建議 - Advice for Computer Science College Students
修要寫大量程式的課
(前略)
這個故事的教訓是資訊科學並不等同於軟體開發。如果你真的非常幸運，你的學校可能會有一套合宜的軟體開發課程，不過大概是不會有的，因為精英學校認為技職教育和犯人改過自新計劃才需要教導實務技能。只不過是寫寫程式而已，到處都可以學。我們可是耶魯大學，身負鑄造未來世界領袖的重責大任。你覺得 16 萬美元的學費是讓你來學 while 迴圈的嗎？你以為這是什麼？某個在機場旅館舉辦的騙人 Java 研討會嗎？哼。
問題在於我們並沒有真正的專門軟體開發學校，所以如果你想當個程式師，可能還是得主修資訊科學。這是個好的主修學科，不過跟軟體開發是兩回事。
不過如果你幸運的話，可以在資訊科系找到很多密集寫程式的課程，就像你可以在歷史系找到很多能學會寫作的課一樣。這些是最好的課程了。如果你喜歡寫程式，修 lambda 演算或線性代數這種不碰電腦的課時，有些地方搞不懂不必難過。去找那些課程名稱有 Practicum 的 400 等級課程。這些課用這個拉丁文只是想弄個漂亮的課程名稱，好瞞過那些愛跩文的屁管理階層。
----
給資訊科學系學生的七個免費建議（物超所值哦）：
在畢業前學會寫作。
在畢業前學會C。
在畢業前學會個體經濟學。
不要因為非資訊課程無聊就放棄。
修要寫大量程式的課。
別擔心所有工作都會外流到印度。
不管你做什麼，去找個好的暑期實習工作。
接下來是解釋，除非你好騙到只因為我叫你做就去做。萬一你真的那麼天真，那就再來一個吧：8. 自尊心受損時要尋求專業援助。
修要寫大量程式的課
(前略)
這個故事的教訓是資訊科學並不等同於軟體開發。如果你真的非常幸運，你的學校可能會有一套合宜的軟體開發課程，不過大概是不會有的，因為精英學校認為技職教育和犯人改過自新計劃才需要教導實務技能。只不過是寫寫程式而已，到處都可以學。我們可是耶魯大學，身負鑄造未來世界領袖的重責大任。你覺得 16 萬美元的學費是讓你來學 while 迴圈的嗎？你以為這是什麼？某個在機場旅館舉辦的騙人 Java 研討會嗎？哼。
問題在於我們並沒有真正的專門軟體開發學校，所以如果你想當個程式師，可能還是得主修資訊科學。這是個好的主修學科，不過跟軟體開發是兩回事。
不過如果你幸運的話，可以在資訊科系找到很多密集寫程式的課程，就像你可以在歷史系找到很多能學會寫作的課一樣。這些是最好的課程了。如果你喜歡寫程式，修 lambda 演算或線性代數這種不碰電腦的課時，有些地方搞不懂不必難過。去找那些課程名稱有 Practicum 的 400 等級課程。這些課用這個拉丁文只是想弄個漂亮的課程名稱，好瞞過那些愛跩文的屁管理階層。
----
給資訊科學系學生的七個免費建議（物超所值哦）：
在畢業前學會寫作。
在畢業前學會C。
在畢業前學會個體經濟學。
不要因為非資訊課程無聊就放棄。
修要寫大量程式的課。
別擔心所有工作都會外流到印度。
不管你做什麼，去找個好的暑期實習工作。
接下來是解釋，除非你好騙到只因為我叫你做就去做。萬一你真的那麼天真，那就再來一個吧：8. 自尊心受損時要尋求專業援助。
大麥克對原味主廚 - Big Macs vs. The Naked Chef
大麥克對原味主廚 - Big Macs vs. The Naked Chef
1. 有些事需要天份才做得好。
2. 天份很難複製。
3. 有人嘗試複製天份，要有天份的人建立規則讓普通人照著做。
4. 結果所得到的產品品質很低。
麥克不太高興。他請了一個大型IT顧問公司來建立系統。他請的IT顧問都很無能，只會一直講「方法論(Methdology)」，花了幾百萬美元還做不好一樣東西。 還好麥克找到一位真正聰明又有天份的年輕程式師。這個年輕人只拿了20美元和一塊披薩，一天內就把整個系統架好了。麥克高興得不得了，就把年輕的程式師推薦給所有朋友。 年輕的程式師開始大賺銀子。不久工作就多到做不完，所以請了一堆人來幫忙。厲害的人股票選擇權要太多了，所以他決定請些更年輕剛畢業的程式師來「訓練」六星期。 問題是「訓練」並不真的能產生一致的結果，所以年輕的程式師就開始建立規則和流程希望產生更一致的結果。幾年下來規則手冊愈來愈厚，不久就變成後一套叫做「方法論」的六冊巨書。 過了幾年，當初的年輕程式師現在已經成為巨大無能的IT顧問，帶著一本「方法論」和一堆盲從方法論的手下。即使方法論行不通的時候這些人還是硬幹，因為他們根本不知道其他方法。何況他們也並不是真有才能的程式師，只是受過六星期訓練，好心的政治學科系畢業生而已。 而這個新的巨大無能IT顧問公司也開始陷入困境了。他們的客戶都很不高興。於是又出現另一個新興的天才程式師把客戶都搶光，然後整個循環又重來一遍。
這個故事的教訓是？小心方法論。方法論可以讓每個人的表現都提升到不佳但可接受的程度，不過同時也會產生很多約束而激怒更多的聰明人。就我而言，有才華的廚師顯然不會樂於在麥當勞做漢堡，原因正是麥當勞的規則。是否如此IT顧問才如此吹噓他們的方法論呢？
1. 有些事需要天份才做得好。
2. 天份很難複製。
3. 有人嘗試複製天份，要有天份的人建立規則讓普通人照著做。
4. 結果所得到的產品品質很低。
麥克不太高興。他請了一個大型IT顧問公司來建立系統。他請的IT顧問都很無能，只會一直講「方法論(Methdology)」，花了幾百萬美元還做不好一樣東西。 還好麥克找到一位真正聰明又有天份的年輕程式師。這個年輕人只拿了20美元和一塊披薩，一天內就把整個系統架好了。麥克高興得不得了，就把年輕的程式師推薦給所有朋友。 年輕的程式師開始大賺銀子。不久工作就多到做不完，所以請了一堆人來幫忙。厲害的人股票選擇權要太多了，所以他決定請些更年輕剛畢業的程式師來「訓練」六星期。 問題是「訓練」並不真的能產生一致的結果，所以年輕的程式師就開始建立規則和流程希望產生更一致的結果。幾年下來規則手冊愈來愈厚，不久就變成後一套叫做「方法論」的六冊巨書。 過了幾年，當初的年輕程式師現在已經成為巨大無能的IT顧問，帶著一本「方法論」和一堆盲從方法論的手下。即使方法論行不通的時候這些人還是硬幹，因為他們根本不知道其他方法。何況他們也並不是真有才能的程式師，只是受過六星期訓練，好心的政治學科系畢業生而已。 而這個新的巨大無能IT顧問公司也開始陷入困境了。他們的客戶都很不高興。於是又出現另一個新興的天才程式師把客戶都搶光，然後整個循環又重來一遍。
這個故事的教訓是？小心方法論。方法論可以讓每個人的表現都提升到不佳但可接受的程度，不過同時也會產生很多約束而激怒更多的聰明人。就我而言，有才華的廚師顯然不會樂於在麥當勞做漢堡，原因正是麥當勞的規則。是否如此IT顧問才如此吹噓他們的方法論呢？
工匠技藝 - Craftsmanship
工匠技藝 - Craftsmanship
這個故事的教訓是修正一個1%的問題可能會用掉500%的工夫。這種狀況並不只軟體業會發生。敢這樣講是因為我現在就在管理這些建築工程。上星期我們的包商終於完成Fog Creek新辦公室的最後修飾工程。內容包括在前門安裝閃亮的藍色壓克力，旁邊圍著鋁框，鋁框上每20公分就鑲有一顆螺絲。如果你仔細看照片，會發現每片門都會被鋁框整個包住，當門關起來時，兩片直框會併排在一起。雖然圖上看不出來，不過中間鋁條上的螺絲幾乎但沒有確實對齊。差了大概有2公釐。負責這件事的木匠很小心的測量，不過裝鋁框時門是放在地上，並不是等好門裝好再當場裝的。所以等到要把門裝上去時，才發現螺絲並沒有對齊。
這或許並不罕見;;我們辦公室裡很多門的螺絲都沒有對的很好。問題是當洞鑽好之後，要重新修正的代價貴得離譜。由於正確的螺絲位置離原來的洞只有幾公釐，所以不能直接在門上再鑽一個，可能得把整個門換掉才能解決。這實在是很不值得。這正是另一個修正1%的問題會用掉500%工夫的例子，而且這也解釋了為何這世上很多人造物都是99%好而非100%完美。(不過建築師倒是不斷吹噓，說某些亞歷桑那州的高貴金屋裡每根螺絲都排得很整齊。)
這點出了軟體的一項特性，一項大部份人都視為工匠技藝的特性。當軟體是由真正的工匠製作時，所有螺絲都會對得整整齊齊..當你做些很罕見的事時，應用程式會表現得很聰明。作者會投入更多的工夫去正確處理特的狀況，而不光是讓主要的程式會動。即使要額外再花500%的力氣去處理1%的狀況也在所不惜。
工匠技藝當然是非常昂貴的。唯一負擔得起的方法就是針對大量的客戶開發軟體。很抱歉，不過保險公司開發的內部人事管理程式絕對不可能達到這種工藝的境界，因為就是沒有足夠的使用者來分散額外的成本。不過就套裝軟體公司而言，這種工藝境界可以讓使用者高興並提供長期的競爭優勢，所以我願意花時間並正確地執行。請容忍我吧。
這個故事的教訓是修正一個1%的問題可能會用掉500%的工夫。這種狀況並不只軟體業會發生。敢這樣講是因為我現在就在管理這些建築工程。上星期我們的包商終於完成Fog Creek新辦公室的最後修飾工程。內容包括在前門安裝閃亮的藍色壓克力，旁邊圍著鋁框，鋁框上每20公分就鑲有一顆螺絲。如果你仔細看照片，會發現每片門都會被鋁框整個包住，當門關起來時，兩片直框會併排在一起。雖然圖上看不出來，不過中間鋁條上的螺絲幾乎但沒有確實對齊。差了大概有2公釐。負責這件事的木匠很小心的測量，不過裝鋁框時門是放在地上，並不是等好門裝好再當場裝的。所以等到要把門裝上去時，才發現螺絲並沒有對齊。
這或許並不罕見;;我們辦公室裡很多門的螺絲都沒有對的很好。問題是當洞鑽好之後，要重新修正的代價貴得離譜。由於正確的螺絲位置離原來的洞只有幾公釐，所以不能直接在門上再鑽一個，可能得把整個門換掉才能解決。這實在是很不值得。這正是另一個修正1%的問題會用掉500%工夫的例子，而且這也解釋了為何這世上很多人造物都是99%好而非100%完美。(不過建築師倒是不斷吹噓，說某些亞歷桑那州的高貴金屋裡每根螺絲都排得很整齊。)
這點出了軟體的一項特性，一項大部份人都視為工匠技藝的特性。當軟體是由真正的工匠製作時，所有螺絲都會對得整整齊齊..當你做些很罕見的事時，應用程式會表現得很聰明。作者會投入更多的工夫去正確處理特的狀況，而不光是讓主要的程式會動。即使要額外再花500%的力氣去處理1%的狀況也在所不惜。
工匠技藝當然是非常昂貴的。唯一負擔得起的方法就是針對大量的客戶開發軟體。很抱歉，不過保險公司開發的內部人事管理程式絕對不可能達到這種工藝的境界，因為就是沒有足夠的使用者來分散額外的成本。不過就套裝軟體公司而言，這種工藝境界可以讓使用者高興並提供長期的競爭優勢，所以我願意花時間並正確地執行。請容忍我吧。
訂閱：
文章 (Atom)