C++ 會議第一天(Lippman C++不適合做大規模可伸縮性的項目)zz
http://blog.codingnow.com/2009/12/cpp2009.html
Lippman 大牛的第一場，關於大型可伸縮性的軟件開發的， Chen Shuo 同學翻譯的很不錯 :D
找到電源，所以可以寫寫了。
果然是牛人啊，上來就講形而上的東西。我聽的有趣，就做了點筆記，但是記的不多。
我們從自然界去尋找靈感，然後在計算機領域去搞出來。以前的計算機是沒有內存的，後來馮大俠說，計算機就像大腦，大腦是有記憶的，所以有了內存。
我們現在說大腦就像計算機，是本末倒置了。人們總是從自然界的角度來思考，然後解決軟件裏的問題。Lippman 牛的想法是，把軟件比作生物，從 DNA ，細胞核開始向上一層層的。
系統的基礎組織部分是 Data Structure 和 Data Stream ，這個就像細胞一樣；在應用領域方面，Executive Function 和 Type Information 就好比生物的各個器官。
大牛參加了許多項目，他抱怨了一輪，說好多都可恥的失敗鳥。大項目就是容易失敗。程序員辛苦啊，根本不是所謂白領。而且每個程序員都是不可替代的。因爲每個人的學習經歷不同，看待問題不同，寫出來的程序就不同。人們對編程的理解並不像想象的那麼美好。現在慢慢的我們提高了抽象層次，按這個宇宙存在的方式去運作。但是從 java 開始學習編程，對程序員來說是有很大代價的，以前用 pascal 開始學習程序也有很大代價。大約是說，失去了對某些本質的理解。形成的對程序世界的世界觀會有問題。
說回大項目，比如他參加的 Visual Studio 就不是啥成功的產品。用 .net 做 Windows 也很失敗，那玩意根本就跑不快。微軟做軟件的哲學有問題，所以做不好。
有一個土星登陸器的項目，一代代技術都更新了。他作爲技術顧問，提了些建議。主架構師糾結於用 java 還是用 C++ 這種問題上。其實架構師根本不應該關心用啥語言做。語言好不好都是屁話，把事情做好纔對。最終項目是失敗了。有很多問題都不是常規方法可以處理的。比如通訊的問題，因爲土星上有什麼什麼，導致有時候信號 5,6 小時發不出去，等等。傳統的通訊連接方式就不適用。
還有好多項目（有具體列舉，沒一一記了），做着做着，做了好幾年，程序員心都涼了。
另一個是 MMO 項目，花了幾千萬，還是可恥的失敗鳥。做出來後，什麼都好，什麼都很完美，只能支持 40-50 人在線。公司還說聖誕就要上。高層說，無所謂，不能玩也無所謂，做出來就好。結果當然是不能用的。開發人員心那是拔涼拔涼的。
再話說，Sun AT&T 幾個公司想用 C++ 重寫 Unix 。還有 IBM 等等用 Unix 的公司，搞了個啥邪惡同盟。反正最後也是可恥的失敗鳥。
還有 Bell Labs 的 Plan 9 。東西是好的。不過根本不能成爲一個產品。這裏，提醒各位同學，找工作要小心。先偵察一下，如果公司就是要做個啥項目光衝着賺錢去的，這心態就有問題，肯定玩完。還有管理人員一定要懂技術，要知道做的東西是怎麼回事。否則碰到這種倒黴事趕緊捲鋪蓋走人，別浪費青春。
接下去又說了好多悲劇，比如 IBM 的 OS/2 啥的。說着說着，說不下去了，名單太長，全是血淚史啊。
Lippman 接着自比江湖百曉生。我覺得他是自謙，想說自己其實只是倚老賣老，知道許多事情，參與了很多項目而已。
正題其實是說怎麼做大規模可伸縮性的項目。結論很悲觀，說 C++ 其實不適合做這個。最後我問了個問題，說那什麼合適呢。他沒正面回答。不過舉了個例子，提了愛因斯坦的相對論，還有量子力學。大約是想說，C++ 更像是 BS 大牛個人的作品，他一個人構架了 C++ 的大部分東西。但是我們未來需要新的語言來解決問題的話，應該參考量子力學的發展過程，大家一起來構架。C++ 呢，說這個最後可能會被我們帶進墳墓。不是 C++ 不好，是因爲細節太多，沒人全搞的明白。結果每個人寫出來的程序都不一樣。指定規範很難。最後會有很多人不願意學。
正題裏圍繞的實際例子是在動畫工業中的。其實做動畫，好多工具都是用完即棄的。提高可複用性，關鍵在於要把可複用單元做的足夠小。做大就沒人理你了。
他們有人（貌似說的 pixar）做了個神奇的東西，反正就是類似 method 註冊啦，動態生成類型啦之類的一個奇妙的 C++ 玩具。可以把代碼動態的以字符串形式註冊進去。動態生成一些類，一些接口調用之類。大約加了兩個間接層。代碼裏充斥着所謂的註冊代碼。往往多達幾千個。當然性能上也因爲這個間接層，下降了幾十倍。
當然，大型可伸縮的項目，性能也不是關鍵的東西。
這裏還插了幾句關於腳本的。說是有 C++ 程序員說，其實我拿 C++ 寫什麼什麼也很快的。不過那不行，因爲 C++ 程序員太少。你用 C++ 寫沒問題，不過要求你寫完了翻譯成 perl 代碼.
不過這個東西很複雜，所以除了寫它的人，沒人願意去看怎麼實現的。後來做這個的那個傢伙回巴黎去了。那些代碼也很可怕，很複雜，裏面也有很多 bug 。
後來 Lippman 也做了個類似的東西，也是號稱 Metaprogramming ，不過不是所謂 template metaprogramming ，而是代碼生成代碼。最終自動生成的是 C 結構。不過主要目的達到，就是隱藏衆多細節。有人說這個不是 OOP ，沒有 class 啥的，不過他認爲這個也是 OOP 。OOP 不能看錶象。他說，他其實只是想明白個事，關於靜態數據和動態部分之類。
這個例子我很有感觸，因爲我們公司曾經也有個類似的東西。做了個 C++ 和 lua 的巨複雜的粘合層。弄的看起來很高級。結果發明和維護的人走了後，用它的項目組都以把這坨東西從項目中去掉爲榮。
說起大項目，Lippman 說，一切失敗的大項目都有個通病。就是時間很長，經過幾年後，就變成了一個封閉王國。結果沒人知道在幹啥。裏面拉幫結派，爲了一些無所謂的技術問題爭來吵去。其實爭論的都不是要乾的事情。
另外，項目太大了後，就沒人瞭解項目的全部細節。漸漸的，大家都只關心自己做的那一塊。這樣很糟糕。他思考後，認爲解決的方法是，應該把結構旋轉 90 度，變成一個有層次的結構。從上到下一層層剝離。同一層次上就不要橫向切了。
嗯，這個問題我也很有感觸，雖然我的項目不算特別巨大。但是隻有我一個人瞭解項目全部的細節，這讓人很累。當然如果要每個人都瞭解全部細節，就會讓每個人都很累。
以上是我凌亂的一些聽課筆記。很多有趣的東西沒來的及記下。可能也有很多我的誤解在裏面。同學們姑且看之吧。
********************************************************************************************
http://www.cppblog.com/heath/archive/2009/12/05/102605.html
聽Lippman講座
對Lippman的印象：
第一次在現場看到Lippman，比以前在視頻上看到的老了很多，頭髮少了很多，鬍子也
沒了，說話也有些含糊不清了，但年齡的增長卻絲毫沒有抹去他的睿智和朝氣。他是一
位非常smart、對喬布斯讚賞有加，很喜歡用Iphone和Ipod的老頭兒。在Q&A環節他頑皮
地坐在講臺地板上回答問題，讓我看到了大師可愛的一面，也讓我聯想到了Iphone發佈
會上的喬布斯。
內容：
講座的主題是下一代大規模軟件開發中的挑戰與解決方法，但Lippman卻講的是目前大
型軟件(諸如MMOG)開發的問題，以他在皮克斯動畫公司解決的一個實際問題入手，闡述
他對此類問題的解決哲學。
問題：
爲什麼貝爾實驗室用以取代Unix的Plan 9會失敗，爲什麼宇宙探測器自動控制系統會失
敗，爲什麼他們做的MMO——God & Hero只能承載不到100人？要知道，這些團隊的成員
都是非常聰明，並且有着很絢麗的工作業績的牛人。
原因：
原因在於隨着團隊規模的膨脹，越來越多人蔘與到其中，代碼規模會呈幾何級增長，直
到超出了個體的掌控和理解能力，團隊中已經沒有一個人能夠完全理解整個系統，這時
往代碼庫中添加代碼，沒有一個人能夠肯定這將給系統帶來什麼。
解決方法：
沒有通用的解決方案，但有些原則：
1）系統不要超出團隊成員的理解和掌控能力範圍；
2）不贊成一個人從頭到尾負責一個模塊，因爲每個人的擅長不一樣，思考問題的角度
和解決問題的手段也不同，讓不同的人開發一個模塊能夠讓該模塊滿足多方面的需求
（從底層優化到對上層抽象的接口）；
3）從小到大的開發方法，實際上就是迭代的開發，從具有簡單功能的初級系統迭代到
功能完善的大系統；
4）不管用什麼開發技術，程序=數據+算法的核心理念是不變的。程序能夠跑多快，最
終取決於數據的訪問速度，而層層抽象往往會降低數據訪問速度。因此，首先應該保證
數據的訪問速度，在此基礎上，才考慮封裝和抽象；
5）自己擅長的技術和方法，不一定就是解決問題的最好的、最合適的方法；
6）Lippman最引人入勝的開發哲學——向大自然學習。自然界便是一個異常複雜但設計
良好的系統：原子組成分子，在由分子組成蛋白質，進而組成DNA，最終形成生物。
Lippman給我的啓發：
1、敏捷開發方法已經深深地影響了Lippman，這一點可以從他對於迭代開發和提交可執
行代碼的推崇可以看出。同時，結合以前讀的書以及聽過的講座，有一個意識在我頭腦
中越來越清晰了：大師在技術領域摸爬滾打了幾十年之後，必然會從哲學、生物學、心
理學的角度來解析軟件開發，並試圖解決開發過程中的一系列問題，因爲他們相信這才
是認知的本源。雖然Lippman沒有很直白地給出大規模軟件開發問題的解決方法，但是
他給出了一條途徑——從自然界尋求解決方法，就像萬物的構成：原子->分子->蛋白
質->細胞，從小到大，層次分明。
2、面向對象技術的誕生只是解決了C/Pascal等面向過程語言的一些問題，C++在誕生
時，設計和實現者並沒有奢望滿足將來不確定的需求。然而，在C++誕生二十多年之
後，我們居然很坦然地認爲面向對象技術是理所當然，是符合自然規律的，這明顯是個
悲劇。
3、不要迷你大師，大師只是一個傳說。當Lippman在回答cloud computing何去何從
時，他只是謙虛地說：他只是對C++比較瞭解，在其他領域，他可能還不如在座諸位。
******************************************************************************************
轉載3
http://nyim.blog.163.com/blog/static/2414916420091132162784/
[摘]'名家之聲'--Stan Lippman VLSP課程培訓筆記
記錄人: oromeouyan(歐陽羣明)
Hi, guys
下午參加了Stan Lippman大師的下一代大規模的軟件開發，目睹了大師，大師隨便就
地一坐，感受到了國際大師的"風采"。
培訓其間,零散記錄了大師的一些言語、思路與想法，回來整理了一下。
以下有些是出自Stan大師的原語，未加修改與擴展; 有部分是在理解的基礎自己寫出來
的，甚至加了一些自己的一些thoughts.
大師講的是E文，可能理解有不到位的地方，或聽錯了，有不對的地方，請大家更正;)
1.失敗並不可怕，因我們可以從中學到一些經驗與經歷
2.軟件公司擁有的唯一兩項資源:程序員與軟件代碼
3.M$一直都在維護VC超過十年的代碼庫，其維護難度相當之大, 70%的精力都在bug fix
上,可見軟件可維護性的重要性
4.Lippman試着從生物生長與發展的角度來思考軟件開發的存在的問題, 如固有的難度
與複雜性, 提到的生物的概念有基因與DNA
5.大型軟件系統分爲兩類:一種是一開始很小，然後隨着其特性增加，以自然方式成
長，最後獲得了成功，
它們成長到成功是在沒有一個真的整體架構前，如Linux;另一種是一開始就非常大，後
面變得更大,這兩種的挑戰與方案是截然不同的
6.從基因特性，我們學到的第一點就是可用性, 兼容性，軟件應該層次構造，而不是線
性構造
7.最底層永遠是數據，我們要保證在程序中的數據流要最小的延遲，因爲沒有其他的可
比這個更快,
這就意味着我的數據不應該因爲抽象而分離，我們希望抽象在我們的數據上被分層
8.如果能夠在編譯時決定的數據，不要在運行時花費開銷來做,除非真的不影響性能且
能讓程序更優雅，更好維護.
這裏反面例舉了兩個項目，一個是MMO項目，其中機制是動態註冊成員函數，另一個通
過分析一個巨大的XML數據文件而生成對象，
並試圖利用序列化的另一思路，也是走不通的, 因爲C++語言對這方面的根本支持，必
須要自己實現
9.對於可以通過.h文件中信息就能產生的代碼，我們應該編寫工具來生成相應的代碼，
而無須手工編寫邏輯與結構一致的，
但又不能抽象統一的代碼，手工編寫會帶來額外的工作量與維護成本,如果常見的數據
庫訪問代碼或協議定義代碼，我們的atom系列類就可以這樣來做.
10.程序員需要培養喜歡閱讀別人的代碼的習性，而不只是只看自己的代碼
11.在使用HashMap的情況，由於衝撞帶來的開銷，可能相當大，有時候直接使用c風格
的array效率更好，這裏還有page-swapping的理解，
雖然換頁這是操作系統的職責，但如果程序員在編寫代碼的時候能有這個概念，能夠在
編程的時候把常一起出現的數據放在一塊，
從而在執行的時候大減少缺頁中斷的次數，也可對程序的性能改進有不少幫助
12.對於大規模的系統，細節有時候顯得有尤爲重要，它可以成爲一個整體性能的決定
因素
13.Lippman強調程序員之間應該相互閱讀代碼，並提出意見進行討論，而不是封閉自
己, 這不就是Peer-review嘛，大師對其重要性都表示強烈支持，
我們可以應該想辦法應用到工作中來...
14.一個人專職負責的模塊，在它出現重大問題的時候，他一個人往往無法搞定，如果
有多人瞭解，情況就不同了
15.程序員閱讀自己寫的代碼，他就猶如走進一個已經有四面牆(four-walls room)的房
間，已是一個完整的概念，一些意識已佔據的他的大腦，也就是先入爲主了;
所以對自己的代碼理解，非常容易造成理解死角，如果閱讀別人的代碼，就是走進三面
牆(three-walls room)，是一個不完整的概念，
需要努力的去理解作者的做法與思路，爲什麼要這樣做，所以有時候更容易發現問題所
在及存在的潛在問題
16.我們要讓正確的人去做他最擅長的事，如果將一個不恰當的任務分配給一個錯誤的
人，往往達不到最好的效果，Lippman舉例了他讓一個在底層驅動開發方面的牛人，
讓他來爲C++開發人員封裝一個易用的類，因而他做出來的只是一個非00模式的類，依
然暴露太多細節，看不懂，不好使用，最後他決定讓另一個在OO方面有更深造詣
的人來做，一句話總結:讓正確的人做正確的事
17.你熟悉的方式有時候並不是最好的解決方法, 有時候我應該放棄自己依賴的舊方
式，更多的依賴大腦的思考
18.加速數據的訪問的速度是開發大規模系統的一個設計開發指導思想
19.大型軟件的設計與實現，要始終的可伸縮性的概念做爲指導
20.要解決一個大型系統的問題，最好的辦法仍然是閱讀其代碼，修改代碼時，一定不
要造成這樣的影響:需要修改所有使用到的現有代碼庫，其方法是基於接口編程
21.開發一個大型系統，我們需要儘早有一個可以運行的系統，儘管他有缺陷，這都沒
有關係，如果一個軟件經過一年二年之後，最後才得出結論無法做下去，打擊是致命的
22.在未來，我們可能會有更好的工具、語言和新的開發模型，但目前，多層結構仍然
是解決大型系統的一個較爲合適的方案
23.OOP這個20年前出現的技術，在目前已有點不能很好工作了
24.當一個系統需要構建在多個系統平臺上時，我們重組合，重構現有代碼庫，提高其
可用性，而不是全部重寫一份, 因爲除去開發的工作量，重測試的代價是巨大的
現場答問中的一些觀點彙總，個人感覺前兩個提的問題沒有問好，二個都是雲計算，
Lippman的專長肯定不在這邊嘛:
1.如果你覺得這個項目不會成功，就一定不要加入這個項目
2.人總是想盡量的迴避那些讓人痛苦的事情
3.做技術的人，永遠保持一份開放的思想(Keeping open-minded)
4.對於一項還可預測的技術，不要狂加斷言與提前預測來以此做出決定，除非你真的決
定賭上這一回了
5.你不能放棄你所愛的(You can't quit what you loved)
Orome
******************************************************************************************