joel on software大家應該比較熟悉了：

http://www.joelonsoftware.com/index.html

關于jeol，可以看下他的背景，耶魯大學，91年進入微軟，在excel組作為programmer manager，而且是在一線編程的，后來又經歷的一些公司，最后單干，他們的trello.com非常棒，幾個同事和我在用。

簡而言之，這哥們很hardcore，說的很多東西很不錯。

我讀的這個紙版的書《jeolOnSoftware》（http://book.douban.com/subject/1426838/）其實比較早了，中文翻譯版是05年出的。

這個書里的確有含金量高的地方，但是也有很多地方比較基礎，筆記加一些個人評論：

14 不要被太空架構師嚇到

jeol描述了這樣一群人，他們喜歡做很多抽象，以至于脫離了現實，作為理論很好，但是對于現實卻沒有意義，jeol稱之為太空架構師。

他們傾向于在大公司里面任職，只有這樣的公司才能供養這樣的身份巨高，卻對基本業務沒什么貢獻的人，喜歡為了創新而創新，喜歡搞革命，弄個大體系。。。。

這些東西的確是牛的，但需要踏踏實實的積累和卓越的能力。

這篇文章里，jeol更多的是吐槽，的確是，這樣的人本身常常在公司里面浪費公司的資源（高薪+引來的抱怨），如果跳出來指導項目開發，很可能把一個團隊的青春年華毀掉，遠離這些不腳踏實地的人吧。

吐槽之外，也不能一概而論的說抽象和革命性的東西都是不好的，畢竟我們還是時不時看見有革命性的東西發生，但是個人覺得一個是要尊重客觀事實和規律，腳踏實地，不要強求，更不要忽悠，做一個真正讓人尊敬的開發者。

15 fire and motion

這是一個軍事廣泛運用的基本策略，就是向敵人開火，敵人肯定要低頭，然后你可以趁著這個機會（在敵人不知道的情況下）搶占更有利的地方，但是你一定要移動，否則敵人知道你的地方，在你換彈夾的時候，就會反擊你。

這的確是一個很好的策略，在軟件競爭中常常用到，大公司會做這樣的火力覆蓋：你不用買我的產品，從更便宜的小公司買也可以，但是務必要保證支持xml/soap/j2ee否則你可要掛。于是小公司在談的時候就不得不調整自己的開發，支持本來不需要的這些特性，這樣自己的成本和速度的優勢就被削弱，而大公司則繼續前進。

或者大公司迫使你來跟隨，然后它自己來向有利的地方前進。

yeah, fire and motion.

18 二元文化

這個概括我很喜歡：unix是想讓程序員爽的系統，windows是想讓人民群眾爽的系統。

因此兩個系統有著很大的不同，應用場所也很不同。

反言之，你如果想做一個賣給大眾的東西，你就不能不顧大眾的需求，按著自己覺得酷的方式來做。

21 激勵

原來的題目是“重金獎勵害多利少”，我不是很認同，但是里面說的內容還是很有同感的。

講的是微軟excel團隊的愣頭青hr認為這些行業內最頂級的人才僅僅需要錢就可以驅動，他們設定各種獎項，然后向調戲幼兒園小孩（我覺得也很像耍猴）一樣去設立一個獎項，期望這些開發者能夠玩命，誰做的好就給誰。

微軟和jeol需要的人才肯定是vision驅動的，就像《魔鬼代言人》里面撒旦和羅麥斯首先談的是要干什么（統治世界xxx），然后大家達成共識了，沒什么好談了，羅麥斯才開玩笑的說我們談談money吧，撒旦哈哈一笑，說“that's the easy part”，這才是吸引頂級人才的方式。

對頂級人才用耍猴的策略，這樣那樣的原因，總是找一些不懂開發者的人來“激勵”開發者，而且這些manager們非常難有

22 不配備測試人員的5個原因

這個部分后面工作中還真有遇到對測試的重要性認識很外行的情況，不過這個也不是很大的問題，知道就好了，而且沒有發現這一點也不意外，尤其是在google宣稱程序員自己測試巨牛無比之后。

首先這是一個在實際生產中的客觀事實：

在微軟（我上一家游戲公司也如此）有著非常大規模很正規的測試團隊，以至于所有的問題都會被抓出來，然后干掉。

我在上一家公司驚奇的發現，最后游戲發售的時候如此的穩定，沒有bug，根本就不是程序員寫的那么完美，幾乎可以說就是測試團隊的功勞，龐大的測試團隊幾乎和開發團隊一樣大，從項目早期就開始有，一天天不間斷的測試，然后通過正規的bug數據庫，反饋給開發組，開發組再作為task分配給各個人。

測試團隊如同定海神針一樣，作為開發團隊的后盾存在，記得一次我做了一個巨大的改動，一次提交了狂加班一個月的很具顛覆性的改動，心里頗為不安（盡管我一再檢查了代碼，確認都ok，但是規模太大了，有過一定開發經驗的人都會知道，這里幾乎就一定會有問題，不太可能一次性通過），然后測試團隊針對這樣的改動，分配了較多的人，連續測了幾天，都ok，然后我就可以把心放下，回家睡個安穩覺了----定海神針。

測試團隊至關重要基于這樣的事實：

• 地球上不存在寫程序沒bug的程序員，而且一般我們所在的公司里面充滿了水平很一般的程序員，測試團隊是必須要有的，當然這個測試團隊可以是程序員自己，也可以是一個專門的測試團隊，但是必須要有。
• 測試并不是一個巨簡單的工作，好的測試人員的抓錯能力和差的相差很大，軟件越是復雜，這個越是大，作為最復雜的軟件之一：游戲，程序員的測試能力只能用很差來形容，簡言之，程序員自己的測試能力是不夠的。
• 客觀地說，程序的人力成本畢竟是要高于測試人員的，出于成本的考慮，也需要有專門的測試團隊。
• • 實際上，比較好的公司會做很多這樣的成本計算和控制，比如給程序員最好的機器配置，辦公室搬家的時候有專門的人來搬

所以邏輯很清楚了，必須要有測試，而且有專門的測試團隊是性價比最高的。 另外一個公司里面容易犯的錯誤就是測試人員的職業發展問題，如果測試人員只能止步于測試，那么可以想象，肯定是“流水的兵”這樣的情況，而我們需要的是有資深的測試帶著一個團隊的測試來工作，那么給測試人員有其他的發展空間是很必要的（比如轉成designer等等）
23 任務切換的代價 原標題是”任務換人有害無益“。 jeol談到同時做多個任務的代價要高于一個個做，這個論點在有一年的gdc上也有一個producer說過，因為我們的大腦就是這么設計的：單任務執行能力強，多任務執行能力差。 盡管有人有著很好的多任務處理能力，但是對于絕大多數來說，同樣的能力下，一個個任務完成是最高效的。 至于任務換人。。。那是最低效的事情之一了，除非必須如此，否則最好不要這樣。這里的飛機就多多了，說到這里，我覺得程序員最強者的一個重要元素就是能淡泊程序員典型的自我欲望，比如說在另外一個人接手的時候，會有一個傾向就是，如果按照前人的做法，就顯不出我牛了，然后潛意識里就要自己搞一套，在這樣的潛意識下，所以符合這個方向的東西就會被夸大，給項目組x個理由要重搞，或者自己直接重搞。 在《浪潮之巔》里面講到蓋茨對dos的支持，可以說是能夠超越程序員自我欲望的一個典型，不是很理想化的直接拋棄一個落后的東西，而是更加理智的去采取最合適的策略。

另外一個切膚之痛就是我現在經歷的引擎和游戲一同開發，美術團隊等待引擎工具的功能來產出，項目自己也有milestone的壓力，那么很多feature都是做到一個80分即提交，然后轉向下一個，有問題和改進的需要再回頭做。

這個是在”引擎和游戲需要一同開發“的大前提下的最優策略，但是相比引擎先行1年這樣的情況就有質的不同，這種情況下，完全可以更加深遠的設計，更加少的任務切換，和專注的實現。

24 重寫代碼

原標題是”絕不去做的事情，第一部“

里面寫了網景公司花了3年時間，重寫了他們認為很爛的代碼，結果導致錯過了大好的競爭機會，市場占有率直線下降（從%90到%4）。

嗯，對于這種案例我覺得也沒有太大意思，這么多年來，你可以找到通過重寫把自己弄死的，也可以找到重寫進而脫胎換骨的，這不是一個簡單的一概而論的”應該還是不應該“的問題。

比如我郵件的簽名檔就是carmack給abrash作序的一句話：

“Much heroic programming ensued. Several hundred thousand lines of code were written. And rewritten. And rewritten. And rewritten”.

在做網景這樣的公司戰略級重寫決定權衡的時候，起碼要有商業產品端的大局觀和技術方面的縱深思考兩方面的權衡，還是那句話，程序員需要超越自己作為程序員來思考問題才會得到一個正確的結果。

那么為什么程序員愛重寫呢，jeol提的兩點我很贊同：

• 程序員有一種做完美建筑師的傾向，其實這個傾向是程序員技術快速持續提升的重要價值觀，在作為純粹技術來說，非常好的一個特點，但是實際做產品的時候，就需要產品端的視野來平衡
• 閱讀代碼比寫代碼要困難的多，尤其是經過產品化的代碼，常常會很是”很丑陋“以至于閱讀和搞懂這樣的代碼非常的痛苦，重寫則爽多了

重寫為什么危險呢？

• 丑陋的代碼或許是必須如此
• • 它就是有那么多奇怪詭異的情況要處理，也就是你再寫一遍也差不多，同時你浪費了那么多時間
• 那些詭異情況，常常是在一開始寫的時候想不到的，然后實際測試或者上市的時候才發現的，然后才添加了，原始代碼的丑陋中蘊含了大量的通過測試（測試團隊或者用戶使用）才獲得特殊需求，而這種在一開始很理想化的設計的時候幾乎都是考慮不到，這部分極有可能要再走一遍。
• 如果和原始團隊水平大抵相當的話，那么重寫之后大抵也是類似的水準

那么不妨跳出”重寫“的這個局限，可以看出代碼如果能夠在設計和實現上更加的優美，在詭異需求的時候能夠有足夠的文檔和說明，這是多么重要的啊，一開始就把事情做對，那么就不會陷入”泥潭中的怪獸“的絕境，也不會給項目帶來”需要重寫“的危機，糟糕的代碼即便最后決定不重寫，也會大幅度拖慢項目進展。 一份能夠經過時間考驗的代碼，對初始的奠基人的要求是超極高的，務必要以虔誠謹慎的態度投入其中。
26&27 了解內部機制
這一部分的道理很簡單，但是我們極易因為懶惰而犯這樣的錯誤。 就是現在東西越來越大越來越復雜，越來越多的東西被抽象，但是要把東西用對用好（而不是隨便用用），你必須還是要懂的其內部的機制（這也隨著規模越來越大，變得越來越難了），而內部機制的比例規模就像冰山未露出的部分那么大。 比如STL，了解了其中的內存分配機制之后，你就很容易寫出不僅對，而且高效的實現出來。 游戲引擎也是如此。 最后jeol給了這樣的建議，如果你沒法找到一位你將要依賴的語言和平臺方面有幾年扎扎實實的實踐經驗的專家之前（套用引擎也適用），不要貿然啟動一個項目。
29 全能型管理團隊 jeol在這里列舉了大量事實，說明商業上很棒的人，但是對技術不懂的人，根本無法領導一個軟件公司。 同時如同網景公司（同時也讓我想起了idsoftware）這種，對技術很在行，但是商業方面很有欠缺的人也很難領導好一個公司。 盡管很難，但是這就是一個事實，要想讓公司發展的好，管理團隊就需要能夠很好理解并且喜愛技術和商業。

31 作為哼哈二將，只管去做事

這一章頗有意義，項目管理不只是項目負責人才能做的事情，做為底層的開發者一樣可以做很多，方法就是：只管去做就好了。

項目組里有這樣那樣的問題，但是你可以用你做事的正能量來影響項目組，先保證自己的事情完成，然后去做一些幫助項目組的事情（設置sourcecontrol，bug數據庫，寫一些文檔。。。）。

32 放權問題

如果下屬足夠強力可以信任，那么就交給他去做，否則要干預，單純說信任或者說控制都是不對的。

33，要好好設計

極限編程里面提倡的是不要過度設計，但是很多人歪曲成不要設計，上來搞起，不行再改。。。然后就倒霉了

要好好設計，就這么簡單

35，提防非自主開發綜合癥

這一章我覺得是這本書里最棒的一章，很精辟的談論了我們的常常會遇到的，而且是戰略級的問題：是自己來做還是使用別人的。

jeol給出的答案是（我也非常贊同）：

如果這個是你的核心業務，如果程序開發團隊能做好，或者不會明顯差，那么即便會耗費很大的精力，還是要保證自己來做。

這就是ue和ce里面的stl部分都自己來實現的原因，因為性能是engine的核心業務，而stl在性能和一些feature上的支持并不好，所以一些容器類要自己來實現。

而tree什么的對于ue并不是核心業務，那么使用第三方的speedtree未嘗不可。

究其原因就是，核心業務方面不只是要求能夠完成，而且有著非常高的要求，比如engine里面就要盡可能的快，效果好，開發效率高，這是真正定義你的價值的部分。

而重用一些第三方的東西，一般來說不會出現能夠完全滿足你的需求和質量要求的東西（否則你就沒有必要存在了），而你需要保持一個在漫長開發周期中，對核心業務的控制力和持續提升的能力，這只有你自己做才能實現。

當然如果自己搞不定，那還是多快好省的重用第三方的為好。

36 ben&jerry與amazon

這里談及了一個比較有意思的商業策略：

• 如果市場比較空，那么amazon這種使用大資金大投入去搶占市場的方式是比較好的
• • 市場比較空的時候，搶占市場最重要，投入的資源幾乎一定會有產出，時間才是最重要的因素，如果能用錢來換時間，那么就去做，比如核心技術人員要搬家，那么公司就應該雇人幫他搬，然后讓他把搬家的時間拿來工作
• 如果市場比較飽和，那么就要走ben&jerry公司的方式，一步一個腳印的去積累，先保證不死，然后去一點點擴大自己的生存空間

37 雞與蛋的問題 這個在手機上比較明顯的問題，系統要賣的多才會有人來給這個系統開發軟件，但是要有人開發軟件才會賣的多，這個雞與蛋的問題。 實際解決的時候jeol提到了其中一個方面，即兼容性。 在軟件開發過程中，對于不是相距很遙遠的軟件提供兼容性，可以讓你不至于失去很多用戶，進而能夠保持雞與蛋問題上的平衡。 實際中，蘋果的app store通過很棒的政策，吸引開發者來開發，進而和蘋果產品互相促進也很棒。
里面一個示例讓我印象很深刻，win95的內存機制更準確，但是當時流行的軟件simcity有一個bug，既是釋放了一個內存，然后又立即使用它，在原先的pre win95的系統的內存機制下可以，但是win95不行，于是ms就反匯編了simcity，然后專門提供了一個simcity的模式，這樣simcity愛好者在win95下也能很好的玩到simcity。 純技術上看，這簡直太下賤了，但是在商業行為上，意義重大。
40 公開源代碼的經濟因素 這里是一個微觀經濟學的一個定律：對產品的需求在其配屬品價格降低的時候提高了。 比如去海南的機票便宜了，那么去海南旅游的人就會變多，頂飯店的人也會變多一樣。 這就是為什么大公司會開發如此多的免費產品，ibm會大力開發eclipse，sony和微軟都會給游戲機提供免費的（當然還是比較粗糙）的游戲引擎雛形。

超越時代的技術 在讀這本書的時候，里面不停地提到為數不少的很超前的技術，但是都因為不適合當下結果終結了。 這就好像自然界的淘汰法則一樣，如果原始人突然有一群人變異，變成智力很發達但是體力不行，或者抵抗力不行，那么這種在幾十萬年后會成為寵兒的人就會被自然界因為抵御不了這樣那樣的危險而淘汰。 適者生存，就這么簡單！

總結

以上是生活随笔為你收集整理的《JeolOnSoftware》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。