《梦断代码》读后感 - 驱动，责任，交流，远虑
這三篇讀后感原來發布在我自己申請的域名 yishan.cc 上面，后來這個域名被墻了。
?
?(原文寫于2008年12月)
幾個星期前，我給《現代軟件工程》課的每一個團隊都發了一本 《Dreaming In Code》的中文版 《夢斷代碼》，要求寫讀后感。這本書講了這樣的故事：一群很有經驗的代碼牛人在先進軟件開發模式的指導下，沒有資金壓力，在更多大牛的帶領下，原計劃用一到兩年的時間開發出一個備受期待的個人信息管理軟件(PIM)，后來花了七年時間才完成這一創舉，但是已經無人喝彩。我是9月份讀的英文版，后來又翻閱了中文版，也有一些感想如下。
1)驅動
到底是什么驅動程序員和管理人員，測試人員長年累月投入到一個軟件項目中去？
有理論認為，傳統的軟件公司用工資，職位，績效考核等讓一群經過面試和培訓的人在嚴格定義的流程下一起工作(大教堂/Cathedral模式)。其實，用開源，社區，共享的模式會更好(集市/Bazaar模式)也許更好。正如在第26頁所說的 [所有頁碼都是指英文版]
… it maps an alternate universe for programming in which time is simply less important because the work is cooperative rather than corporate, the workers are all volunteers, and the motivation is fun and ego, not financial reward.? [p26]
這理論聽起來很好，但是我想起了兩個故事：
1) 美國的一個肥皂劇Seinfield里有一集，講了一個混混Kramer 熱心地加入了一家公司，義務打工，起初他的口頭幽默和熱情感動了團隊，領導委以重任，不料Kramer 根本沒法兒把事情做好。最后領導只好找他談話，Kramer 承認自己不行，他說- 但是俺是義務給你們打工的！ 領導說，對，這就是讓我們為難的地方。。。 項目中來了一位“義務打工的”，照理說，對項目只有幫助，而且別人是“義務”，你怎么好意思把別人趕走？
2) 我以前在西雅圖的時候參加過一個非營利組織，成員們都是有熱情為社區服務，而且義務付出。但是后來有些成員就逐漸找不到了，一些事情也不了了之。 由于大家都是義務貢獻，你沒法如何要求別人。
在Chandler 項目中，Andy Hertzfeld 就是這樣一個義務作貢獻的大牛。但是他也遇到了同樣的"志愿者問題" –
They don’t know whether to count on you or not. And because you’re not getting paid, there’s lack of control. [p167]
后來這位Hertzfeld 也拍拍屁股走人了，大家可以為 fun 和 Ego 一起工作，但是如果fun? 和 ego 都得不到滿足，或者，那motivation 也會急劇下降。
2)責任 和驅動緊密相關的，是責任 – Accountability.
在 Hard Drive 這本書中，講了這樣的故事 – 由于Windows 一再拖延，BillG 最后跟 SteveB 說 – 如果今年下雪之前Windows 還沒出來，你就別在這兒干了。 書中沒有詳細講 SteveB 回頭來又和他的團隊講了什么，但是第二天一個員工背著睡袋進駐了辦公室。
很多年以后，Windows Vista 也經歷了很長的拖延，在又一次宣布拖延之后，人們發現 Windows 團隊中一個赫赫有名的 VP 已經卷起鋪蓋走了。
我們回過頭來看，在Chandler 項目長達7年的拖延中，有沒有發生過各位項目管理者引咎辭職的事？ 好像沒有。 [有不少人離開，但是沒有人直接為項目延期負責]? 既然我上一次拖延沒有什么懲罰，那我為什么一定要拼了老命要避免下一次拖延呢？
在傳統意義上的軟件公司，如果項目延期，那項目原計劃的收入就拿不到，拖延的時間再長一些，員工就得走人，否則整個公司都被拖垮了。在“集市”，社區，共享的模式下，大家都是義務，大家都在玩票，大家都做貢獻，但是對最終項目不直接負責任，那到底誰負直接責任呢？
在《移山之道》 中，我講了下面的例子：
| 阿超：我今天在“頂球”網吧看到大牛他爹在下棋，圍觀者支招的不少，有的說上馬，有的說拱卒，有的說出車。大牛他爹一會兒招法就亂了，眼看局勢不靈了，圍觀者一哄而散，老崔后來也沒法，只好認輸了。 一個圍棋國手在一次重要的對局后，聽到旁觀者對棋局的進程有很多不同的看法，他也沒有過多爭辯，只是說：“無責任的旁觀者和有重大責任的當局者的看法自然是不一樣的”。 無責任的旁觀者在支招后，如果不靈，他可以面不改色地繼續支招，甚至可以給另一位對局者支招，不管最后誰輸誰贏，旁觀者隨時都能安心地離開，回家吃飯。有重大責任的當局者在走了損招或敗招之后，他很可能就要認輸下臺，丟掉比賽的獎金和頭銜。 |
我在清華大學的這一次《現代軟件工程》課，我發現有些學生好像不是特別投入，后來了解到，由于申請學校用的GPA只計算前三年的成績，第四學年課程的分數就和申請學校沒有什么關系了，所以比較“雞肋”。有一個同學說，如果這門課是在第三學期，那許多同學們會非常計較分數，排名。現在，只要能過就可以了。這也許解釋了不少項目中出現了“花最少的努力能過就行”的心態。
一個軟件團隊可以制定出動人的遠景/Vision， 但是如果大家沒有搞清楚驅動項目的各種因素和每個角色應付的責任，那Vision只是一句話而已。
時間和交流：時間對每一個人都是公平的，對每一個軟件項目也是這樣。
nearly all software projects require only 1/6 of their time for the writing of code and fully 1/2 of their schedule for testing and fixing bugs.? But it was rare project manager who actually planned to allocate developers’ time according to such a breakdown. [p17]
書中援引理論家的話說，最高效的軟件團隊規模應該是一個人，因為這樣就不用交流了。 隨著人數的增加，依賴關系的復雜，新手，老手員工之間的不同步，交流的成本會隨著幾何級數增加。在這里插播一個有獎竟猜：
| 當Windows 研發團隊在開發Windows 2000的時候，團隊內部每天有多少封e-mail 交流？ a) 90 b) 900 c) 9,000 d) 90,000 |
對每一個團隊成員來說，他/她不僅要完成手頭工作，還有報告自己的進展(通過email 或其他形式)，回答別人的問題，了解其他人的進展。每個人的時間都是有限的，那怎么能保證我們在應付所有的交流/溝通之后，能有時間完成“手頭工作”？
一個微軟的同事前兩天跟我說，他們最近沒寫什么代碼，集中精力做“planning” 去了，大家寫了很多PowerPoint，改了很多PowerPoint。然后給VP, General Manger 做了兩輪匯報，然后根據VP們的意見再修改，再匯報。。。 PowerPoint 的風格變得非常專業和花哨，但是他們仍然沒有完成Planning，進入實質開發階段。華麗的 PowerPoint 中的每一個條目，也需要花PM 很多時間才能寫明白，讓VP 了解，同時也要花一線dev/test 很多時間才能實現，但是VP，PM 和 Dev/Test 面對同一個條目，他們心里想的是同一回事么？
外部交流
在Chandler 項目中，幸運的是，他們沒有這么多VP 要匯報 (真正的VP? –? Al Gore 只露了一個小臉)，但是我注意到他們用于交流的時間也非常多。例如
Every day the developers shared a chat room via Internet Relay Chat (IRC) [p139]
1 internal and? 4 external email list set up.?
blogs, wiki’s…
這些都是花時間的！我看到團隊成員還要回復素未謀面的愛好者的各種問題(例如質問他們為何不用某某框架，等等)，當然這種透明度也滿足了很多人的好奇心，開源，社區的優點么。。。 另一方面，項目管理人員發現他們面對著大量的任務沒有時間完成。就像第一章 Doomed 的開篇就說到：
John is doomed,? he has 500 hours of work scheduled between now and the next release… [p11]
團隊中其他人也好不到哪里去。那在這種情況下，是花時間繼續參加各種討論，blog，提供透明度 (Transparency)，滿足大眾的好奇心，還是集中精力把自己“手頭的事” 搞定？我從書中沒有看到經驗豐富的管理人員這時候采取了什么措施。事實上，在產品發布之后，沒有證據表明，那些在IRC，Email，BBS 上發了很多議論的愛好者未必真正下載并使用你根據他們的意見開發出來的軟件。那這么忙于交流是為嘛?!
事實上，這么多交流和信息并不能幫助人們回答一個最重要的問題 –
What had each programmer accomplished in the past week, and what task was next? [p141]
我的故事 – 在MS Outlook97 發布之后，網上對這個V1 版本有很多意見，也有很多期待。 其中很多用戶在 NewsGroup (新聞組) BBS 上發表了強烈的建議，要求Outlook 支持直接閱讀 NewsGroup/BBS 的內容，當時只有Outlook Express 有這個功能。Outlook 的開發成員一度認為用戶的要求太強烈了，如果我們沒有這個功能，可能V2就會很不受歡迎 (幾個dev 已經做了一個初始版本)。 但是大家仔細分析后發現，在BBS上強烈發言的，就是那么幾個人，因為他們老用BBS，因此他們的需求特別強烈，并且好像聲勢浩大，但是別的大部分用戶根本就不上BBS，因此也沒機會表達意見。所以Outlook 決定不做 NewsGroup 的功能，一直到現在。
內部的交流
除了外部的交流，還有內部的交流，隨著一個人經驗的增多，會有很多其他人來找你，為大大小小的事咨詢你的意見。然而你自己也有無數的任務要完成，怎么辦？微軟的員工對這種情況也不陌生，微軟團隊允許一些人 “Go Dark”，他們可以關起門自己干活，敲門不答應，不回答一般的email，不參加會議等等。
據說很早以前，BillG 把開發OS/2 API 的任務交給了一個牛人，這位前輩接受任務之后，并沒有開新聞發布會，建立email distribution list, 或者QQ 群，而是掛了一個和下面類似的牌子在辦公室門外，把門一關，一個人悶頭開發去了。
??????????????? 不要打擾、投喂辦公室里的動物
我們知道交流很重要，但是軟件不是在QQ 群中交流出來的(當然，有人在QQ 群中交流別人寫好的軟件)，而是一些人一行行寫出來的。 這個過程需要集中注意力，避免打擾。在一個 “集市” 風格， “共享” 的開發氛圍中，如何能保證關起門來開發呢？
遠慮和近憂
Kapor 的團隊看起來非常重視“遠景”， 他們似乎沒有近憂 – 這也許是致命的。
他們對于軟件的基本架構/infrastructure 非常關心，例如對于存儲系統，它們提出了下列需求：[p103]
后來對于Data Storage，又有如下構想：[p109]
非常令人佩服的遠慮。 如果一個項目能同時實現其中3個目標，就已經能實用并吸引客戶，開始賺錢了。 但是Chandler 項目的同志們不滿足于只實現兩三個，他們要實現全部5個夢想。
一群牛人在 “沒有近憂，只有遠慮” 的條件下討論問題，最后只能議而不決。 在一次次延續到深夜的討論中，有人感慨 – "How is this night different from all other nights?" //[p110]
沒有近憂，或者說不用為近憂而負責 – “我們這個月的目標沒完成不要緊，但是我們的遠景一定要討論好”。 導致了項目不能收斂 – 一個項目的一個里程碑中，不確定的事情應該越來越少，bug 也越來越少，直到產品發布。
Making firm technical choices was hard in the absence of a settled design, and settling on a design was hard in the absence of a technical roadmap. [p150 – 151]
正因為大家沒有近憂，所以大家可以繼續等待，設計要等技術決定后才好做，而技術的選擇要等設計決定后才好開始。就這樣，大家折騰到2005年的時候，他們才從高瞻遠睹的遠慮的云端中下來，有了第一個腳踏實地的計劃：
But for the first time, at least, they could see they had a plan grounded in reality, rooted in estimates that … [p232]
Kapor 畢竟是聰明人，很多年以后，他說到了教訓：
We’ve consistently overinvested in infrastructure and design… [p342]
收斂的另一個特點是 – 做過了的決定，就要執行，不要反復。事實上，Chandler 團隊在很多決定上搖擺不定。 架構師Hertzfeld 度假回來，發現他帶領其他同事奮戰一個夏天得到的 Document Architecture 被扔到一邊，原來 Kapor 決定 “We’ll have to come back and realign things”? [p168]。 如果你是做義務勞動的 Hertzfeld，你還能做下去么？
回到 “遠景”， 我相信幾乎沒有合適的解決方案能滿足“遠景” 中的所有要求，很難找到 “多快好省” 的解決方案(書中提到 fast|cheap|good 不能兼得，這也是MSF 中 time | resource | feature 三個元素的矛盾)。但是往往存在若干方案，從不同的角度逼近最優，但是有各自令人討厭的缺點。我們能否有智慧來選擇這樣一個方案，把近憂，遠慮都慢慢解決？
我自己在微軟正在做一個創新項目，前幾天一位加入這個項目不久的優秀的開發人員對我說，我們去年設計的數據庫問題太多了，如果我們早就像我這樣設計，估計會好很多。我不是數據庫的專家，我只能對他說，如果我們當時堅持要做到今天這樣才發布，這個項目也許就做不到今天了。
換句話說，正是因為早期那些不完美，但是及時的設計，讓后來者有挑剔這些不完美的奢侈機會。
我們每個人在使用這些不完美的軟件(Windows, Outlook, 甚至Linux)的時候，都應該感謝當初設計者做出了正確決定，而那些堅持完美設計遠景的項目，它們都到哪去了？
創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的《梦断代码》读后感 - 驱动，责任，交流，远虑的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： php oci 11g.dll下载,Or
- 下一篇： 现代软件工程 教学计划 适应两种难度和