http://dtslob.spaces.live.com/?_c11_BlogPart_BlogPart=blogview&_c=BlogPart&partqs=amonth%3d12%26ayear%3d2008

Dreaming in code Blog Post 3

Dreaming in Code這書，讀著讀著就到了尾聲，然后驚訝的發現關于后面章節的內容和我的想法，有很多在前面發的兩三個blog里（僅涉及開頭3章）就已經有了。可能這本書開頭那些宏觀的描述讓我產生了不少想法吧:-P

所以這次呢，咱們就說說Chandler失敗的幾個原因，找到一些原因了自然就會有相應的解決策略。（我還是用中文罷，自己寫著大家看著都舒服，而且我的英文還是不能完滿的表達出心中所想）

Chandler走到現在這步田地，其實很難把原因說清楚說完全。我零散的整理出以下幾點：

1. 目標過于偉大

Linus Torvalds說：“Don’t expect to get anywhere big in any kind of short time frame……If it doesn’t solve some fairly immediate need, it’s almost certainly overdesigned.” 為什么Chandler的目標會被反反復復的定義，架構也重復設計了很多遍？因為OSAF的人，尤其是Kapor，從一開始就只有頭腦中的一個幻象。他們幻想著Chandler“應該”對所有的事件都統一處理，“應該”是p2p的架構，“應該”支持互斥鎖保證數據同步（我的描述可能不嚴謹，只是來源于我看后最深的幾個印象）。在沒有初步設計、沒有可行性方案的情況下，誰也不能保證這些“應該”做到的就能做到。有人會想，單是這些幻想倒也無可厚非，畢竟想法都是好的，想為人類造福，但是問題在于Chandler的內在使命是要一步到位！

另外一個過于宏偉的目標就是“任何人都能發現 Chandler對自己有用”。我很懷疑這種想法的現實性，至少程序員和非程序員的需求就很不相同。誰敢說自己的軟件有如此的智能呢？我認為這不應該成為做軟件的目的。在設計的初期要定位適合的目標人群，即便是微軟也不會定位成全體地球人吧！

題外話：目標不可過大又不可過小，那末軟件的價值如何確定？我想，在決定做一個軟件之前還是要先想象一下，假設你想做的東西已經有了，人們為什么要用它？能不能不用它也活得很happy，或者這樣的軟件是否已經存在？Bill Gates來清華的時候我記得最清楚的一句話，“軟件是一種習慣”。有時自己想做的東西確實有killer feature，但實際做出來可能還是沒人用，那這時候就要看習慣和killer feature兩者火拼誰能贏了。對幾個Team做的Project，我也一直在想這個問題。我覺得我們組的畫圖軟件，對于某些人群還是能破除習慣的（當然是在消滅不能忍的bug之后）。一是像CTex那樣，針對的用戶是想用Windows風格的界面去實現原本是Linux下的功能；二是作為畫圖方面的大眾用戶，我只會用Windows畫圖程序、不會畫矢量圖，而在用我們的DTSlob Graphics畫圖的時候能發現很多更加方便的功能（IPE雖已具備，但是用著麻煩），至少讓我很想用它替代Windows畫圖程序——當然還有一點，如果大眾裝電腦時都沒有裝.NET的習慣的話，這個習慣如何能讓大眾建立起來呢？

2. 松散的組織

一個由 volunteer組成的non-profit機構，想來就來想走就走，沒有合同、工資、上下級等等。這種形式倒是夠平等的，本意是要每個人的思想都能得到挖掘，但卻缺少了點條例性質的約束。再者，資金的數額似乎是用之不竭的，招多少人都無所謂，開發Chandler的先后幾年間隊伍漸漸的換了好幾批。除此之外，開發過程中一直沒有堅定的采用某種方法論（比如到2005年才開始做TDD），可能也與松散的組織有關。所謂以興趣結成的團體其實是最不牢固的。

所以軟工課也一樣，一個Team所有人得同樣的分就只約束了Team，而無法形成對每個人的約束。

3. 人人都是專家

書中幾乎每個人首次出場時，都用了兩三頁的篇幅介紹Ta的歷史，就像三國里的武將現身定會有一段精彩的特寫。每個人都有大項目的開發經歷，都曾擔任大公司重要產品或開源項目的工程師、架構師等等。這樣的一群人到一起做事，看似會集思廣益，實則拖慢了進度。每個人都有一套獨門武功，來了個對手大家一起上，互相之間動作協調不好難免會傷及自家弟兄。其實他們可能都明白原有經驗不能照搬到新項目上的道理，然而一開會討論實際問題也許就都忘了，各說各的理。孫劉曹手下的謀士皆常有意見利益不和之時，如求自保則歸隱山中，如被收買則棄暗投明。書中提到，有一個人度個假回來發現自己原來寫的東西被完全拋棄了，這樣的心情可想而知，不走才怪。

忽然想起做電梯的時候，課上老師問有誰愿意寫接口，只有Lonnie主動接了這活。等出了一套接口大家用起來，開始怨聲載道。其實各人心里都是怎么想的呢？“都是一個班的，憑什么我要用你的接口，何況用起來還這么別扭”。不過如此。

所以我認為Kapor招的人里面最好有一部分是啥也不想、只管實現、無怨無悔的碼農。這樣的人是有其存在價值的。絕對的人人平等是不可能的。

4. 閉門造車

當 Kapor看到基于AJAX的Gmail、看到眾多基于網頁的PIM相當方便的實現了跨平臺之后，他也感到很不爽。但是沒辦法，他之前也看到了這些技術，但是固執的沒有采用。天上一天，地上一年。當OSAP悠哉悠哉的改著架構的時候，Web 2.0風起云涌了，Firefox小占市場了，誰還會再破除一次習慣，刻意要去接受古樸的Chandler呢？
在Dreaming in Code一書的第10章Engineers and Artists中，作者提到了許多大牛對軟件將走向何方的考慮。這些意見大體分為兩派：革命黨vs. 改良派。

革命黨的意見自然十分奇特，比如用自然語言寫程序啊，把編程的過程生物化啊，等等。這派意見認為軟件已經陷于各種理論的bound和各種工具和經驗形成的桎梏之中，不脫胎換骨就無法繼續發展。他們要start over，尋求一條“科學”之路。然而我認為這樣的偏激有以下不妥。

1. 要說科學的話，任何一門科學都不會完全start over。不可否認的是新發現新理論總會對舊科學造成沖擊甚至危機，但是沖擊或危機之后其實又常常是在原有基礎上實行擴展，至少沒有“把寫程序變為種程序”這么大的變化。
2. 假使我們果真start over，之后呢？是不是還會面臨像現在一樣的窘境呢？這些start over的主張恐怕都不能說明這一點。或許computation theory里的各種bound、complexity的本質性是人類在計算這一課題面前不可避免的，無論以什么形式實現計算。
3. 從利益群體考慮，如果真的推翻了computation一切的一切，工業界、學術界、新聞界能夠允許人類在這上面60多年的努力全部幻滅嗎？

改良派的意見就更加可操作。他們也想尋求科學發展，并且抓住了科學的一個最重要的特點：繼承性。現今的程序員不想看或者看不到前人的經典設計和代碼，就像小孩玩積木，自己就搭自己的，搭出來自己覺得好看就夠了。然而科學的發展歷史中很重要的一點就是文獻的編寫和總結，如此才能高效率的完成創造性的發現。至于程序員能不能拿到真正大制作的代碼……我有個信念是互聯網和世界的發展潮流就是終極的共享。

前方的路雖然太凄迷，請在笑容里為程序員祝福……

最后，copy尾聲中的一段話作為結束：

“Making software is still, and truly, hard. But I can hear the objection: There are different kinds of hard. Raising a child is hard. Burying a parent is hard. Birth and growing; living with other people or without them; trying to love them; failing to love them; accepting someone else's death; accepting your own—these things are hard. Software? That's a different universe of hard, a lesser one.”

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的现代软件工程系列 学生读后感 梦断代码 DTSlob (2)的全部內容，希望文章能夠幫你解決所遇到的問題。

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