上個周末讀了史鐵生的《我與地壇》，對他的北京話印象深刻。北京方言和河北方言差不多，讀他回憶的那些故事，不覺間想到了自己的童年。摘錄其中的幾段暫作為讀書筆記吧。

我的夢想

• 也許是因為人缺了什麼就更喜歡什麼吧，我的兩條腿一動不能動，卻是個體育迷。
• 我希望既有一個健美的軀體又有一個了悟人生意義的靈魂，我希望二者兼得。

好運設計
史鐵生20歲時雙腿癱瘓，很不走運。所以他常常在床上想如果有來世，自己會有一個什麼樣的命運。他設想了一個完美的命運，一個完美的人，最好生在一個普通知識分子家庭。在鄉下不好，在貴府名門也不好。下面這段對於生在農村的我來說感觸很深。

• 降生在什麼地方也是件相當重要的事。二十年前插隊的時候，我在偏遠閉塞的陝北鄉下，見過不少健康漂亮尤其聰慧超群的少年。當時我就想他們要是生在一個恰當的地方他們必都會大有作為，無論他們做什麼他們都必定成就非凡。但在那窮鄉僻壤，吃飽肚子尚且是一件頗為榮耀的成績，哪還有餘力去奢想什麼文化呢？所以他們沒有機會上學，自然也沒有書讀，看不到報紙電視甚至很少看得到電影，他們完全不知道外面的世界是什麼樣子，便只可能遵循了祖祖輩輩的老路，日出而作日入而息，春種秋收夏忙冬閑，日復一日年復一年。光陰如常地流逝，然後他們長大了，娶妻生子成家立業，才華逐步耗盡變作純樸而無夢想的漢子。然後，可以料到，他們也將如他們的父輩一樣地老去，惟單調的歲月在他們身上留下註定的痕迹。而人為什麼要活這一回呢？卻仍未在他們蒼老的心裡成為問題。然後，他們恐懼著、祈禱著、驚慌著聽命於死亡隨意安排。再然後呢？再然後倘若那地方沒有變化，他們的兒女們必定還是這樣地長大、老去、磨鈍了夢想，一代代去完成同樣的過程。或許這倒是福氣？或許他們比我少著夢想所以也比我少著痛苦？他們會不會也設想過自己的來世呢？沒有夢想或夢想如此微薄的他們又是如何設想自己的來世呢？我不知道。我不知道。我只希望我的來世不要是他們這樣，千萬不要是這樣。

記憶與印象1

• 故事有時候是必要的，有時候讓人懷疑。故事難免為故事的要求所迫；動人心弦，感人淚下，起伏跌宕，總之它要的是引人入勝。結果呢，它僅僅是一個故事了。一些人真實的困苦變成了另一些人編織的愉快，一個時代的絕望與祈告，變成了另一個時代的瀟洒的文字的調遣，不能說這不正當，但其間總似拉開著一個巨大的空當，從中走漏了更重要的東西。

這段其實是說史鐵生的「姥爺」，一個國民黨抗日軍官，在「解放」時被小人算計，最後被執行槍決。他說這其中必定隱匿著一個故事，悲慘的，或者竟是滑稽的故事。但他不想去考證，不想讓這成為一個故事，一個供後來人消遣的故事。

記憶與印象2

• 模仿電影里的行動，是一切童年必有的樂事。...... 因而，曾有一代少年由衷地嚮往那樣的烽火硝煙。（「首長，讓我們上前線吧，都快把人憋死了！」 「怎麼， 著急了？ 放心，有你們的仗打。」）是呀，打死敵人你就是英雄，被敵人打死你就還是英雄，這可是多麼值得！故而衝鋒號一響，銀幕上炮火橫飛——一批年輕人撂倒了另一批年輕人，一些被懷念的戀人消滅了另一些被懷念的戀人——場內立刻一片歡騰。
• 我獨自看那「編劇」後面的三個字，早已懂得：有為，與愛情，原是風馬牛不相及的兩個領域。但暫時，亦可在心中長久，而寫作，卻永遠地不能與愛情無關。

想念地壇

• 再看那些老柏樹，歷無數春秋寒暑依舊鎮定自若，不為流光掠影所迷。我曾注意過它們的堅強，但在想念里，我看見萬物的美德更在於柔弱。...... 柔弱，是信者仰慕神恩的心情，靜聆神命的姿態。...... 但要是「愛」也喧囂，「美」也招搖，「真誠」淪為一句時髦的廣告，那怎麼辦？惟柔弱是愛願的識別，正如放棄是喧囂的解劑。

讀這部分的時候，突然想到某人的溫柔。我想，溫柔也是一種很難得的美德吧。

• 寫，真是個辦法，油然地通向著安靜。寫，這形式，註定是個人的，容易撞見誠實，容易被誠實揪住不放，容易在市場之外遭遇心中的陰暗，在自以為是時回歸零度。把一切污濁、畸形、歧路，重新放回到那兒去檢查，勿使偽劣的心魂流布。

我想，不僅是寫，讀也是這樣。讀到文中幾段反思自己的惡的部分，我看到了自己曾經的虛偽。很多事，並不因為沒有人追究你，你就能逃脫懲罰。也許在某個午後，往事會一幕幕襲來，醜陋的內心暴露在陽光下，痛苦與悔恨充斥心間，而你卻什麼也做不了。借用《一個女孩》中的一句話：當你無法說抱歉的時候，你的錯誤就變成肉中刺。

希望在這個浮躁的世界，仍然能做一個真誠的人，誠實的人。… Read the rest

抽空把《人月神話》複習了一遍，回顧自己近期的工作，想對書中的一些觀點談談自己的感受。

1. 編程行業「滿足我們內心深處的創造渴望和愉悅所有人的共有情感」，其提供了五種樂趣：

   • 創建事物的快樂；
   • 開發對其他人有用的東西的樂趣；
   • 將可以活動、相互嚙合的零部件組裝成類似迷宮的東西，這個過程所體現出令人神魂顛倒的魅力；
   • 面對不重複的任務，不斷學習的樂趣
   • 工作在如此易於駕馭的介質上的樂趣——純粹的思維活動——其存在、移動和運轉方式完全不同於實際物體

   最近公司接了一個活，目標是把一個windows上的軟體產品做成跨平台的，也就是windows和mac。僱主那邊寫了一個類似於WPF的框架，目前需要我們把原來用MFC寫的界面換成用他們的框架寫成的界面。寫了2天之後我發現這個工作大部分是體力活。首先你需要把原來的界面用他們的框架畫好，就跟寫WPF界面差不多。然後把原來界面中的邏輯重新實現一下。因為沒有文檔，全靠參照前期領導寫的代碼和問同事，所以寫得比較累。繼續寫了幾天以後，感覺這個東西沒有給我帶來任何成就感。我覺得我成了流水線上的工人，原來編程帶給我樂趣都不存在了，有的只是重複和被push的壓力。原來覺得編程是一種腦力勞動，現在發現在你掌握了一定的技術基礎之後，有些事情就變成了體力勞動。對於這種工作，我的態度是按時上班，按時下班，不付出額外的勞動。因為我覺得這個工作不值得我付出哪怕多一點的精力。它對程序員而言是一種痛苦。加班加點地做這種痛苦的事只會使自己逐漸喪失對編程的樂趣。所以我一直在自學一些覺得有意思的東西，始終讓自己保持對編程的新鮮感。我知道我還要寫幾十年的程序，保持興趣才能讓我不斷進步。

2. 所有的編程人員都是樂觀主義者，「一切都將動作良好」。
   這個是我感受最深的一點。從我非常有限的編程實踐中，我發現從project manager到一線程序員，普遍都對進度做了過於樂觀的估計。書中提到了幾個點說明為什麼進度常常不是按照我們估計得那樣進行。

   • 由於編程人員通過純粹的思維活動來開發，我們期待在實現過程中不會碰到困難。但是我們的構思本身是有缺陷的，因此總會有bug.
   • 圍繞著成本核算的估計技術，混淆了工作量和項目進度。人月是危險和帶有欺騙性的神話，因為它暗示人員數量和時間是可以相互替換的。
   • 在若干人員中分解任務會引發額外的溝通工作量——培訓和相互溝通。

   做樂觀的進度估計很多時候來自於客戶或者僱主的壓力。項目經理會受到來自於客戶的壓力，一線開發者又會受到同事和項目經理的壓力。然而實際完成的時間並不會由於估計的時間少就會早完成。從實際來看，我完成的時間一般都是領導估計時間的3倍左右。我覺得我領導估計時間更多地考慮了代碼變動所花的時間，而忽視了其它活動所花的時間。因此實際完成時間和預估時間相差比較大。

3. 目標上（和開發策略上）的一些正常變化無可避免，事先為它們做準備總比假設它們不會出現好的多。
   程序員都希望需求是一成不變的，可是實際項目的需求往往一變再變。來公司3個月的時候，領導給了我一個小需求。要求在原來的界面上加幾個控制項，本來位置和個數寫死就行了，後來變成了控制項類型和數量都可以動態變化，控制項位置也要動態改變。我原來實現的時候，只用了一層抽象去實現，這樣實現起來可以滿足需求，但可能很難應對變化。領導建議我把控制項分組，增加一層抽象。後來僱主又要求控制項布局也要動態變化，我才想到領導的先見之明。提前想想可能出現的需求變化，在前期適當增加一些抽象，往往可以更容易應對以後的需求變化。當然這個其實要求你對業務比較熟悉，能夠對可能的需求變化做一些預測。後來我想寫出好的軟體除了需要精通各種技術之外，還需要熟悉業務，不熟悉業務很難做出有價值的決策。

4. 缺陷修復總會以20%~50%的幾率引入新的bug.
   在不斷的改bug過程中，我越來越覺得這是真理。因為改bug需要你先理解原有的邏輯，對於老項目而言，特別是沒有文檔的老項目，理解它一個模塊的各個邏輯是比較費力的。有時候你覺得你理解了它原有的邏輯，但你可能忽略了其中一個case，於是你的這次改動就引入了新的bug. 很多時候也是由於面前工期的壓力，你沒有時間完全理解原有的邏輯，只想快點解決這個比較嚴重的bug。這些都是導致新bug的原因。

5. 即使是完全開發給自己使用的程序，描述性文字也是必須的，因為它們會被用戶——作者遺忘
   這條說的是文檔的重要性。就我現在做的項目而言，是美國的外包項目。美國那邊很重視文檔，一開始就把詳細的需求說明書（或者叫規格說明書）寫好，並在以後根據情況隨時更新。這樣開發做起來就完全清楚要做什麼功能，把功能具體做成什麼樣。原來待過一個月的A公司，經常是領導口頭交待任務，具體做成什麼樣領導自己也不清楚，靠自己去問其他人，沒有任何規範。我很難想像它這個項目能維護下去。現在做的這個項目已經有20多年的歷史了，仍然能夠維護下去，我覺得文檔是很重要的一點。有什麼問題，先看看原來的文檔是怎麼定義功能的，這樣很多東西都有據可查。另外一點，代碼中的注釋也是極重要的，特別是針對特定case所寫的代碼，一定要寫上注釋，否則後面維護的人可能就倒霉了。在這一點上，我覺得我的領導給我做了很好的示範。通過他的code review，我逐漸明白了何時注釋以及怎樣寫好的注釋。

6. 在未來的十年內，無論是在技術還是管理方法上，都看不出有任何突破性的進步，能夠保證在十年內大幅度地提高軟體的生產率、可靠性和簡潔性。
   這是Brooks博士最重要的論點。他認為軟體開發中最主要的困難是規格說明、設計和測試這些概念上的結構，而不是對概念進行表達和對實現逼真程度進行驗證。軟體開發中有一些無法避免的內在特性：複雜度、一致性、可變性和不可見性。正是這些內在特性導致了軟體開發的生產率不會得到大幅度的提高。在他論文發表後的幾十年時間裡，軟體開發領域出現了很多新的語言、工具、程序庫，但這些只解決了軟體開發中的一部分次要困難。
   不過，Brooks博士也提出了一些解決主要困難的方法。其中一個是需求精鍊和快速原型。需求精鍊是說，必須與客戶進行深入的溝通，明確化客戶需求中模糊的部分。但即使這樣客戶還是會有很多地方無法精確表達自己的需求，而改變傳統的軟體開發流程可能對解決這個問題有很大幫助，即快速原型。首先系統應該能夠運行，即使未完成任何有用功能，只能正確調用一系列偽子系統。接著，系統一點一點被充實，子系統被輪流開發，或者在更低的層次調用程序、模塊、子系統的佔位符。這種方法要求自上而下的設計，因為它本身是一種自上而下增長的軟體。
   讀完這個論點，我還是有點雲里霧裡的。可能是經驗太少，做的只是一小塊，所以感觸也不多。

最後，想用書中的一段評論來結尾，送給國內的開發者：
現實世界中的管理就是在更大程度上以人員的生命為代價，讓他們更努力、更長時間的工作。經理們總是不停地吹噓他們的人員的加班時數和能從這些人身上榨取更多時間的小把戲。這種情況下，開發產品的質量一定會下降，甚至慘不忍睹，因為開發人員唯一能控制的是質量，當他們不得不犧牲質量，痛苦地面對自己的工作，踐踏工作的樂趣時，可以想像項目成本會大大增加，並且項目的發布往往伴隨著一大批程序員的倒下。… Read the rest