Stan Lippman VLSP课程培训笔记 汇总

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

******************************************************************************************

关于“一次定义法则”（ODR）的问题