其他

 在軟體這個行業裡，怕是沒有任何一個其話題域像開發語言這樣引起爭議了。對開發語言是非的爭論，不單曠日持久，且深度亦是與時俱進。 實現要強調下的是，在這裡我們要專註的是開發語言的選擇而非開發語言的優劣。 從不同的視角對開發語言進行選擇，其結論可能大相徑庭。 從項目的角度看，語言自身特性的多少，強弱往往並不成為一個關鍵選擇因素。好比說某語言支援多重繼承，而某語言不支援多重繼承，但對大多項目而言多重繼承這一語言特性並不成為選擇的決定性因素。從項目角度看，某些通常被考慮(或不得不考慮)的因素有：  曆史

眾所周知，領導與管理意義不同，領導者要決定的是未來的走向和基本的原則策略。管理者則要使用具體的手段，達成既定的目標。但現實中的管理上的問題往往並不只類似於數學，只需要計算和推理，而更類似於社會學，需要許多判斷，這也就意味著做管理的時候最終會涉及導向性的問題。 軟體項目的管理尤其如此。 建造一棟房屋和構建一個軟體，其不同在於建造房屋的工人需要的是按照設計圖紙嚴格執行，因此紀律要比文化重要。但在軟體開發過程中，由於工作和概念與邏輯相關，現場幾乎就是一切，如果程式員被定位為被動執行者，那麼一切創新和改

很多年來始終有一種聲音：編碼自身會逐漸消亡，軟體開發會越來越像一種組裝工作。也就是說，程式員會越來越像IT工程師，他們很少自己從頭做什麼，而是靠搭配來達成各種目標。 我身邊就有持這種觀點的人。 而在《代碼整潔之道》一書中，Robert C Martin在開篇處加了這樣一段文字：有人也許會以為，關於代碼的書將有點落後於時代---代碼不再是問題；我們應當關注的是模型和需求。確實有人說過我們正在臨近代碼的終結點。很快，代碼就會自動產生出來，不需要再要人工編碼。.... ...這段文字告訴我們編碼會逐漸

對於軟體而言，層次是讓人又愛又恨的東西。 很多問題是通過增加層次解決的，但另外一部分問題也是因為層次而匯入的。我們來分別看幾個例子。 例1：很多時候我們並不希望最終的應用綁定於某個指定平台，比如:Windows。為了達成這種跨平台的目的，就需要在OS和應用之間加入一個中介層，這個中介層負責屏蔽不同OS的差異。實際上，Java虛擬機器等走的都是這樣一條路線。 例2：當使用XML檔案儲存配置資訊的時候，我們並不希望XML的結構在整個程式中隨處可見。比如說：現在我們在Configuration/Out

雖然Code Review經常被提及，但就我個人感覺（一半從別人的部落格，一半個人經曆），Code Review的實際境況大多時候還是比較難看的。更多時候，Code Review很像被存起來的酒，用的時候拿出來看看，證明有這東西，但大多時候是不用來喝的。 細究成因可能是來源於兩個方面：一是時間壓力太大。軟體開發裡可以安全打折扣的地方其實不多，文檔不寫很容易被看出來，代碼不寫程式就動都不動了。沒辦法下，很多時候就只好拿Code Review開刀。畢竟Code Review裡少看兩眼，多看兩眼，用多

恰如標題，第二定律表示為：在思維可以精確量化前，量化管理在程式員身上永無可能。 這次估計會有爭議，所以這裡給出具體的邏輯鏈以及對應的分析。 邏輯鏈： 軟體是一種固化的思維 →思維的本質是概念和邏輯 → 概念和邏輯無法直接度量和精確度量 → 度量過程中需要很多的主觀判斷 → 以目標為導向的，個人中心的量化管理（相關的激勵和懲罰）將崩潰  具體分析：  公平公正是管理的基石，為達成這一目的很多人會想到量化管理，但量化管理的基石卻往往被忽略。 對人進行量化管理的基石是：量化後的數字主要受個人表現這一個

在MBA的課程中有一門是組織行為學，就我個人感覺專案管理者別的科目不看也罷，組織行為學這門還是看看比較好。組織行為學被定義為這樣一種研究領域：探討個體、群體以及結構對組織內部行為的影響。通俗的講就是研究一個人的行為規則，比如人的需求層次會如何影響動機，又會如何影響人的行為。餓的要死的人，是不適合總談理想的。研究一個群體的行為規則，比如從眾心理如何產生以及如何預防。研究組織圖對個人行為的影響，比如官僚的體繫結構下和矩陣體繫結構下，人的行為會不同。 上面這些東西無疑的是對專案管理有意義的。 對專案管

有時候正工作呢，突然就會聽到兩個兄弟聲音放大，言辭也開始變的激烈。這事兒實在太常見，以至於不需要具體案例大多數人就能想象到是怎麼個情境。現在的關鍵問題是這個時候經理M應該幹點什嗎？  我個人感覺，有兩種極端的處理方法一定不太行。一是完全置之不理，就是假裝沒看見，你們吵成什麼樣算什麼樣。一是什麼事都管，一有爭吵就開始調解，消除所有不“和諧”聲音。前者比較失職，工作中，人員間矛盾大多與工作有關，完全不處理必然影響到工作，所以即使單純從對工作負責的角度看，這也是種失職。後者會顯的過於婆婆媽媽，大家都是

自從《贏》，《基業長青》這些書出了之後，只要是個人，只要他還做管理都會關注文化這個事。這是對的，但關鍵是在這個事上不能走形式，不能在管理中做虛情假意的文化建設。 不知道提到文化這事，每個人會對應到什嗎？可能有的人會想到宣講，有的人會想到集體活動（喝酒，唱歌，旅遊，培訓等），有的人會想到挂圖，曆史展示等。但事實上這些手段更類似一種枝節，如果沒有一個核心支撐，那就很容易變成虛情假意。這個核心支撐就是：你能很清楚的回答你的部下，你的員工在三年（或多年）後它可能得到什麼嗎？你能很清楚的回答你的部下，你的

對於特定的人，在大致時間段裡他所能寫的、確定品質的代碼基本上應該是個確定值。這點似乎顯而易見，但事實上大多時候卻總是被忽視。如果項目負責人總是認可上面的基本點，那麼任何項目的議程就應該以此為前提，而不是以此為變數。假設說一個項目被估計為1萬行(SLOC)，團隊平均每人每天可以寫100行代碼，如果團隊中有5個人，那麼就應該至少為編碼保留20整天。 說到這裡，為避免誤解，要區分一下編碼速度和生產率這兩個概念。專案管理中常用的一個資料被稱為生產率，用程式碼計算時，會被表示為SLOC/MM。這個值用於表

程式員由於天天和邏輯打交道，所以在世故的人眼裡往往顯得過於簡單。近來看組織行為學，發現其中一節列了很多特別的技能。考慮到也許他們對程式員群體很有啟示意義，就追加了一點說明，把它放在部落格裡。相信這對想成為管理者的程式員是有意義的。我個人的觀點很簡單：一個人可以拒絕厚黑和莫名其妙的複雜，但也不能被人認為是傻蛋。從這個角度看，把這個記下來是有點意義的，當然把這個的優先順序抬到基本技術技能之上就走火入魔了。 組織行為學裡管下面這些叫做權術手段，但實際上這也是協調各方力量的一些方法。 合法性。強調自己的

我們必須承認技術和管理所面臨的問題、所需要的性格和能力皆是不同。雖然有的時候管理也被認為是一種技術，但我們更願意把直接貢獻於軟體產品的工作稱之為技術，而把通過協調溝通等手段間接貢獻於軟體產品的工作稱之為管理。 從先天性格來看，有的人天生適合做管理多一點，有的人天生適合做技術多一點。 比如說：有的程式員天生有點被動，不喜歡主動學習很多東西，不喜歡與人溝通，但對工作所直接關聯的領域研究較深，做事情兢兢業業，一絲不苟。 有的程式員生活的比較被動，安排的事還能努力去做，但很難主動去做什麼。有的程式員非常

在1992年，Jack W.Reeves發表了一篇名為：Code as Design的文章，這篇文章可以在《敏捷式軟體開發 (Agile Software

剛畢業不久的程式員往往非常期望成為專案經理，主要原因應該是感覺專案經理收入等會遠好於碼農。所以很多人會去總結如何成為專案經理，看起來點擊率也還不錯。  這大致上沒錯，相信在未來相當一段長時間裡也不會有什麼改變，相當於程式員群體裡的“官本位”。本質上看，這是軟體層次所限制的，很微妙，這次不談。  但這裡面有一個陷阱，有志於成為專案經理的人要預Crowdsourced Security

寫物件導向設計原則的文章很多，但在我看來物件導向的一些原則是雖然是對的，但不夠精練。大多面向原則其實可以用三個支撐點推匯出來：確保正交，控制層次，資訊隱藏。這一篇裡談一下確保正交性。 抽象是設計工作的起點，而抽象的結果可以是一個具體的概念，也可以是一段邏輯。正交性則與抽象的結果有關聯。為了理解正交性，我們先來看一下這個詞的幾何解釋： 當兩根直線互相垂直的時候，我們認為這兩根直線是正交的，否則的話這兩根直線就是不正交的。 這似乎和軟體沒什麼關聯。但如果我們假設相交的不是兩根直線，而是兩根圓柱的話，

引子這兩天讀了李彥宏先生給內部員工的內部郵件，感覺應該是真的，所以稍微做點評價。郵件有三個要點，並不複雜：提倡面對變化、反對小資呼喚狼性、減少管理層級。 這三者間應該是因果關係，因為要面對變化，所以反對小資，小資沒有戰鬥力。因為要激發狼性，所以要減少管理層級，提升效率。 簡評單純從邏輯上來分析，這封郵件提倡的東西是會失敗的，李彥宏先生髮現了問題但解題思路很可能偏了。什麼是狼性，狼性也許表現為敏銳的嗅覺、不屈不撓奮不顧身的進攻精神，群體奮鬥，但其根本驅動則是生存所面臨的巨大壓力。生存威脅是所有狼性

大多情況下，並行對複雜度影響過大，並間接導致測試困難---多線程或多進程導致的問題往往是有時發生，有時不發生，一般的測試手段並不足以發現這類問題。所以原則上應該儘可能不用，除非收益足夠大。或則說在滿足需求的前提下，線程數和進程數應該儘可能少。 以多線程和多進程而論，確定“什麼時候適合使用這種技術”是比“怎麼使用這項技術”困難的多的事情。現實中人們往往對事件，號誌等同步處理手段關注過多，而對究竟應不應該啟用多線程/進程關注的太少。這裡來簡單做個總結，對於下面這些情境，一般來講啟用多線程/進程是合適

要想做好管理先要理解相應群體的動機，所以管理者要大致知道一點動機理論，要不然就只能呼喚狼性了。 《組織行為學》這本書很有意思，說動機理論前，先攻擊金胖子。說尊敬的領導（即剛去世不久的金胖子）通常被認為有點瘋狂，比如他會綁架韓國電影導演或者日本人，可這是為什麼呢？作者認為首先是享樂主義。金胖子喜歡所有最新的玩具和小玩意，讓廚師去東京學習世界上最好吃的壽司的做法，到伊朗學習魚子醬的做法，到新加坡學習番木瓜的做法，到哥本哈根學習熏肉的做法，吃米飯前，大米要一粒粒被檢查並去除殘渣等等。其次是恐懼以及對安

在軟體這個行業裡有些規則是很有殺傷力的，比如很有名的摩爾定律。總結出這些規則的意義在於可以大致的照明方向，免得努力來努力去卻走到了陰溝裡。現實中種種利益紛爭、觀點之爭看似紛繁，但在大時間尺度下來看卻都是規則的實現手段。這就好比下圍棋，每一手都要為謀得利益而計算，但結局卻只有三種：贏、輸或和，這就是規則的力量。 民以食為天，所以第一定律從收入開始。 程式員第一定律可以表述為：程式員的收入是技能複雜度和技能實現可能程度的函數。如果程式員的工資是S，社會平均水平的工資為A，程式員掌握的技能複雜度為C，

經常有小同事和我說，這程式的代碼寫的太垃圾了，什麼水平。確實如此，大部分持續存在一段時間的程式碼品質都不怎麼樣。從循環複雜度的角度看，超過15的代碼就很看了會頭疼了，但可怕的是循環複雜度到70,、80的也不是沒有。誰要攤上改這種代碼，估計上吊的心都有：不改不行，改了誰知道出什麼問題？ 從這種代碼裡能看出來什麼，很說明的人的心境。說看到技術水平較差的大多是剛畢業的兄弟。說看到利益糾葛，人心世道的大概就是成年老鳥了。 我持後一種觀點。 為什麼世界上會有這麼多垃圾代碼，這絕對不只是因為技術不行。如果世