车开了800公里了，感觉比刚开时，上手了不少；现在马路上熄火已经比较少了。
1. 放手开，该给油就给油。新手刚开车，就不要考虑省油了， 把车开的安全、不伤着车就好了。
2. 尽量让发动机转速维持在2500转，宁愿减档，也不可以低于2200以下跑，因为是新车，倍加爱护，转速低了发动机积碳，就不好了。
3. 马路红绿灯起步后，尽量先给脚油，把转速拉到2400左右换成2档走；避免后面的司机喇叭催，一慌就容易熄火。
4. 马路上该快则快，我觉得和大家的速度一样最安全，太慢了频繁有人超车、并线，反而容易出剐蹭。
5. 晚上开车比较累，视觉不好，倍加小心，安全第一。记得晚上一定开灯（呵呵，仅对新手，我就有此开了300米没有开灯，一个司机给我按喇叭提醒了）。
6. 换档别舍不得给油提高转速。
总的来说，我认为： 新手开车安全第一、磨车第二、省油第三。
另外，开车要小心关注路况和行人、非机动车，不能分心，在车上思考问题、开小差非常危险。
2007年5月29日星期二
没有侥幸
记得以前有此和朋友聊天，谈到一句话：“只要感觉有问题的地方，最终一定会在那里出问题”。
现在想想这句话，真是对的。无论如何，我们都不能有侥幸的心理，我们自己没有认真考虑、没有考虑周到的事情，最终出问题的地方也一定在这里。无论我们其它工作做的多么的好，这些潜在的问题最终可能会毁掉成果。
工作中这样的经历也很多了，当初认为可能问题不大而没有再去认真考虑的地方，其中大部分最后都成为要花很大成本去收拾的问题。这些问题刚开始始难度可能也不大，只是我们在考虑其他“更重要”的问题，而没有分精力来考虑这些“小事”。这些小问题积累到后面后，就牵涉了其它一些相关问题，从而成为一个麻烦的“问题团”，而最终导致花很大成本去解决。
具体的事例不提了，我想每个人都有这样的经历。作为一个项目，那么对项目的设计需要考虑到每个细节；对于一个人的工作，也要尽可能的考虑到每一个麻烦因素；对于一个公司，无论核心竞争力如何强大，也必须去注意公司发展中每个小小的毛刺，古谚：“千里之堤，溃于蚁穴”。
现在想想这句话，真是对的。无论如何，我们都不能有侥幸的心理，我们自己没有认真考虑、没有考虑周到的事情，最终出问题的地方也一定在这里。无论我们其它工作做的多么的好，这些潜在的问题最终可能会毁掉成果。
工作中这样的经历也很多了，当初认为可能问题不大而没有再去认真考虑的地方，其中大部分最后都成为要花很大成本去收拾的问题。这些问题刚开始始难度可能也不大，只是我们在考虑其他“更重要”的问题，而没有分精力来考虑这些“小事”。这些小问题积累到后面后，就牵涉了其它一些相关问题，从而成为一个麻烦的“问题团”，而最终导致花很大成本去解决。
具体的事例不提了，我想每个人都有这样的经历。作为一个项目，那么对项目的设计需要考虑到每个细节；对于一个人的工作，也要尽可能的考虑到每一个麻烦因素；对于一个公司，无论核心竞争力如何强大，也必须去注意公司发展中每个小小的毛刺，古谚：“千里之堤，溃于蚁穴”。
2007年5月28日星期一
谎言
昨天下午，我想吃西瓜，就拉着老婆一起下楼，在楼下的报刊亭，停着一辆三轮，有西瓜卖；问了下价钱，说1元五一斤。我说：“好贵啊，比超市还贵"。随后卖西瓜的大妈就来了句：“1块五还贵啊？低于这个价进都进不来。”
我当然不信，也当然没有兴趣去争辩，我只是想吃西瓜，比超市贵几毛钱，也不能让我再跑400米去超市买。就买了半个西瓜，回家享用。
傍晚时我和夫人去超市买酸奶等，到了超市一看，西瓜1.38元，我呵呵就乐了。对老婆说：“楼下大妈骗俺们了”。
这是个小小小事情。但是也让人深省，大妈为了几毛钱，就愿意撒个慌，而撒谎的对象，就是抬头不见低头见的小区住户，我也不认为这是大妈的人品问题，可能对于任何一个做生意的人来说，这样的话都太正常不过。
从另外一个角度来说，当我们需要对一件事情做判断时，一定不能只对事情一方的人进行了解、沟通；而必须两个当事人都进行沟通、了解；还需要尽可能去了解一些事情的背景。原因不是对单方的不信任，而是本质上来说，每个人都会为自己的利益辩解，辩解到一定程度，不惜撒谎；了解背景的目的，是考虑当事人辩解、甚至撒谎的合理性。撒谎不见得就是错误的，如果站到撒谎人的角度去看的话。
我当然不信，也当然没有兴趣去争辩，我只是想吃西瓜，比超市贵几毛钱，也不能让我再跑400米去超市买。就买了半个西瓜，回家享用。
傍晚时我和夫人去超市买酸奶等，到了超市一看，西瓜1.38元，我呵呵就乐了。对老婆说：“楼下大妈骗俺们了”。
这是个小小小事情。但是也让人深省，大妈为了几毛钱，就愿意撒个慌，而撒谎的对象，就是抬头不见低头见的小区住户，我也不认为这是大妈的人品问题，可能对于任何一个做生意的人来说，这样的话都太正常不过。
从另外一个角度来说，当我们需要对一件事情做判断时，一定不能只对事情一方的人进行了解、沟通；而必须两个当事人都进行沟通、了解；还需要尽可能去了解一些事情的背景。原因不是对单方的不信任，而是本质上来说，每个人都会为自己的利益辩解，辩解到一定程度，不惜撒谎；了解背景的目的，是考虑当事人辩解、甚至撒谎的合理性。撒谎不见得就是错误的，如果站到撒谎人的角度去看的话。
2007年5月24日星期四
2007年5月23日星期三
2007年5月22日星期二
30岁前应该完成的几件事情
1，不能再年轻气盛，嘛事能平心静气。
2，做事更加理性，行为的目标为实现一个目的，过程中不再受情感的影响。
3，成为一方面的专家。
4，良好的语言基础和数学基础。
5，很好的朋友圈子。
对于1，主要是形成习惯，对自己要求控制情绪，不再让自己的神经控制思维。具体做法是： 要求1天对任何事情静心思考、平和讨论；然后把要求扩展到3天； 再扩展到一周。最终形成习惯。
对于2，要求自己多看书，多思考，对一件事情三思。
对于3，要求自己在P2P技术和项目管理上，精益求精，成为真正意义上的技术专家。
对于4，要求自己学习日语、英语。
对于5，要求自己更加主动的去交朋友。
2，做事更加理性，行为的目标为实现一个目的，过程中不再受情感的影响。
3，成为一方面的专家。
4，良好的语言基础和数学基础。
5，很好的朋友圈子。
对于1，主要是形成习惯，对自己要求控制情绪，不再让自己的神经控制思维。具体做法是： 要求1天对任何事情静心思考、平和讨论；然后把要求扩展到3天； 再扩展到一周。最终形成习惯。
对于2，要求自己多看书，多思考，对一件事情三思。
对于3，要求自己在P2P技术和项目管理上，精益求精，成为真正意义上的技术专家。
对于4，要求自己学习日语、英语。
对于5，要求自己更加主动的去交朋友。
2007年5月21日星期一
车之感
1. 开车是个辛苦活; 时刻盯着路面情况,前后视镜. 一天开下来,感觉挺不轻松的.
2. 礼貌交流; 如果大家在路上开车,能互相礼貌点的话,对方也会相应的给予照顾,可以避免很多无畏的危险情形.
3. 新手就是新手,应该贴上实习标志; 北京应该是新手司机很多的地方,但大街上没有几个贴实习标志的. 其实贴上还是很有用的,比如路上熄火了,后面的人会稍微等下,不会使劲按喇叭催你. 超车时,也会超过新手远些再并道.
4. 城区开车要十分谨慎,不知道什么地方就钻出个自行车过去.
5. 提前并道; 快到路口时,一般车都比较拥挤了.加塞既不安全又很讨人烦.
6. 在道路上开车,尽量选择一个合适的速度,不能太慢,也不能太快.最好能找一个载了人的出租车跟车,根据车速度保持一定的安全距离. 当然,不要跟喜欢飑车的出租车司机,如果司机频繁并道,不要跟他.
7. 一些老路面上的道路分割线已经不清楚了,得仔细看.我前天走朝阳路,就骑了两条道.
8. 我是新手,慢慢体会开车的技巧. 刚开始,不要考虑油耗,尽可能把车开熟练.
2. 礼貌交流; 如果大家在路上开车,能互相礼貌点的话,对方也会相应的给予照顾,可以避免很多无畏的危险情形.
3. 新手就是新手,应该贴上实习标志; 北京应该是新手司机很多的地方,但大街上没有几个贴实习标志的. 其实贴上还是很有用的,比如路上熄火了,后面的人会稍微等下,不会使劲按喇叭催你. 超车时,也会超过新手远些再并道.
4. 城区开车要十分谨慎,不知道什么地方就钻出个自行车过去.
5. 提前并道; 快到路口时,一般车都比较拥挤了.加塞既不安全又很讨人烦.
6. 在道路上开车,尽量选择一个合适的速度,不能太慢,也不能太快.最好能找一个载了人的出租车跟车,根据车速度保持一定的安全距离. 当然,不要跟喜欢飑车的出租车司机,如果司机频繁并道,不要跟他.
7. 一些老路面上的道路分割线已经不清楚了,得仔细看.我前天走朝阳路,就骑了两条道.
8. 我是新手,慢慢体会开车的技巧. 刚开始,不要考虑油耗,尽可能把车开熟练.
2007年5月18日星期五
今天贿赂了停车管理的管理员:)
今天5:20从家出发,一路速度较快,朝阳北路基本是60公里，四环路基本是80公里，40分钟到了公司，才6:00,呵呵.
在车里休息了会,然后到老家肉饼吃了4元的早餐. 回来碰上了看车的管理员,说了下不要票,5元停一天,呵呵.
在车里休息了会,然后到老家肉饼吃了4元的早餐. 回来碰上了看车的管理员,说了下不要票,5元停一天,呵呵.
软件开发技术和软件工程
今天看到了一篇文章,介绍C/C++异常处理机制的缺点;其中提到了"软件开发技术"和"软件工程". 我想把这这两个概念放在一起比较非常有意思.
我经常看到一些同事或朋友为自己的会了一个技术津津乐道,比如可以用了一种很巧妙的办法把一个功能完成.或者在讨论一个项目时,不厌其烦的讲解着所谓的技术有多么多么高深. 其实这些所谓的"高深"技术,已经是前辈门研究出来的成果,已经告诉了我们这个技术的实现方式,和一个功能的完成办法.这样的技术,我们要做的事情无非是看文档资料,设计成计算机程序而已.
我的意见是,这样的技术当然要掌握,但是为一个技术而沉迷,不能跳出技术的圈子看整个项目,是很遗憾的.一个项目最终的成败,大部分情况不是技术决定的,而是项目管理\项目流程决定的.一个技术人员在成长过程中,不仅需要关注技术,还需要关注项目.
软件工程追求的是项目的可靠性\可维护性,和开发的可控性; 软件技术追求的是更好的编程方式\更高的软件性能和可维护性. 所以,仅关注软件开发技术,有可能在项目中和软件工程是有冲突的,因为两者的焦点并不一致.
总的来说,我人为一个程序员,一定要有软件工程的概念.
我经常看到一些同事或朋友为自己的会了一个技术津津乐道,比如可以用了一种很巧妙的办法把一个功能完成.或者在讨论一个项目时,不厌其烦的讲解着所谓的技术有多么多么高深. 其实这些所谓的"高深"技术,已经是前辈门研究出来的成果,已经告诉了我们这个技术的实现方式,和一个功能的完成办法.这样的技术,我们要做的事情无非是看文档资料,设计成计算机程序而已.
我的意见是,这样的技术当然要掌握,但是为一个技术而沉迷,不能跳出技术的圈子看整个项目,是很遗憾的.一个项目最终的成败,大部分情况不是技术决定的,而是项目管理\项目流程决定的.一个技术人员在成长过程中,不仅需要关注技术,还需要关注项目.
软件工程追求的是项目的可靠性\可维护性,和开发的可控性; 软件技术追求的是更好的编程方式\更高的软件性能和可维护性. 所以,仅关注软件开发技术,有可能在项目中和软件工程是有冲突的,因为两者的焦点并不一致.
总的来说,我人为一个程序员,一定要有软件工程的概念.
[转] 异常处理的讨论
对C++异常处理机制的讨论
今天在C++技术大会上做了一个Presentation，论题是C++的异常处理机制。很有点出乎我的意料，大家的反馈很是强烈。演讲后，午饭中，以及下午的讨论板块，很多人争相发表自己的看法。
姑且不谈争论的细节，我想一定程度的争论不是坏事情。不同的观点更有助于我们认识问题，和让更多的人意识到问题的存在。
1，争议的一个地方是无法接受我引用的几个对C++异常处理机制的反对性意见（例如不要在自己的代码中主动抛出异常）。对于此，我主要是从软件工程的角度考虑而支持这些意见的，因为一种技术如果在工程应用中不易被大多数人所把握，那么我们就应该考虑是否还要应用它。因为应用一种技术的目的是为了降低软件项目的复杂度，而不是相反。这一点我在开篇就强调了。但也许有些听者晚到了，没有听到。
2，引起争论的另一个地方是有听者觉得我主要谈的是结构化异常处理（SEH），不是C++的异常处理机制。事实上，因为我讨论的是针对Windows操作系统和MS Visual C++编译器。因此，EH是基于SEH之上实现的。EH只是简单的做些包装就把C++的异常转变为SEH统一处理了。也正是因为这个原因，在Windows下，C++异常捕捉块(VC编译器)也可以捕捉到CPU定义的除0等异常。
尽管有不同意见，很多人还是很有同感的赞同我提出的结论。
模块内和内部模块之间不要用抛出异常代替错误返回；
设置全局性的异常预处理和未处理异常补救措施（类似Windows XP引入的向量化异常处理机制, VEH）；
定义完善的错误处理政策和机制
错误日志
错误代码格式
今天在C++技术大会上做了一个Presentation，论题是C++的异常处理机制。很有点出乎我的意料，大家的反馈很是强烈。演讲后，午饭中，以及下午的讨论板块，很多人争相发表自己的看法。
姑且不谈争论的细节，我想一定程度的争论不是坏事情。不同的观点更有助于我们认识问题，和让更多的人意识到问题的存在。
1，争议的一个地方是无法接受我引用的几个对C++异常处理机制的反对性意见（例如不要在自己的代码中主动抛出异常）。对于此，我主要是从软件工程的角度考虑而支持这些意见的，因为一种技术如果在工程应用中不易被大多数人所把握，那么我们就应该考虑是否还要应用它。因为应用一种技术的目的是为了降低软件项目的复杂度，而不是相反。这一点我在开篇就强调了。但也许有些听者晚到了，没有听到。
2，引起争论的另一个地方是有听者觉得我主要谈的是结构化异常处理（SEH），不是C++的异常处理机制。事实上，因为我讨论的是针对Windows操作系统和MS Visual C++编译器。因此，EH是基于SEH之上实现的。EH只是简单的做些包装就把C++的异常转变为SEH统一处理了。也正是因为这个原因，在Windows下，C++异常捕捉块(VC编译器)也可以捕捉到CPU定义的除0等异常。
尽管有不同意见，很多人还是很有同感的赞同我提出的结论。
模块内和内部模块之间不要用抛出异常代替错误返回；
设置全局性的异常预处理和未处理异常补救措施（类似Windows XP引入的向量化异常处理机制, VEH）；
定义完善的错误处理政策和机制
错误日志
错误代码格式
人近30
人近30,即将进入而立之年. 30岁,应该是什么样子呢?
1. 30岁,应该会欣赏音乐,能倾听每一个音符. 而不能还是天天听着流行歌曲,那应该是怀旧时才会听的.
2. 30岁,应该会品茶. 能安静的看着一片茶叶,慢慢的在开水中展开;开水的颜色,慢慢的浸成浅绿色.
3. 30岁,应该知道了40岁时,自己需要做什么. 那是一生的选择,决定的自己完整的人生在社会中最终留下什么.
4. 30岁,应该领着自己的孩子,在公园的小湖边上,锻炼身体.
5. 30岁,应该记得每周领着父母,去爬爬山,或者一起聊聊天.
6. 30岁,应该每天都在拼搏自己的事业,为自己的工作尽心竭力.
7. 30岁,应该有自己的几个志同道合的朋友,一起奋斗,一起互相帮助.
人近30, 为了30岁时的样子而修养.
1. 30岁,应该会欣赏音乐,能倾听每一个音符. 而不能还是天天听着流行歌曲,那应该是怀旧时才会听的.
2. 30岁,应该会品茶. 能安静的看着一片茶叶,慢慢的在开水中展开;开水的颜色,慢慢的浸成浅绿色.
3. 30岁,应该知道了40岁时,自己需要做什么. 那是一生的选择,决定的自己完整的人生在社会中最终留下什么.
4. 30岁,应该领着自己的孩子,在公园的小湖边上,锻炼身体.
5. 30岁,应该记得每周领着父母,去爬爬山,或者一起聊聊天.
6. 30岁,应该每天都在拼搏自己的事业,为自己的工作尽心竭力.
7. 30岁,应该有自己的几个志同道合的朋友,一起奋斗,一起互相帮助.
人近30, 为了30岁时的样子而修养.
2007年5月17日星期四
第一次上路记
行程: 从保富寺经朝阳公园桥，走朝阳北路，到通州北关环岛。
所犯错误：
1。在北航入四环的口熄火，若干次重新启动，一走就熄。大约7-8次，静心检查，发现是挡位在4档。。。。。
2。从红领巾桥上朝阳北路时，不幸没有走对路，绕了下又上了四环，左拐弯调头后，回到朝阳北路。
3。在朝阳北路的一个红绿灯口，由于我在左拐弯线上，需要右并道，右后侧是一辆货车，我把车头并过点，那位师傅很照顾的把路让给了我。
4。在朝阳北路等红灯时，一辆Siena闲我慢，想超车，我没有让。一个富康车别过车头要并道，我让了他先过。
5。整个路上多次熄火，汗。。。
6。到60公里时，都没有加5档，汗；基本都在4档跑了。
7。给油门偏重，过红绿灯口时，一档起步，加油到2500左右，换2档。还有很多次是2200左右，就欢档，是不是很伤车？正常跑时，基本把砖算维持在1800到2200之间。
8。今天还并了好几次道，我看后视镜，车和我距离允许，就打灯，小拐过去，看反映，然后打拐过去。本来想，一路上能不并道就不并道的。。。
说实话，北京的司机师傅没有大家说得那么凶悍阿，都还是挺文明的。在学院桥上，我后面的一辆740，一直在我后面保持一定距离（估计看见我在北航门前的熄火了：），我没有及时启动也没有按喇叭催我。总的来说，第一天上路，感谢各位司机师傅关照了。（我下午还没有贴实习标，呵呵，晚上贴上了）。
所犯错误：
1。在北航入四环的口熄火，若干次重新启动，一走就熄。大约7-8次，静心检查，发现是挡位在4档。。。。。
2。从红领巾桥上朝阳北路时，不幸没有走对路，绕了下又上了四环，左拐弯调头后，回到朝阳北路。
3。在朝阳北路的一个红绿灯口，由于我在左拐弯线上，需要右并道，右后侧是一辆货车，我把车头并过点，那位师傅很照顾的把路让给了我。
4。在朝阳北路等红灯时，一辆Siena闲我慢，想超车，我没有让。一个富康车别过车头要并道，我让了他先过。
5。整个路上多次熄火，汗。。。
6。到60公里时，都没有加5档，汗；基本都在4档跑了。
7。给油门偏重，过红绿灯口时，一档起步，加油到2500左右，换2档。还有很多次是2200左右，就欢档，是不是很伤车？正常跑时，基本把砖算维持在1800到2200之间。
8。今天还并了好几次道，我看后视镜，车和我距离允许，就打灯，小拐过去，看反映，然后打拐过去。本来想，一路上能不并道就不并道的。。。
说实话，北京的司机师傅没有大家说得那么凶悍阿，都还是挺文明的。在学院桥上，我后面的一辆740，一直在我后面保持一定距离（估计看见我在北航门前的熄火了：），我没有及时启动也没有按喇叭催我。总的来说，第一天上路，感谢各位司机师傅关照了。（我下午还没有贴实习标，呵呵，晚上贴上了）。
2007年5月16日星期三
建立一个好团队[转]
(原文<美国式团队>)
一、团队精神
团队精神反映一个人的素质、一个人的能力，一个人与别人合作的精神和能力。一个团队是个有机的整体，作为个人，只有完全融入到这个有机整体之中，才能最大限度地体现自己的价值。
团队是由一群有缺点的人构成的，没有哪一个个体是完美的，只有总体搭配起来，才能够发挥出团队的最大力量；各种不同人才的搭配，才会实现一个完美的团队。所以，每一个人都应该明确在团队当中应该扮演一个什么样的角色，在这个团队中究竟能够起到多大的作用。
所有团队成员都必须记住：世上没有完美的个体，只有完美的团队。惟有一个建立健全的团队，才能带给个体最大的发展机会，使个体始终立于不败之地。
企业要使自身处于最佳发展状态，团队精神是必不可少的，团队精神是企业发展的灵魂。一个群体不能形成团队，就是一盘散沙；一个团队没有共同的价值观，就不会统一意志、统一行动，当然就不会有战斗力。说到底，团队精神是一个企业的灵魂，也是一个人能否被重用的重要标准！
团队精神是指团队的成员为了团队的利益和目标而相互协作、尽心尽力的意愿和作风。
二、团队与工作群体
什么是团队？
工作群体，指两个或两个以上相互作用、相互依赖的个体，为了实现某一特定工作目标而组成的集合体。
团队是一种为了实现某一目标而由项目协作的个体组成的正式群体。
团队和工作群体最大的不同，就是团队成员既需要个人责任感，也需要相互负责。团队比工作群体更依赖于讨论、争论、冲突和决策，更依赖于分享信息和交流最佳经验，更依赖于在业绩水平上的相互提高和共同进步。
美国团队理念认为，每一个团队成员的工作，都是为了与其他的团队成员共同完成团队的目标。他们通过共同的努力产生积极协同作用，这种作用的结果使得个人所做的贡献形成互补，取得比工作群体更大的业绩，使团队的绩效水平远远高于个体成员绩效的总和。
团队内个体间的互助及信息共享，会直接影响一个团队，从而对一个企业的工作效率起到深远的影响。
企业拥有强大竞争力的根源，不在于其员工个人能力的卓越，而在于其员工整体“团队合力”的强大。
团队和工作群体的关系应该是：工作群体是团队的基础，团队始于工作群体，但团队能达到更高的质量水准。所有的团队都是群体，只有正式群体才能成为团队。
美国将团队定义为，是由两个或两个以上、相互依赖、承诺共同的规则、具有共同的愿望、愿意为共同的目标而努力的互补技能成员组成的群体，通过相互的沟通、信任、合作和承担责任，产生群体的协作效应，从而获得比个体成员绩效总和大得多的团队绩效。
三、团队精神核心
团队精神的核心在于协同合作，强调团队合力，注重整体优势，远离个人英雄主义。
协同合作的实质是要充分利用和发挥团队所有成员的个体优势去作好这项工作，所以，必须善用团队的各种资源，才能在有限的资源下创造最佳的工作绩效。
团队合作的最大特色是团队成员在才能上应该是互补的，在共同完成目标任务时必须发挥每个人的特长，并注重在流程中发挥作用，才能使之产生协同效应。
团队合作不等于简单的相互帮助，最终目的是为了使团队的工作业绩超过成员个人的业绩，让团队业绩由各部分组成而又大于各部分之和，这就是协作精神。
案例：攀岩
四、团队成员的合作能力
案例：鱼与渔杆的故事
团队成员间应该互相依存、同舟共济、互敬互重、礼貌谦逊；彼此宽容，尊重个性的差异；彼此信任，待人真诚，遵守承诺；互相关怀，大家共同提高；利益和成就共享，责任和义务共担。
作为团队中的一员，团队合作能力是其生存之本，因此，必须让自己得到可能多的认可和支持，而其中的关键是尊重他人。
培养团队合作能力，最核心的一点，就是培养良好的与人相处的心态与交流、沟通能力。这不仅是培养团队精神的需要，而且也是获得快乐人生的重要方面。
要培养自己的团队合作能力，需要从两方面着手：一是让他人喜欢你，二是对他人寄予希望。
团队是众多个体的有机组合，它不需要独行狼式的我行我素，而需要蚂蚁般的抱成团儿的集体精神。
五、如何培养团队合作能力
1、欣赏，学会欣赏、懂得欣赏
很多时候，同处于一个团队中的工作伙伴常常会乱设“敌人”，尤其是大家因某事而分出了高低时，落在后面的人的心里就会很容易酸溜溜的。所以，每个人都要先把心态摆正，用客观的目光去看看“假想敌”到底有没有长处，哪怕是一点点比自己好的地方都是值得学习的。
欣赏同一个团队的每一个成员，就是在为团队增加助力；改掉自身的缺点，就是在消灭团队的弱点。
欣赏就是主动去寻找团队成员的积极品质，尤其是你的“敌人”，然后，向学习这些品质，并努力克服和改正自身的缺点和消极品质。这是培养团队合作能力的第一步。
三人行，必有我师。每一个人的身上都会有闪光点，都值得我们去挖掘并学习。要想成功地融入团队之中，善于发现每个工作伙伴的优点，是走进他们身边、走进他们之中的第一步。
适度的谦虚并不会让你失去自信，只会让你正视自己的短处，看到他人的长处，从而赢得众人的喜爱。
每个人都可能会觉得自己在某个方面比其他人强，但你更应该将自己的注意力放在他人的强项上。因为团队中的任何一位成员，都可能是某个领域的专家。因此，你必须保持足够的谦虚，这种压力会促使你在团队中不断进步，并真正看清自己的肤浅、缺憾和无知。
总之，团队的效率在于每个成员配合的默契，而这种默契来自于团队成员的互相欣赏和熟悉——欣赏长处、熟悉短处，最主要的是扬长避短。如果达不到这种默契，团队合作就不可能真正成功，团队成员的个人前途也将渺茫。
2、尊重，无论新人或旧人
尊重没有高低之分、地位之差和资历之别，尊重只是团队成员在交往时的一种平等的态度。平等待人，有礼有节，既尊重他人，又尽量保持自我个性，这是团队合作能力之一——尊重的最高境界。
团队是由不同的人组成的，每一个团队成员首先是一个追求自我发展和实现的个体人，然后才是一个从事工作、有着职业分工的职业人。
虽然团队中的每一个人都有着在一定的生长环境、教育环境、工作环境中逐渐形成的与他人不同的自身价值观，但他们每一个人也同样都有渴望尊重的要求，都有一种被尊重的需要，而不论其资历深浅、能力强弱。
尊重，意味着尊重他人的个性和人格，尊重他人的兴趣和爱好，尊重他人的感觉和需求，尊重他人的态度和意见，尊重他人的权利和义务，尊重他人的成就和发展。
尊重，还意味着不要求别人做你自己不愿意做或没有做到过的事情。当你不能加班时，就没有权力要求其他团队成员继续“作战”；尊重，还意味着尊重团队成员有跟你不一样的优先考虑，或许你喜欢工作到半夜，但其他团队成员也许有更好的事情可以做。
只有团队中的每一个成员都尊重彼此的意见和观点，尊重彼此的技术和能力，尊重彼此对团队的全部贡献，这个团队彩绘得到最大的发展，而这个团队中的成员也才会赢得最大的成功。
尊重能为一个团队营造出和谐融洽的气氛，使团队资源形成最大程度的共享。而如果一个团队中的每一个成员都能够将彼此的知识、能力和智慧共享，那么，这对整个团队以及每一个成员来说，无疑是一笔巨大的财富。
3、宽容，让心胸更宽广
美国人崇尚团队精神，而宽容正是他们最为推崇的一种合作基础，因为他们清楚这是一种真正的以退为进的团队策略。
雨果曾经说过，“世界上最宽阔的是海洋，比海洋更宽阔的是天空，而比天空更宽阔的则是人的心灵”。这句话无论何时何地都是适用的，即使是在角逐竞技的职场之上，宽容仍是能让你尽快融入团队之中的捷径。
宽容是团队合作中最好的润滑剂，它能消除分歧和战争，使团队成员能够互敬互重、彼此包容、和谐相处、从而安心工作，体会到合作的快乐。
试想一下，如果你冲别人大发雷霆，即使过错在于对方，谁也不能保证他不以同样的态度来回敬你。这样一来，矛盾自然也就不可避免了。反之，你如果能够以宽容的胸襟包容同事的错误，驱散弥漫在你们之间的火药味，相信你们的合作关系将更上一层楼。
如果有人握着拳，还用一副愤怒的表情来见我，我敢肯定，我的拳头会比他握的更紧，我会比他更加愤怒。
团队成员间的相互宽容，是指容纳各自的差异性和独特性，以及适当程度的包容，但并不是指无限制地纵容，一个成功的团队，只会允许宽容存在，不会让纵容有机可乘。
宽容，并不代表软弱，在团队合作中它体现出的是一种坚强的精神，它是一种以退为进的团队战术，为的是整个团队的大发展，以及为个人奠定有利的提升基础。
首先，团队成员要有较强的相容度，即要求其能够宽厚容忍、心胸宽广、忍耐力强。其次，要注意将心比心，即应尽量站在别人的立场上，衡量别人的意见、建议和感受，反思自己的态度和方法。
4、平等，不论地位和等级，真正以人为本
美国企业在这一点上的所作所为让人叹为观止，从无差别的办公室到无等级之分的停车场，每一个管理环节，都充分体现了团队的平等精神。
当每一个团队成员都处于相同的起跑线上时，他们之间就不会产生距离感，他们在合作时就会形成更加默契、紧密的关系，从而使团队效益达到最大化。
5、信任，成功协作的基石
美国管理者坚信这样一个简单的理念：如果连起码的信任都做不到，那么，团队协作就是一句空话，绝没有落实到位的可能。
人们在遇到问题时，会首先相信物；其次是相信自己和自己的经验，最后，万不得已才相信他人。而这一点，在团队合作中则是大忌。
团队是一个相互协作的群体，它需要团队成员之间建立相互信任的关系。信任是合作的基石，没有信任，就没有合作。信任是一种激励，信任更是一种力量。
团队成员在承受压力和困惑时，要相互信赖，就象荡离了秋千的空中飞人一样，他必须知道在绳的另一端有人在抓着他；团队成员在面临危机与挑战时，也要相互信任，就象合作猎捕猛兽的猎人一样，必须不存私心，共同行动。否则，到最后，这个团队以及这个团队的成员只会一事无成、毫无建树。
现代社会的发展，使职业分工越来越细，一个人单打独斗的时代已经成为过去，越来越需要集体的合作。个人的能力再强、工作做的再出色，也不能离开团队这个大的氛围。因此，团队成员只有相互信任、主动做事、乐于分享，才能共同成长，共达成功的彼岸。
信任，是整个团队能够协同合作的十分关键的一步。如果团队成员彼此间没有充分的信任，其交流就很难发生，就会丧失彼此合作的基础，整个团队也就势必形同散沙，毫无力量可言。
高效团队的一个重要特征就是团队成员之间相互信任。也就是说，团队成员彼此相信各自的品格、个性、特点和工作能力。这种信任可以在团队内部创造高度互信的互动能量，这种信任将使团队成员乐于付出，相信团队的目标并为之付出自己的责任与激情。
如果你不相信任何人，你也就不可能接纳任何人。根据团队交往的交互原则，你就不信任别人，别人也就不会信任你；相反，你以坦诚友好的方式待人，对方也往往会以同样的方式待你，那么，结果可想而知。
信任是缔造团队向前的动力，它同时也是团队成员对自身能力的高度自信。正是基于这种自信，他才会将自己的信任和支持真正交付给自己的合作对象。所以，若想获得最大的成功，就必须让自己拥有这份自信！
6、沟通，敢于沟通、勤于沟通、善于沟通，让所有人都了解你、欣赏你、喜欢你
从古至今，中国人一直将“少说话，多做事”，“沉默是金”奉为瑰宝，固执认为埋头苦干才是事业走向辉煌的制胜法宝。可却忽略了一个人身在团队之中，良好的沟通是一种必备的能力。
作为团队，成员间的沟通能力是保持团队有效沟通和旺盛生命力的必要条件；作为个体，要想在团队中获得成功，沟通是最基本的要求。沟通是团队成员获得职位、有效管理、工作成功、事业有成的必备技能之一。
在很多人的头脑中，都不能容忍另类思维的存在。于是，在追寻真理的过程中，我们不断重复着“瞎子摸象”的游戏，也许你摸到了“墙”，我摸到了“绳子”，他摸到了“柱子”……而每个人都抱着固有的思维不放，顽固地坚持着自己的意见，不管这个意见是否全面、具体。
沟通能力在团队工作中是非常重要的，现代社会是个开放的社会，当你有了好想法、好建议时，要尽快让别人了解、让上级采纳，为团队做贡献。否则，不论你有多么新奇的观点和重要的想法，如果不能让更多的人去理解和分享，那就几乎等于没有。
持续的沟通，是使团队成员能够更好地发扬团队精神的最重要的能力。团队成员惟有冲自身做起，秉持对话精神，有方法、层次地对同时发表意见并探讨问题，汇集经验和知识，才能凝聚团队共识，激发自身和团队的力量。
建立团队精神时必须掌握的沟通语言：
最重要的八个字：我承认我犯过错误！
最重要的七个字：你干了一件好事！
最重要的六个字：你的看法如何？
最重要的五个字：咱们一起干！
最重要的四个字：不妨试试！
最重要的三个字：谢谢您！
最重要的两个字：我们……
最重要的一个字：您……
7、负责，自信的面对一切
负责，不仅意味着对错误负责，对自己负责，更意味着对团队负责、对团队成员负责，并将这种负责精神落实到每一个工作的细节之中。
一个对团队工作不负责任的人，往往是一个缺乏自信的人，也是一个无法体会快乐真谛的人。要知道，当你将责任推给他人时，实际上也是将自己的快乐和信息转移给了他人。
任何有利团队荣誉、有损团队利益的事情，与每一个团队成员都是息息相关的，所有的人都拥有不可推卸的责任。如果我是公司的老板，如果有谁说那不是我的责任之类的话，我就会立刻把他开除，因为这种人显然对整个团队没有足够的专注和忠诚，缺乏责任心。
9、节俭，以小显大
在美国，节约是整个团队的事，而每一个细微之处的浪费都可能会被认为是一种品德上的缺陷。
越是优秀的员工，越要懂得事事从小处着眼，因为很多细小的环节都是与公司的前途休戚相关的。正所谓细节决定命运。所以，为了团队的整体利益，所有的团队成员都应该养成节约成本的好习惯。
由俭入奢易，由奢入俭难，要想在短时间内就将浪费的习惯彻底改掉，确实有很大的难度。但只要你下定决心，从骨子里树立自己的节约思维与习惯，那么，你就一定会在最短的时间内完成由浪费到节约这个艰难的过程。
在今天这个高度竞争的社会里，即使企业员工从小处节俭，最后聚少成多，企业所获得的成果也是十分可观的，甚至真的可以造成企业赚钱和赔钱的本质区别。
因此，当我们在工作中自主、自动和自发地极力减少不必要的浪费时，无形中就会使整个团队减少支出、降低成本，实际上也就等于为整个团队增加了利润。
如果我们在工作中能够形成习惯性节俭，使他成为我们的第二天性，那么我们就会因为这些习惯而获益，并最终赢得辉煌的事业。
10、诚信，不容置疑
古人说：人无信则不立。说的是为人处世若不诚实，不讲信用，就不能在社会上立足和建功立业。一个个体，如果不讲诚信，那么他在团队之中也将无法立足，最终会被淘汰出局。
诚信，是做人的基本准则，也是作为一名团队成员所应具备的基本价值理念——它是高于一切的。
没有合格的诚信精神，就不可能塑造出一个良好的个人形象，也就无法得到上司和团队伙伴的信赖，也就失去了与人竞争的资本。唯有诚信，才是让你在竞争中得到多助之地的重要条件。
团队精神应该建立在团队成员之间相互信任的基础上。而只有当你做到了“言必信，信必果”时，你才能真正赢得同事的广泛信赖，同时也为自己事业的兴盛发达注入了活力。
11、肥胖，也关系到整个团队
身处团队之中，发生在团队成员身上的任何一件事情，都将关系到团队的健康发展；每一个团队成员的行为和生活方式，都影响着团队的前进步伐！
12、热心，帮助身边每一块“短木版”
职场之内，人们一致认定的竞争法则是：强者有强者的游戏规则，弱者有弱者的生存法则。
作为一个团队成员，必须记住，只有一个完全发挥作用的团队，才是一个最具竞争力的团队；而只有身处一个最具竞争力的团队之中，个体的价值才能得到最大程度的体现！
当你是团队中的那块“短木版”时，应该虚心接受“长木版”的帮助，尽一切努力提高自己的能力，不要让自己拖整个团队的后腿，当你是团队中的那块“长木版”时，你不能只顾自己前进的脚步，而忽略了“短木版”的存在，那么，你收获的终将是与“短木版”一样的成就。
当我们身处于一个团队中时，只有想方设法让短木版达到长木版的高度，或者让所有的板子维持“足够高”的相等高度，才能完全发挥团队作用。
13、个性，坚持自己的特质，要的就是与众不同
团队精神不是集体主义，不是泯灭个性、扼杀独立思考。一个好的团队，应该鼓励和正确引导员工个人能力的最大发挥。
团队成员个人能力的最大发挥，其实是个人英雄主义的最好体现。个人英雄主义在工作中往往表现为个性的彰显，更包含有创造性的工作，以及勇于面对压力和敢于承担责任的勇气。团队若能给团队成员提供一个充分施展、表现自己才能的机会，那么，这将会为团队带来永不枯竭的创新能力！
诚然，团队精神的核心在于协同合作，强调团队合力，注重整体优势，远离个人英雄主义，但追求趋同的结果必然导致团队成员的个性创造和个性发挥被扭曲和湮没，而没有个性，就意味着没有创造，这样的团队只有简单复制功能，而不具备持续创新能力。
团队不仅仅是人的集合，更是能量的结合与爆发。
作为团队成员，不要因为身处团队之中就抹杀了自己的个性特质。记住，团队制度的建立是为了更好的发挥成员的才能，只要你不逾矩，那你就完全可以随心所欲。“八仙过海，各显神通”地开展你的工作。
14、团队利益，至高无上
皮之不存，毛将焉附
团队精神不反对个性张扬，但个性必须与团队的行动一致，要有整体意识、全局观念，要考虑到整个团队的需要，并不遗余力地为整个团队的目标而共同努力。
只有当团队成员自觉思考到团队的整体利益时，他才会在遇到让人不知所措的难题时，以让团队利益达到最大化为根本，义无返顾地去做，自然不会因为工作中跟相关部门的摩擦而耿耿于怀，也不会为同事之间意见的分歧而斤斤计较，更不会因为公司对自己的一时错待而怨恨于心。
对上司和公司的决定需要保持高度的认同感，这也是全局意识的一种体现。因为上司或公司高层正是一支团队的指挥中枢，每位下属或员工都必须听命于他们，与他们精诚合作，这个团队才能保持旺盛而持久的战斗力，企业才能发展壮大。
在团队之中，一个人与整个团队相比，是渺小的，太过计较个人得失的人，永远不会真正融入到团队之中！而拥有极强全局意识的人，最终会是一个最大的受益者！
15、超越自我的团队意识
强调团队合作，并不意味着否认个人智慧、个人价值，个人的聪明才智只有与团队的共同目标一致时，其价值才能得到最大化的体现。
成功的团队提供给我们的是尝试积极开展合作的机会，而我们所要做的是，在其中寻找到我们生活中真正重要的东西——乐趣——工作的乐趣，合作的乐趣。
团队成员只有对团队拥有强烈的归属感，强烈地感觉到自己是团队的一员，才会真正快乐地投身于团队的工作之中，体会到工作对于人生价值的重要性。
16、永远不要抛开你的队友
杰克·韦尔奇有句关于团队的名言：你可以拿走我的企业，但不能拿走我的团队，只要我的团队在，我就能再开创一个更加辉煌的企业。这是通用的路标，也是我们现代企业中生存必须秉持的原则。
现代企业需要协调不同类型，不同性格的人员共同奋斗，如果你不是一个领军型人才，如果你缺乏一定的合作精神，那么，你的晋升之路将倍加坎坷，甚至遥遥无期。
17、“我们”，Forever！
不是“他们”、“你们、“你”、“他”、“我”，而是“我们”!
如果你想成为一名合格的团队领导，甚或只是一名合格的团队成员，那么，你就必须努力养成不在团队中使用第一人称的习惯，因为你在团队中所做过的每一件事情，几乎都是与他人一起合作完成的，都是由“我们”共同来承担的。所以，当你又想说出“我”这个字的时候，请你认真回想一下你所有的同事、伙伴和下属，以及那些你可能遗漏的人们……
如果你经常使用“你们”、“他们”等人称，那么在无形中你就会表现出一种疏离感，散发出一种“生人勿近”的气息，久而久之，你会被整个团队孤立起来，成为一个和谐团队中最不和谐的音符。这样的你，又何谈事业与前程？
管理者和企业员工在用“我”来代替整个团队的“我们”时，就已经习惯了把整个团队的功劳归于己身，在论功行赏时忽视整个团队的努力，使整个团队都成为“我”本身的附属品，致使团队人心涣散、一盘散沙，战斗力也无从谈起。
一个企业就象一部机器，机器的正常运转需要每个部件的相互配合，缺一不可，否则，就会影响到整个企业的效率，使整个团队处于瘫痪状态。
六、团队管理
1、资源共享，真正意义上的团队合作
团队工作的核心是协同合作，协同合作的重点在于资源共享，只有达到了真正的资源共享，这个团队才是真正意义上的团结合作的组织。
资源共享举措：
图书馆
知识库管理系统，搜集整理各种知识
项目产品事后分析报告，揭露存在的问题
休假会
定期过程审计，是技术交换的过程，是发现先进典型的过程，是学习的过程。
产品质量信息公布
通过学习交流实现资源共享
不同部门不同场合的多种交流
成功地将员工们的自身技能、智慧和头脑风暴纳入公司资源，使每一位团队成员都享受到了充分的资源支持，使他们可以没有后顾之忧地彼此切磋、彼此学习，从而获得不断提高，获得和提供友善帮助的机会。
资源共享是成功释放团队成员潜能的良好机制。了解更多的信息，掌握更多的资源，实际上使得员工不得不或者说是主动承担起应负的，甚至更大的责任。
正是团队资源共享的成功实践，它跨越了时间和空间的障碍，让每一位团队成员都可以随时随地的接触和管理自己与整个团队的资源，从而在团队成员之间构筑起资源共享的渠道，使整个团队的办公空间被无限扩大，使团队团结得更紧密。
一位理智的团队成员会做到资源共享，这样可以让自己更清楚团队的实际情况，有利于认清团队工作的目标，从而促进自己工作的积极性，并开创出一片新气象。
2、同一个目标
共同的目标能够引导大家共同去追求，去努力，从而明确了企业目标是企业相成团队精神的核心动力。
要想建立一个真正意义上的团队的共同目标，就必须使团队成员之间达成和谐的共识。团队中每一位成员都必须非常清楚团队要做什么，成品会是什么模样，基本的产品策略是什么，什么时候必须完成等。
在任何项目的执行过程中，都会有一些“关键时刻”，要求团队成员在心理和情绪上必须凝聚对目标的共识，对共同的目标产生共鸣，对事情的优先级形成清楚的认识。惟有如此，团队才能团结共进，共创辉煌。
3、沟通，上情下达，下情上达，双向而不拘形式
在一个团队之内，沟通绝不是单向的，必须是一种双向互动的形式。因为，只有团队成员与团队高层之间保有无障碍的通话渠道，这个团队才是健全的，才能够真正地携手共进。
如果一个团队的沟通和互动是正确的、健康而有效的，那么就能够使这一群人的力量完全结合，从而产生相加、相乘的效果，迅速推进团队工作。
最迅速、最方便、最直接、最尊重人性的团队沟通方式，就是利用电子邮件系统。电子邮件系统为内部员工和上下级的交流提供了最大的方便，确保了相互间意见的及时交流，对消除相互间的隔阂十分有利，能够最大限度的统一整个团队的步调，共同前进。
如果一个团队陷入沟通不良的困境时，应该采取不同以往的沟通方式进行改善。比如沟通效率过低，就应考虑设立针对沟通的部门；如沟通欠缺建设性，就应该反省团队内部教育是否滞后不前。
一个成功的团队必须是充分沟通的团队。在上下级之间，如果只有命令，没有交流，必然导致领导者的独裁和团队成员积极性的丧失；在同事之间，如果彼此鼓励隔阂，也只能导致人际关系的僵硬和冷漠。
糟糕的团队沟通就象宇宙的“黑洞”一样，会将团队成员的能量和热情吞噬殆尽。与之相反，顺畅的团队沟通则有如温暖人心的艳阳，为团队成员提供源源不断的能量，帮助他们高效地完成工作。
4、敢于放权，善于授权
充分授权不仅是让团队成员能够全力发挥才能，无所阻碍地工作，也是为他们清除各种不同的障碍，让他们以自己的力量达到某种成就的好方法。自主是充分授权的基石，让他们自主判断和实施计划，自由地思考和表达他们认为应该思考和表达的事情，自由地去冒险尝试，使他们不必怕受到额外的惩罚。
充分授权是充分管理的结果，而不是忽视属下，让他们放任自流。当管理者对属下说“这是你的决定”时，他必须已经提供了完善的支持——训练、信息、资源——让属下能够作出正确的决定，这样才算充分授权。否则的话，让属下做决定等于弃他于不顾。
在充分授权的环境中，不是无政府的混乱，而是用事实和才能领导一切，因而会放弃因为骄傲所造成的愚蠢，去除自我的狭隘心理，给整个团队创造一种和谐统一的合作气氛。
精于授权，敢于担风险是管理者不能忘怀的素质。作为一个好的管理者，要学会放权，不能把权力一人独揽，要充分发挥下属的积极性，不然就会出现只有管理者忙忙碌碌，其他人却无所事事的局面，要学会大权独揽，小权分散，要学会抓大事，放小事，从而调动整个管理机构有机高效地运转。
学会适当放权的最后一部是分清楚什么是可以控制的，什么是不可以控制的，聪明的领导者会发现，想控制下属如何运作项目，如何决定以及他们提什么样的建议是不可能的，因而领导者需要放弃对下属行为的控制，转而让他们以任务为核心，专心致力于自己承担的任务。这样才能更加恰当地把个人的力量转化为整个团队的力量。
5、同等对待，就是抹杀杰出者的贡献
我们最不可忽视的是团队高效率的培养、团队精神的形成，其基础是尊重个人的兴趣和成就，设置不同的岗位，选拔不同的人才，给予不同的待遇、培养和肯定，让每一个成员都拥有特长，都表现特长，并且这样的氛围越浓厚越好。
世界因不同而丰富多彩，人类因差异而个性纷呈，区别对待表明了团队对个性的尊重。一个团队的组成并非是一些完全相同的个体，而是各有不同的个体组合在一起才能为团队带来各种不同的能力。也就是说团队需要的不是每个成员的共同点，恰恰相反，每个成员的不同点的集中才会使团队力量壮大。
经典的团队，是每个成员都经过选拔组合，特别配备的，每个成员都做着与其他人不同的事情，最重要的是团队的管理者区别对待每一个成员，通过精心设计的相应的培训，使每一位成员的个性，特长能够不断的得到发展并发挥出来，这才识名副其实的团队。
所谓的公平对待恰恰是极其不公平的，是对优秀人才的忽视，甚至会迫使优秀人才慢慢走向流失，趋于平庸化，因为他们没有得到应有的肯定而变得不再努力和突出。
6、制定规则的人，就是第一个执行的人
在一个团队中，各级管理者都起着至关重要的作用，所以，在任何一个团队中，每一级的负责人在提出工作要求、颁布管理规则的时候，要求每一个下属做到的，管理者自己必须首先要做到，每一个下属能做到的，管理者必须要做得更好。
管理者以身作则的力量和作用，无论在任何时候都是不能丢弃的，一个人没有规则意识会被认为素质低，一个管理者没有规则意识也绝不是一个优秀的管理者。
管理者决不能忽略自身对下属可能产生的影响，更需要知道自己会对下属产生深刻的影响，自己的乐观和悲观情绪会同样富有感染力，而且自己一举一动、一言一行的表现都会影响到周围所有人的情绪、语言和行为。管理者发出的信号是非常重要的。所以说，管理者的每一个决定和每一个行动都是对下属的一次绝好的培训机会.
发号施令并不能帮助管理者实现自己的意图。真正的领导是通过以身作则来实现的，而不是简单的行政命令。无论管理者喜欢与否，他的做法都会成为组织其他成员的榜样。管理者对他们有着巨大的影响，他们事事都会从他的身上寻找原型。
规则就是规则，确定下来的规则就要坚决执行。我们不缺乏规则，缺乏的是不折不扣的贯彻规则的决心和行动。
管理者应该树立起“规则意识”。否则，规则就难以维持下去，只有真正做到这一点，并且把这些意识贯彻到团队的每一位成员的每一天的工作中去，才能够建设出一个成功的团队。
7、授人以鱼与授人以渔
一个团队的管理者，要做的不仅仅是帮助团队成员完成工作，更重要的是要教会团队成员如何独立完成工作。
有时结果并不能反映出成功与失败，团队的成员们更注重的是一个过程，注重他们在这个过程中学会了什么，得到了什么、做出了什么。只有在工作过程中达到完美的配合和协作才是团队工作的真正意义所在。
团队领导肩负着让队员得到学习和成长的重任。“授人以鱼”只是解决了他一时的低层次的需求，却不可能帮助他从根本上摆脱被动，他难免要等待外界的馈赠或者施舍；“授人以渔”则使成员有了求知的能力，这样才能在今后的工作中掌握主动权，作为一个平等、独立的团队成员立足于团队之中。
帮助手下完成任务，不如教会手下如何去完成任务。
团队合作需要学习，而学习更需要团队合作，如果一个团队中，为了发展而形成一种激烈竞争的局面，不但不会促进团队成员的大力学习，还会阻碍学习的进程，使成员之间互相明争暗斗而各自为政。这样就难以发展成一个学习型组织，要成为学习型组织，先决条件是必须有和谐的内部气愤，组织内的成员才能共享知识。
8、利用内部竞争、激发团队活力
一个团队中不能缺少团结，但是更不能缺少竞争意识。没有竞争的团队就象没有波澜的死水一样，会丧失活力的，既然我们是一个团队的成员，那么就要把团队的意识放在竞争的意识之前，处处从大局考虑就可以了.
利用不同的群体，开展集体间的竞争，要在竞争中培养企业员工的团队精神，首先要巩固他们心中的集体观念。比如说尽量让员工参与集体管理，而在这一过程中，应注意分工明确、互相监督，力求让集体中的所有员工都找到自己在集体中的位置。
在处理和平衡合作与竞争的关系时，一定要强调合作高于竞争。从总体上说，团队通向成功的途径是内部合作，而不是内部竞争。在团队内，胜利必须建立在“我们一起干”的意识的基础上，而不是“我超过了同伙”的意识基础上。
不想被狼吃掉，就要学会与狼共舞，要与狼共舞，先要学会变成狼。
9、细节，体现凝聚力
团队的凝聚力，表现为团队成员对团队强烈的归属感和一体性——每个团队成员都强烈感受到自己是团队中的一分子，真正把个人工作和团队目标联系在一起，对团队表现出一种忠诚，对团队的业绩表现出一种荣誉感，对团队的成功表现出一种骄傲，对团队的困境表现出一种忧虑。
一个成功的团队管理者，必须使团队的每一个成员都能强烈的感受到自己是雄伟城墙中的一块砖，是不可缺少的一分子。而砖与砖之间的紧密结合则是建立城墙的基础，这种紧密结合就是团队的强大凝聚力。
团队凝聚力，是指团队对其成员的吸引力和成员之间的相互吸引力。它包括“向心力”和“内部团结”两层涵义。
10、旁观、还是投入？
作为旁观者，当局者的迷茫和困惑你可能会看得一清二楚，但当你主动伸出援手时，反而可能会得到一张冷脸，当局者有当局者的骄傲和自负，这种实话实说需要高度的技巧与智能，但却是建立团队精神的基础之一。
给予忠告的最佳媒介是情感，单纯的沟通效果可能只会昙花一现，你必须真的以彼此的情谊为赌注，甚至冒着失去工作的危险来讲出实话，如果不是这样，你可能很难突破对方的心理防线，让他打心底里接受你的建议。所以，请付出你那用之不竭的关怀和好意，让你讲述的事实被正面地接受。
总之，学会接受事实和学会传达真实的信息，虽然是两个方向的沟通，但却是团队合作精神的一体两面。
11、单纯，而不是世故，简单而无须复杂
一个团队是由众多的不同动机、需求与特性的人组成的，如果无法建立起一个简单而透明的规范，就会产生很多矛盾，形成大量的内耗，即使花很大的力气，也产生不了相应的成果。
要建立一个团结向上的团队，要想成为一个团结向上的团队中最具发展性的力量，我们必须养成一种“简单”和公开的工作方式。
12、信任，但不放任
一般来说，每个团队里都会有明星员工，就象一个团队的领袖一样，其他人对这个人的某方面的能力一般都特别津津乐道。而作为一名团队管理者，应该善于利用明星员工的这种效应，使他成为最支持这个团队的人，从而借助他的行为去影响其他人。
一个成熟的团队之中，绝不应该任由明星员工主导一切。如果出现了这样的管理方式。那么一定会损害团队自身。如果明星员工特别自傲，表现得难以合作，而沟通也不能解决问题，最好的办法也许是请他走人。
明星员工的存在价值，在于为团队其他成员起到表率作用，引领整个团队共同进步，而不是个人的昙花一现的荣耀。应让他学会主动的追求完美的团队表现。
放眼世界，没有一个企业是由于一个人或者是明星员工的成功而具有持久生命力的，团队的共同表现对公司的稳定、繁荣、业绩卓著才是至关重要的。
个人形象的张力是有限的，真正力挽狂澜的还是整个团队的合作实力。所以，必须正视明星员工在团队中的双面作用，真正化不利为有利，促有利为更有利。
13、提升团队士气
若想有效而持久地提升团队士气，就必须双管齐下，一面要进行激励，以图营造团队奋进的氛围；一面着手进行团队的基础建设，力求从最根本之处提高团队的业绩。
14、员工发展规划，把人才推荐到合适的位置
团队管理者的工作，是导引团队成员将个人的志向融入团队目标，辅导他们懂得配合自己的能力定出合宜的计划，从而为整个团队带来切实的利益。
企业对员工职业计划的管理过程成为职业管理，它应该为员工设计职业发展和职业援助计划，通过员工在职业目标上的努力，谋求企业的持续发展。它帮助员工完成自我定位，帮助员工克服在完成职业目标过程中遇到的挫折，鼓励员工将个人职业目标同团队目标统一起来。
因此，管理者对团队的重要职责之一就是，把人才推举到适合的位置上去，而惟有此，企业才能形成真正的团队凝聚力，才能真正留住人才，共创大业。
有效的职业管理应该处理以下问题：
员工在达成自己的职业目标时会遇到那些问题？
怎样解决这些问题？
员工的职业生涯是否可以分为若干阶段？
这些阶段的主要矛盾是什么？
团队领导者只有掌握了这些问题，才能制定相应的政策与措施，帮助员工实现职业生涯设计，为员工提供畅通的职业发展道路。
一、团队精神
团队精神反映一个人的素质、一个人的能力，一个人与别人合作的精神和能力。一个团队是个有机的整体，作为个人，只有完全融入到这个有机整体之中，才能最大限度地体现自己的价值。
团队是由一群有缺点的人构成的，没有哪一个个体是完美的，只有总体搭配起来，才能够发挥出团队的最大力量；各种不同人才的搭配，才会实现一个完美的团队。所以，每一个人都应该明确在团队当中应该扮演一个什么样的角色，在这个团队中究竟能够起到多大的作用。
所有团队成员都必须记住：世上没有完美的个体，只有完美的团队。惟有一个建立健全的团队，才能带给个体最大的发展机会，使个体始终立于不败之地。
企业要使自身处于最佳发展状态，团队精神是必不可少的，团队精神是企业发展的灵魂。一个群体不能形成团队，就是一盘散沙；一个团队没有共同的价值观，就不会统一意志、统一行动，当然就不会有战斗力。说到底，团队精神是一个企业的灵魂，也是一个人能否被重用的重要标准！
团队精神是指团队的成员为了团队的利益和目标而相互协作、尽心尽力的意愿和作风。
二、团队与工作群体
什么是团队？
工作群体，指两个或两个以上相互作用、相互依赖的个体，为了实现某一特定工作目标而组成的集合体。
团队是一种为了实现某一目标而由项目协作的个体组成的正式群体。
团队和工作群体最大的不同，就是团队成员既需要个人责任感，也需要相互负责。团队比工作群体更依赖于讨论、争论、冲突和决策，更依赖于分享信息和交流最佳经验，更依赖于在业绩水平上的相互提高和共同进步。
美国团队理念认为，每一个团队成员的工作，都是为了与其他的团队成员共同完成团队的目标。他们通过共同的努力产生积极协同作用，这种作用的结果使得个人所做的贡献形成互补，取得比工作群体更大的业绩，使团队的绩效水平远远高于个体成员绩效的总和。
团队内个体间的互助及信息共享，会直接影响一个团队，从而对一个企业的工作效率起到深远的影响。
企业拥有强大竞争力的根源，不在于其员工个人能力的卓越，而在于其员工整体“团队合力”的强大。
团队和工作群体的关系应该是：工作群体是团队的基础，团队始于工作群体，但团队能达到更高的质量水准。所有的团队都是群体，只有正式群体才能成为团队。
美国将团队定义为，是由两个或两个以上、相互依赖、承诺共同的规则、具有共同的愿望、愿意为共同的目标而努力的互补技能成员组成的群体，通过相互的沟通、信任、合作和承担责任，产生群体的协作效应，从而获得比个体成员绩效总和大得多的团队绩效。
三、团队精神核心
团队精神的核心在于协同合作，强调团队合力，注重整体优势，远离个人英雄主义。
协同合作的实质是要充分利用和发挥团队所有成员的个体优势去作好这项工作，所以，必须善用团队的各种资源，才能在有限的资源下创造最佳的工作绩效。
团队合作的最大特色是团队成员在才能上应该是互补的，在共同完成目标任务时必须发挥每个人的特长，并注重在流程中发挥作用，才能使之产生协同效应。
团队合作不等于简单的相互帮助，最终目的是为了使团队的工作业绩超过成员个人的业绩，让团队业绩由各部分组成而又大于各部分之和，这就是协作精神。
案例：攀岩
四、团队成员的合作能力
案例：鱼与渔杆的故事
团队成员间应该互相依存、同舟共济、互敬互重、礼貌谦逊；彼此宽容，尊重个性的差异；彼此信任，待人真诚，遵守承诺；互相关怀，大家共同提高；利益和成就共享，责任和义务共担。
作为团队中的一员，团队合作能力是其生存之本，因此，必须让自己得到可能多的认可和支持，而其中的关键是尊重他人。
培养团队合作能力，最核心的一点，就是培养良好的与人相处的心态与交流、沟通能力。这不仅是培养团队精神的需要，而且也是获得快乐人生的重要方面。
要培养自己的团队合作能力，需要从两方面着手：一是让他人喜欢你，二是对他人寄予希望。
团队是众多个体的有机组合，它不需要独行狼式的我行我素，而需要蚂蚁般的抱成团儿的集体精神。
五、如何培养团队合作能力
1、欣赏，学会欣赏、懂得欣赏
很多时候，同处于一个团队中的工作伙伴常常会乱设“敌人”，尤其是大家因某事而分出了高低时，落在后面的人的心里就会很容易酸溜溜的。所以，每个人都要先把心态摆正，用客观的目光去看看“假想敌”到底有没有长处，哪怕是一点点比自己好的地方都是值得学习的。
欣赏同一个团队的每一个成员，就是在为团队增加助力；改掉自身的缺点，就是在消灭团队的弱点。
欣赏就是主动去寻找团队成员的积极品质，尤其是你的“敌人”，然后，向学习这些品质，并努力克服和改正自身的缺点和消极品质。这是培养团队合作能力的第一步。
三人行，必有我师。每一个人的身上都会有闪光点，都值得我们去挖掘并学习。要想成功地融入团队之中，善于发现每个工作伙伴的优点，是走进他们身边、走进他们之中的第一步。
适度的谦虚并不会让你失去自信，只会让你正视自己的短处，看到他人的长处，从而赢得众人的喜爱。
每个人都可能会觉得自己在某个方面比其他人强，但你更应该将自己的注意力放在他人的强项上。因为团队中的任何一位成员，都可能是某个领域的专家。因此，你必须保持足够的谦虚，这种压力会促使你在团队中不断进步，并真正看清自己的肤浅、缺憾和无知。
总之，团队的效率在于每个成员配合的默契，而这种默契来自于团队成员的互相欣赏和熟悉——欣赏长处、熟悉短处，最主要的是扬长避短。如果达不到这种默契，团队合作就不可能真正成功，团队成员的个人前途也将渺茫。
2、尊重，无论新人或旧人
尊重没有高低之分、地位之差和资历之别，尊重只是团队成员在交往时的一种平等的态度。平等待人，有礼有节，既尊重他人，又尽量保持自我个性，这是团队合作能力之一——尊重的最高境界。
团队是由不同的人组成的，每一个团队成员首先是一个追求自我发展和实现的个体人，然后才是一个从事工作、有着职业分工的职业人。
虽然团队中的每一个人都有着在一定的生长环境、教育环境、工作环境中逐渐形成的与他人不同的自身价值观，但他们每一个人也同样都有渴望尊重的要求，都有一种被尊重的需要，而不论其资历深浅、能力强弱。
尊重，意味着尊重他人的个性和人格，尊重他人的兴趣和爱好，尊重他人的感觉和需求，尊重他人的态度和意见，尊重他人的权利和义务，尊重他人的成就和发展。
尊重，还意味着不要求别人做你自己不愿意做或没有做到过的事情。当你不能加班时，就没有权力要求其他团队成员继续“作战”；尊重，还意味着尊重团队成员有跟你不一样的优先考虑，或许你喜欢工作到半夜，但其他团队成员也许有更好的事情可以做。
只有团队中的每一个成员都尊重彼此的意见和观点，尊重彼此的技术和能力，尊重彼此对团队的全部贡献，这个团队彩绘得到最大的发展，而这个团队中的成员也才会赢得最大的成功。
尊重能为一个团队营造出和谐融洽的气氛，使团队资源形成最大程度的共享。而如果一个团队中的每一个成员都能够将彼此的知识、能力和智慧共享，那么，这对整个团队以及每一个成员来说，无疑是一笔巨大的财富。
3、宽容，让心胸更宽广
美国人崇尚团队精神，而宽容正是他们最为推崇的一种合作基础，因为他们清楚这是一种真正的以退为进的团队策略。
雨果曾经说过，“世界上最宽阔的是海洋，比海洋更宽阔的是天空，而比天空更宽阔的则是人的心灵”。这句话无论何时何地都是适用的，即使是在角逐竞技的职场之上，宽容仍是能让你尽快融入团队之中的捷径。
宽容是团队合作中最好的润滑剂，它能消除分歧和战争，使团队成员能够互敬互重、彼此包容、和谐相处、从而安心工作，体会到合作的快乐。
试想一下，如果你冲别人大发雷霆，即使过错在于对方，谁也不能保证他不以同样的态度来回敬你。这样一来，矛盾自然也就不可避免了。反之，你如果能够以宽容的胸襟包容同事的错误，驱散弥漫在你们之间的火药味，相信你们的合作关系将更上一层楼。
如果有人握着拳，还用一副愤怒的表情来见我，我敢肯定，我的拳头会比他握的更紧，我会比他更加愤怒。
团队成员间的相互宽容，是指容纳各自的差异性和独特性，以及适当程度的包容，但并不是指无限制地纵容，一个成功的团队，只会允许宽容存在，不会让纵容有机可乘。
宽容，并不代表软弱，在团队合作中它体现出的是一种坚强的精神，它是一种以退为进的团队战术，为的是整个团队的大发展，以及为个人奠定有利的提升基础。
首先，团队成员要有较强的相容度，即要求其能够宽厚容忍、心胸宽广、忍耐力强。其次，要注意将心比心，即应尽量站在别人的立场上，衡量别人的意见、建议和感受，反思自己的态度和方法。
4、平等，不论地位和等级，真正以人为本
美国企业在这一点上的所作所为让人叹为观止，从无差别的办公室到无等级之分的停车场，每一个管理环节，都充分体现了团队的平等精神。
当每一个团队成员都处于相同的起跑线上时，他们之间就不会产生距离感，他们在合作时就会形成更加默契、紧密的关系，从而使团队效益达到最大化。
5、信任，成功协作的基石
美国管理者坚信这样一个简单的理念：如果连起码的信任都做不到，那么，团队协作就是一句空话，绝没有落实到位的可能。
人们在遇到问题时，会首先相信物；其次是相信自己和自己的经验，最后，万不得已才相信他人。而这一点，在团队合作中则是大忌。
团队是一个相互协作的群体，它需要团队成员之间建立相互信任的关系。信任是合作的基石，没有信任，就没有合作。信任是一种激励，信任更是一种力量。
团队成员在承受压力和困惑时，要相互信赖，就象荡离了秋千的空中飞人一样，他必须知道在绳的另一端有人在抓着他；团队成员在面临危机与挑战时，也要相互信任，就象合作猎捕猛兽的猎人一样，必须不存私心，共同行动。否则，到最后，这个团队以及这个团队的成员只会一事无成、毫无建树。
现代社会的发展，使职业分工越来越细，一个人单打独斗的时代已经成为过去，越来越需要集体的合作。个人的能力再强、工作做的再出色，也不能离开团队这个大的氛围。因此，团队成员只有相互信任、主动做事、乐于分享，才能共同成长，共达成功的彼岸。
信任，是整个团队能够协同合作的十分关键的一步。如果团队成员彼此间没有充分的信任，其交流就很难发生，就会丧失彼此合作的基础，整个团队也就势必形同散沙，毫无力量可言。
高效团队的一个重要特征就是团队成员之间相互信任。也就是说，团队成员彼此相信各自的品格、个性、特点和工作能力。这种信任可以在团队内部创造高度互信的互动能量，这种信任将使团队成员乐于付出，相信团队的目标并为之付出自己的责任与激情。
如果你不相信任何人，你也就不可能接纳任何人。根据团队交往的交互原则，你就不信任别人，别人也就不会信任你；相反，你以坦诚友好的方式待人，对方也往往会以同样的方式待你，那么，结果可想而知。
信任是缔造团队向前的动力，它同时也是团队成员对自身能力的高度自信。正是基于这种自信，他才会将自己的信任和支持真正交付给自己的合作对象。所以，若想获得最大的成功，就必须让自己拥有这份自信！
6、沟通，敢于沟通、勤于沟通、善于沟通，让所有人都了解你、欣赏你、喜欢你
从古至今，中国人一直将“少说话，多做事”，“沉默是金”奉为瑰宝，固执认为埋头苦干才是事业走向辉煌的制胜法宝。可却忽略了一个人身在团队之中，良好的沟通是一种必备的能力。
作为团队，成员间的沟通能力是保持团队有效沟通和旺盛生命力的必要条件；作为个体，要想在团队中获得成功，沟通是最基本的要求。沟通是团队成员获得职位、有效管理、工作成功、事业有成的必备技能之一。
在很多人的头脑中，都不能容忍另类思维的存在。于是，在追寻真理的过程中，我们不断重复着“瞎子摸象”的游戏，也许你摸到了“墙”，我摸到了“绳子”，他摸到了“柱子”……而每个人都抱着固有的思维不放，顽固地坚持着自己的意见，不管这个意见是否全面、具体。
沟通能力在团队工作中是非常重要的，现代社会是个开放的社会，当你有了好想法、好建议时，要尽快让别人了解、让上级采纳，为团队做贡献。否则，不论你有多么新奇的观点和重要的想法，如果不能让更多的人去理解和分享，那就几乎等于没有。
持续的沟通，是使团队成员能够更好地发扬团队精神的最重要的能力。团队成员惟有冲自身做起，秉持对话精神，有方法、层次地对同时发表意见并探讨问题，汇集经验和知识，才能凝聚团队共识，激发自身和团队的力量。
建立团队精神时必须掌握的沟通语言：
最重要的八个字：我承认我犯过错误！
最重要的七个字：你干了一件好事！
最重要的六个字：你的看法如何？
最重要的五个字：咱们一起干！
最重要的四个字：不妨试试！
最重要的三个字：谢谢您！
最重要的两个字：我们……
最重要的一个字：您……
7、负责，自信的面对一切
负责，不仅意味着对错误负责，对自己负责，更意味着对团队负责、对团队成员负责，并将这种负责精神落实到每一个工作的细节之中。
一个对团队工作不负责任的人，往往是一个缺乏自信的人，也是一个无法体会快乐真谛的人。要知道，当你将责任推给他人时，实际上也是将自己的快乐和信息转移给了他人。
任何有利团队荣誉、有损团队利益的事情，与每一个团队成员都是息息相关的，所有的人都拥有不可推卸的责任。如果我是公司的老板，如果有谁说那不是我的责任之类的话，我就会立刻把他开除，因为这种人显然对整个团队没有足够的专注和忠诚，缺乏责任心。
9、节俭，以小显大
在美国，节约是整个团队的事，而每一个细微之处的浪费都可能会被认为是一种品德上的缺陷。
越是优秀的员工，越要懂得事事从小处着眼，因为很多细小的环节都是与公司的前途休戚相关的。正所谓细节决定命运。所以，为了团队的整体利益，所有的团队成员都应该养成节约成本的好习惯。
由俭入奢易，由奢入俭难，要想在短时间内就将浪费的习惯彻底改掉，确实有很大的难度。但只要你下定决心，从骨子里树立自己的节约思维与习惯，那么，你就一定会在最短的时间内完成由浪费到节约这个艰难的过程。
在今天这个高度竞争的社会里，即使企业员工从小处节俭，最后聚少成多，企业所获得的成果也是十分可观的，甚至真的可以造成企业赚钱和赔钱的本质区别。
因此，当我们在工作中自主、自动和自发地极力减少不必要的浪费时，无形中就会使整个团队减少支出、降低成本，实际上也就等于为整个团队增加了利润。
如果我们在工作中能够形成习惯性节俭，使他成为我们的第二天性，那么我们就会因为这些习惯而获益，并最终赢得辉煌的事业。
10、诚信，不容置疑
古人说：人无信则不立。说的是为人处世若不诚实，不讲信用，就不能在社会上立足和建功立业。一个个体，如果不讲诚信，那么他在团队之中也将无法立足，最终会被淘汰出局。
诚信，是做人的基本准则，也是作为一名团队成员所应具备的基本价值理念——它是高于一切的。
没有合格的诚信精神，就不可能塑造出一个良好的个人形象，也就无法得到上司和团队伙伴的信赖，也就失去了与人竞争的资本。唯有诚信，才是让你在竞争中得到多助之地的重要条件。
团队精神应该建立在团队成员之间相互信任的基础上。而只有当你做到了“言必信，信必果”时，你才能真正赢得同事的广泛信赖，同时也为自己事业的兴盛发达注入了活力。
11、肥胖，也关系到整个团队
身处团队之中，发生在团队成员身上的任何一件事情，都将关系到团队的健康发展；每一个团队成员的行为和生活方式，都影响着团队的前进步伐！
12、热心，帮助身边每一块“短木版”
职场之内，人们一致认定的竞争法则是：强者有强者的游戏规则，弱者有弱者的生存法则。
作为一个团队成员，必须记住，只有一个完全发挥作用的团队，才是一个最具竞争力的团队；而只有身处一个最具竞争力的团队之中，个体的价值才能得到最大程度的体现！
当你是团队中的那块“短木版”时，应该虚心接受“长木版”的帮助，尽一切努力提高自己的能力，不要让自己拖整个团队的后腿，当你是团队中的那块“长木版”时，你不能只顾自己前进的脚步，而忽略了“短木版”的存在，那么，你收获的终将是与“短木版”一样的成就。
当我们身处于一个团队中时，只有想方设法让短木版达到长木版的高度，或者让所有的板子维持“足够高”的相等高度，才能完全发挥团队作用。
13、个性，坚持自己的特质，要的就是与众不同
团队精神不是集体主义，不是泯灭个性、扼杀独立思考。一个好的团队，应该鼓励和正确引导员工个人能力的最大发挥。
团队成员个人能力的最大发挥，其实是个人英雄主义的最好体现。个人英雄主义在工作中往往表现为个性的彰显，更包含有创造性的工作，以及勇于面对压力和敢于承担责任的勇气。团队若能给团队成员提供一个充分施展、表现自己才能的机会，那么，这将会为团队带来永不枯竭的创新能力！
诚然，团队精神的核心在于协同合作，强调团队合力，注重整体优势，远离个人英雄主义，但追求趋同的结果必然导致团队成员的个性创造和个性发挥被扭曲和湮没，而没有个性，就意味着没有创造，这样的团队只有简单复制功能，而不具备持续创新能力。
团队不仅仅是人的集合，更是能量的结合与爆发。
作为团队成员，不要因为身处团队之中就抹杀了自己的个性特质。记住，团队制度的建立是为了更好的发挥成员的才能，只要你不逾矩，那你就完全可以随心所欲。“八仙过海，各显神通”地开展你的工作。
14、团队利益，至高无上
皮之不存，毛将焉附
团队精神不反对个性张扬，但个性必须与团队的行动一致，要有整体意识、全局观念，要考虑到整个团队的需要，并不遗余力地为整个团队的目标而共同努力。
只有当团队成员自觉思考到团队的整体利益时，他才会在遇到让人不知所措的难题时，以让团队利益达到最大化为根本，义无返顾地去做，自然不会因为工作中跟相关部门的摩擦而耿耿于怀，也不会为同事之间意见的分歧而斤斤计较，更不会因为公司对自己的一时错待而怨恨于心。
对上司和公司的决定需要保持高度的认同感，这也是全局意识的一种体现。因为上司或公司高层正是一支团队的指挥中枢，每位下属或员工都必须听命于他们，与他们精诚合作，这个团队才能保持旺盛而持久的战斗力，企业才能发展壮大。
在团队之中，一个人与整个团队相比，是渺小的，太过计较个人得失的人，永远不会真正融入到团队之中！而拥有极强全局意识的人，最终会是一个最大的受益者！
15、超越自我的团队意识
强调团队合作，并不意味着否认个人智慧、个人价值，个人的聪明才智只有与团队的共同目标一致时，其价值才能得到最大化的体现。
成功的团队提供给我们的是尝试积极开展合作的机会，而我们所要做的是，在其中寻找到我们生活中真正重要的东西——乐趣——工作的乐趣，合作的乐趣。
团队成员只有对团队拥有强烈的归属感，强烈地感觉到自己是团队的一员，才会真正快乐地投身于团队的工作之中，体会到工作对于人生价值的重要性。
16、永远不要抛开你的队友
杰克·韦尔奇有句关于团队的名言：你可以拿走我的企业，但不能拿走我的团队，只要我的团队在，我就能再开创一个更加辉煌的企业。这是通用的路标，也是我们现代企业中生存必须秉持的原则。
现代企业需要协调不同类型，不同性格的人员共同奋斗，如果你不是一个领军型人才，如果你缺乏一定的合作精神，那么，你的晋升之路将倍加坎坷，甚至遥遥无期。
17、“我们”，Forever！
不是“他们”、“你们、“你”、“他”、“我”，而是“我们”!
如果你想成为一名合格的团队领导，甚或只是一名合格的团队成员，那么，你就必须努力养成不在团队中使用第一人称的习惯，因为你在团队中所做过的每一件事情，几乎都是与他人一起合作完成的，都是由“我们”共同来承担的。所以，当你又想说出“我”这个字的时候，请你认真回想一下你所有的同事、伙伴和下属，以及那些你可能遗漏的人们……
如果你经常使用“你们”、“他们”等人称，那么在无形中你就会表现出一种疏离感，散发出一种“生人勿近”的气息，久而久之，你会被整个团队孤立起来，成为一个和谐团队中最不和谐的音符。这样的你，又何谈事业与前程？
管理者和企业员工在用“我”来代替整个团队的“我们”时，就已经习惯了把整个团队的功劳归于己身，在论功行赏时忽视整个团队的努力，使整个团队都成为“我”本身的附属品，致使团队人心涣散、一盘散沙，战斗力也无从谈起。
一个企业就象一部机器，机器的正常运转需要每个部件的相互配合，缺一不可，否则，就会影响到整个企业的效率，使整个团队处于瘫痪状态。
六、团队管理
1、资源共享，真正意义上的团队合作
团队工作的核心是协同合作，协同合作的重点在于资源共享，只有达到了真正的资源共享，这个团队才是真正意义上的团结合作的组织。
资源共享举措：
图书馆
知识库管理系统，搜集整理各种知识
项目产品事后分析报告，揭露存在的问题
休假会
定期过程审计，是技术交换的过程，是发现先进典型的过程，是学习的过程。
产品质量信息公布
通过学习交流实现资源共享
不同部门不同场合的多种交流
成功地将员工们的自身技能、智慧和头脑风暴纳入公司资源，使每一位团队成员都享受到了充分的资源支持，使他们可以没有后顾之忧地彼此切磋、彼此学习，从而获得不断提高，获得和提供友善帮助的机会。
资源共享是成功释放团队成员潜能的良好机制。了解更多的信息，掌握更多的资源，实际上使得员工不得不或者说是主动承担起应负的，甚至更大的责任。
正是团队资源共享的成功实践，它跨越了时间和空间的障碍，让每一位团队成员都可以随时随地的接触和管理自己与整个团队的资源，从而在团队成员之间构筑起资源共享的渠道，使整个团队的办公空间被无限扩大，使团队团结得更紧密。
一位理智的团队成员会做到资源共享，这样可以让自己更清楚团队的实际情况，有利于认清团队工作的目标，从而促进自己工作的积极性，并开创出一片新气象。
2、同一个目标
共同的目标能够引导大家共同去追求，去努力，从而明确了企业目标是企业相成团队精神的核心动力。
要想建立一个真正意义上的团队的共同目标，就必须使团队成员之间达成和谐的共识。团队中每一位成员都必须非常清楚团队要做什么，成品会是什么模样，基本的产品策略是什么，什么时候必须完成等。
在任何项目的执行过程中，都会有一些“关键时刻”，要求团队成员在心理和情绪上必须凝聚对目标的共识，对共同的目标产生共鸣，对事情的优先级形成清楚的认识。惟有如此，团队才能团结共进，共创辉煌。
3、沟通，上情下达，下情上达，双向而不拘形式
在一个团队之内，沟通绝不是单向的，必须是一种双向互动的形式。因为，只有团队成员与团队高层之间保有无障碍的通话渠道，这个团队才是健全的，才能够真正地携手共进。
如果一个团队的沟通和互动是正确的、健康而有效的，那么就能够使这一群人的力量完全结合，从而产生相加、相乘的效果，迅速推进团队工作。
最迅速、最方便、最直接、最尊重人性的团队沟通方式，就是利用电子邮件系统。电子邮件系统为内部员工和上下级的交流提供了最大的方便，确保了相互间意见的及时交流，对消除相互间的隔阂十分有利，能够最大限度的统一整个团队的步调，共同前进。
如果一个团队陷入沟通不良的困境时，应该采取不同以往的沟通方式进行改善。比如沟通效率过低，就应考虑设立针对沟通的部门；如沟通欠缺建设性，就应该反省团队内部教育是否滞后不前。
一个成功的团队必须是充分沟通的团队。在上下级之间，如果只有命令，没有交流，必然导致领导者的独裁和团队成员积极性的丧失；在同事之间，如果彼此鼓励隔阂，也只能导致人际关系的僵硬和冷漠。
糟糕的团队沟通就象宇宙的“黑洞”一样，会将团队成员的能量和热情吞噬殆尽。与之相反，顺畅的团队沟通则有如温暖人心的艳阳，为团队成员提供源源不断的能量，帮助他们高效地完成工作。
4、敢于放权，善于授权
充分授权不仅是让团队成员能够全力发挥才能，无所阻碍地工作，也是为他们清除各种不同的障碍，让他们以自己的力量达到某种成就的好方法。自主是充分授权的基石，让他们自主判断和实施计划，自由地思考和表达他们认为应该思考和表达的事情，自由地去冒险尝试，使他们不必怕受到额外的惩罚。
充分授权是充分管理的结果，而不是忽视属下，让他们放任自流。当管理者对属下说“这是你的决定”时，他必须已经提供了完善的支持——训练、信息、资源——让属下能够作出正确的决定，这样才算充分授权。否则的话，让属下做决定等于弃他于不顾。
在充分授权的环境中，不是无政府的混乱，而是用事实和才能领导一切，因而会放弃因为骄傲所造成的愚蠢，去除自我的狭隘心理，给整个团队创造一种和谐统一的合作气氛。
精于授权，敢于担风险是管理者不能忘怀的素质。作为一个好的管理者，要学会放权，不能把权力一人独揽，要充分发挥下属的积极性，不然就会出现只有管理者忙忙碌碌，其他人却无所事事的局面，要学会大权独揽，小权分散，要学会抓大事，放小事，从而调动整个管理机构有机高效地运转。
学会适当放权的最后一部是分清楚什么是可以控制的，什么是不可以控制的，聪明的领导者会发现，想控制下属如何运作项目，如何决定以及他们提什么样的建议是不可能的，因而领导者需要放弃对下属行为的控制，转而让他们以任务为核心，专心致力于自己承担的任务。这样才能更加恰当地把个人的力量转化为整个团队的力量。
5、同等对待，就是抹杀杰出者的贡献
我们最不可忽视的是团队高效率的培养、团队精神的形成，其基础是尊重个人的兴趣和成就，设置不同的岗位，选拔不同的人才，给予不同的待遇、培养和肯定，让每一个成员都拥有特长，都表现特长，并且这样的氛围越浓厚越好。
世界因不同而丰富多彩，人类因差异而个性纷呈，区别对待表明了团队对个性的尊重。一个团队的组成并非是一些完全相同的个体，而是各有不同的个体组合在一起才能为团队带来各种不同的能力。也就是说团队需要的不是每个成员的共同点，恰恰相反，每个成员的不同点的集中才会使团队力量壮大。
经典的团队，是每个成员都经过选拔组合，特别配备的，每个成员都做着与其他人不同的事情，最重要的是团队的管理者区别对待每一个成员，通过精心设计的相应的培训，使每一位成员的个性，特长能够不断的得到发展并发挥出来，这才识名副其实的团队。
所谓的公平对待恰恰是极其不公平的，是对优秀人才的忽视，甚至会迫使优秀人才慢慢走向流失，趋于平庸化，因为他们没有得到应有的肯定而变得不再努力和突出。
6、制定规则的人，就是第一个执行的人
在一个团队中，各级管理者都起着至关重要的作用，所以，在任何一个团队中，每一级的负责人在提出工作要求、颁布管理规则的时候，要求每一个下属做到的，管理者自己必须首先要做到，每一个下属能做到的，管理者必须要做得更好。
管理者以身作则的力量和作用，无论在任何时候都是不能丢弃的，一个人没有规则意识会被认为素质低，一个管理者没有规则意识也绝不是一个优秀的管理者。
管理者决不能忽略自身对下属可能产生的影响，更需要知道自己会对下属产生深刻的影响，自己的乐观和悲观情绪会同样富有感染力，而且自己一举一动、一言一行的表现都会影响到周围所有人的情绪、语言和行为。管理者发出的信号是非常重要的。所以说，管理者的每一个决定和每一个行动都是对下属的一次绝好的培训机会.
发号施令并不能帮助管理者实现自己的意图。真正的领导是通过以身作则来实现的，而不是简单的行政命令。无论管理者喜欢与否，他的做法都会成为组织其他成员的榜样。管理者对他们有着巨大的影响，他们事事都会从他的身上寻找原型。
规则就是规则，确定下来的规则就要坚决执行。我们不缺乏规则，缺乏的是不折不扣的贯彻规则的决心和行动。
管理者应该树立起“规则意识”。否则，规则就难以维持下去，只有真正做到这一点，并且把这些意识贯彻到团队的每一位成员的每一天的工作中去，才能够建设出一个成功的团队。
7、授人以鱼与授人以渔
一个团队的管理者，要做的不仅仅是帮助团队成员完成工作，更重要的是要教会团队成员如何独立完成工作。
有时结果并不能反映出成功与失败，团队的成员们更注重的是一个过程，注重他们在这个过程中学会了什么，得到了什么、做出了什么。只有在工作过程中达到完美的配合和协作才是团队工作的真正意义所在。
团队领导肩负着让队员得到学习和成长的重任。“授人以鱼”只是解决了他一时的低层次的需求，却不可能帮助他从根本上摆脱被动，他难免要等待外界的馈赠或者施舍；“授人以渔”则使成员有了求知的能力，这样才能在今后的工作中掌握主动权，作为一个平等、独立的团队成员立足于团队之中。
帮助手下完成任务，不如教会手下如何去完成任务。
团队合作需要学习，而学习更需要团队合作，如果一个团队中，为了发展而形成一种激烈竞争的局面，不但不会促进团队成员的大力学习，还会阻碍学习的进程，使成员之间互相明争暗斗而各自为政。这样就难以发展成一个学习型组织，要成为学习型组织，先决条件是必须有和谐的内部气愤，组织内的成员才能共享知识。
8、利用内部竞争、激发团队活力
一个团队中不能缺少团结，但是更不能缺少竞争意识。没有竞争的团队就象没有波澜的死水一样，会丧失活力的，既然我们是一个团队的成员，那么就要把团队的意识放在竞争的意识之前，处处从大局考虑就可以了.
利用不同的群体，开展集体间的竞争，要在竞争中培养企业员工的团队精神，首先要巩固他们心中的集体观念。比如说尽量让员工参与集体管理，而在这一过程中，应注意分工明确、互相监督，力求让集体中的所有员工都找到自己在集体中的位置。
在处理和平衡合作与竞争的关系时，一定要强调合作高于竞争。从总体上说，团队通向成功的途径是内部合作，而不是内部竞争。在团队内，胜利必须建立在“我们一起干”的意识的基础上，而不是“我超过了同伙”的意识基础上。
不想被狼吃掉，就要学会与狼共舞，要与狼共舞，先要学会变成狼。
9、细节，体现凝聚力
团队的凝聚力，表现为团队成员对团队强烈的归属感和一体性——每个团队成员都强烈感受到自己是团队中的一分子，真正把个人工作和团队目标联系在一起，对团队表现出一种忠诚，对团队的业绩表现出一种荣誉感，对团队的成功表现出一种骄傲，对团队的困境表现出一种忧虑。
一个成功的团队管理者，必须使团队的每一个成员都能强烈的感受到自己是雄伟城墙中的一块砖，是不可缺少的一分子。而砖与砖之间的紧密结合则是建立城墙的基础，这种紧密结合就是团队的强大凝聚力。
团队凝聚力，是指团队对其成员的吸引力和成员之间的相互吸引力。它包括“向心力”和“内部团结”两层涵义。
10、旁观、还是投入？
作为旁观者，当局者的迷茫和困惑你可能会看得一清二楚，但当你主动伸出援手时，反而可能会得到一张冷脸，当局者有当局者的骄傲和自负，这种实话实说需要高度的技巧与智能，但却是建立团队精神的基础之一。
给予忠告的最佳媒介是情感，单纯的沟通效果可能只会昙花一现，你必须真的以彼此的情谊为赌注，甚至冒着失去工作的危险来讲出实话，如果不是这样，你可能很难突破对方的心理防线，让他打心底里接受你的建议。所以，请付出你那用之不竭的关怀和好意，让你讲述的事实被正面地接受。
总之，学会接受事实和学会传达真实的信息，虽然是两个方向的沟通，但却是团队合作精神的一体两面。
11、单纯，而不是世故，简单而无须复杂
一个团队是由众多的不同动机、需求与特性的人组成的，如果无法建立起一个简单而透明的规范，就会产生很多矛盾，形成大量的内耗，即使花很大的力气，也产生不了相应的成果。
要建立一个团结向上的团队，要想成为一个团结向上的团队中最具发展性的力量，我们必须养成一种“简单”和公开的工作方式。
12、信任，但不放任
一般来说，每个团队里都会有明星员工，就象一个团队的领袖一样，其他人对这个人的某方面的能力一般都特别津津乐道。而作为一名团队管理者，应该善于利用明星员工的这种效应，使他成为最支持这个团队的人，从而借助他的行为去影响其他人。
一个成熟的团队之中，绝不应该任由明星员工主导一切。如果出现了这样的管理方式。那么一定会损害团队自身。如果明星员工特别自傲，表现得难以合作，而沟通也不能解决问题，最好的办法也许是请他走人。
明星员工的存在价值，在于为团队其他成员起到表率作用，引领整个团队共同进步，而不是个人的昙花一现的荣耀。应让他学会主动的追求完美的团队表现。
放眼世界，没有一个企业是由于一个人或者是明星员工的成功而具有持久生命力的，团队的共同表现对公司的稳定、繁荣、业绩卓著才是至关重要的。
个人形象的张力是有限的，真正力挽狂澜的还是整个团队的合作实力。所以，必须正视明星员工在团队中的双面作用，真正化不利为有利，促有利为更有利。
13、提升团队士气
若想有效而持久地提升团队士气，就必须双管齐下，一面要进行激励，以图营造团队奋进的氛围；一面着手进行团队的基础建设，力求从最根本之处提高团队的业绩。
14、员工发展规划，把人才推荐到合适的位置
团队管理者的工作，是导引团队成员将个人的志向融入团队目标，辅导他们懂得配合自己的能力定出合宜的计划，从而为整个团队带来切实的利益。
企业对员工职业计划的管理过程成为职业管理，它应该为员工设计职业发展和职业援助计划，通过员工在职业目标上的努力，谋求企业的持续发展。它帮助员工完成自我定位，帮助员工克服在完成职业目标过程中遇到的挫折，鼓励员工将个人职业目标同团队目标统一起来。
因此，管理者对团队的重要职责之一就是，把人才推举到适合的位置上去，而惟有此，企业才能形成真正的团队凝聚力，才能真正留住人才，共创大业。
有效的职业管理应该处理以下问题：
员工在达成自己的职业目标时会遇到那些问题？
怎样解决这些问题？
员工的职业生涯是否可以分为若干阶段？
这些阶段的主要矛盾是什么？
团队领导者只有掌握了这些问题，才能制定相应的政策与措施，帮助员工实现职业生涯设计，为员工提供畅通的职业发展道路。
2007年5月15日星期二
部门间合作
工作三年来，我发现在部门间配合的问题上，一直没有完美配合的案例。在金山接受新员工培训时,我还记得PL的培训MM的告诫:完美的配合是不存在的;等待完美的配合，不如现在就开始做.
在KingSoft时，KIM事业部和游戏事业部有个合作计划，即使用KIM的IM技术，替换游戏里的内部聊天系统，但这个计划从一开始就流产；原因是游戏是个公司挣钱的产品，接入一个新的IM系统，可能会带来未知的问题。
在RoxBeam时，开发部和质量控制部(QA)从一开始就在争吵，有些很小的事情，可能互相一两句话沟通就能解决的问题，最后却能成为两个部门间群发邮件的争论。
在现在的公司，两大核心开发组之间的隔阂，让我十分焦虑。P2P产品虽然现在没有成为公司的一个拳头产品，但抬起头看以后，如果有直播点播的技术，加上公司强劲的市场运作能力，将来可以成为业内翘楚。Joost的高调发布和风险投资的追捧，让我们已经看到了互联网视频广告和数字发行的风雨欲来。
纵观这三次经历，有以下几个共同特点：
1. 风险控制问题。KS的游戏部门肯定不愿意接入一个还没有经过大规模运营的IM系统，来替换目前的内部聊天系统。即使接入一个新的聊天系统，也不能给游戏带来真正的增值。
2. 责任归属问题。RB公司的Dev和QA的争论，更像是学术的争论，一个具体的研发流程，应该谁来负责，谁又权力决策的问题。 另外也有开发究竟是Dev强势还是应该QA强势的问题。
解决部门合作问题，我想可以如下几个步骤：
1. 共同认同公司的目标
KS游戏部门应当意识到，更换一个聊天系统虽然对游戏作用不大，但是却扶持了公司的一个巨大有潜力的产品：即时通讯。
对公司目标的认同，可以解决不愿意接入可能有风险的项目的问题。共同控制、承担公司未来发展需要的技术和产品暂时的风险。
2. 互相理解
RB公司的Dev和QA的争论，我想还是属于一个技术争论的范畴，一个具体的流程应当谁负责，一个具体的Bug究竟需要不需要Fix。如果这时Dev站到QA角度，QA反站到Dev角度，这个问题的答案就已经非常清晰了。
互相的理解，可以分解责任的归属，能做到自责，这样可以互相帮助着解决对方的问题。也可以彼此互相感谢。
不得不承认，这个想法非常的理想化，写这篇blog时，我也对自己的想法做了很多保留。但是对我来说，部门间配合的问题，我必须在我的工作里解决。
在KingSoft时，KIM事业部和游戏事业部有个合作计划，即使用KIM的IM技术，替换游戏里的内部聊天系统，但这个计划从一开始就流产；原因是游戏是个公司挣钱的产品，接入一个新的IM系统，可能会带来未知的问题。
在RoxBeam时，开发部和质量控制部(QA)从一开始就在争吵，有些很小的事情，可能互相一两句话沟通就能解决的问题，最后却能成为两个部门间群发邮件的争论。
在现在的公司，两大核心开发组之间的隔阂，让我十分焦虑。P2P产品虽然现在没有成为公司的一个拳头产品，但抬起头看以后，如果有直播点播的技术，加上公司强劲的市场运作能力，将来可以成为业内翘楚。Joost的高调发布和风险投资的追捧，让我们已经看到了互联网视频广告和数字发行的风雨欲来。
纵观这三次经历，有以下几个共同特点：
1. 风险控制问题。KS的游戏部门肯定不愿意接入一个还没有经过大规模运营的IM系统，来替换目前的内部聊天系统。即使接入一个新的聊天系统，也不能给游戏带来真正的增值。
2. 责任归属问题。RB公司的Dev和QA的争论，更像是学术的争论，一个具体的研发流程，应该谁来负责，谁又权力决策的问题。 另外也有开发究竟是Dev强势还是应该QA强势的问题。
解决部门合作问题，我想可以如下几个步骤：
1. 共同认同公司的目标
KS游戏部门应当意识到，更换一个聊天系统虽然对游戏作用不大，但是却扶持了公司的一个巨大有潜力的产品：即时通讯。
对公司目标的认同，可以解决不愿意接入可能有风险的项目的问题。共同控制、承担公司未来发展需要的技术和产品暂时的风险。
2. 互相理解
RB公司的Dev和QA的争论，我想还是属于一个技术争论的范畴，一个具体的流程应当谁负责，一个具体的Bug究竟需要不需要Fix。如果这时Dev站到QA角度，QA反站到Dev角度，这个问题的答案就已经非常清晰了。
互相的理解，可以分解责任的归属，能做到自责，这样可以互相帮助着解决对方的问题。也可以彼此互相感谢。
不得不承认，这个想法非常的理想化，写这篇blog时，我也对自己的想法做了很多保留。但是对我来说，部门间配合的问题，我必须在我的工作里解决。
战略与战术
记得大四时，一天中午比较热，和一起做项目的兄弟跑到玉渊潭公园去消遣；随身带了张《南方周末》（还是新京报？），里面有一篇文章是些战术和战略的。基本的含义就是战略要明确，战术可以失败，但是不意味着整个战略就失败了；战略关注的是整个竞争的结果，战术是实现战略的手段。
从那时起，我一直头脑里有着一个战略和战术的概念，虽然不那么懂哲学，但是这对个人的工作和发展还是很有意义的。从光芒离开时，虽然公司还在盈利，但是长远的战略已经失败了，这样继续发展下去，也就没有什么机会了。
最近有了一个新的想法:人的职业规划，也是一个战略。
职业之路曲曲折折，磨练的是我们的能力和素质，一次不成功的经历可以让我们自己更加成熟，一次不成功的经历可以让我们自己变得更加坚强，让我们的职业生涯更加充满希望。人的成败最终归于性格和习惯，失败的经历会给我们强烈的信号，需要对自己的习惯进行规避或培养。
抱怨是没有用的，对职业生涯真正有帮助的，就是立刻去解决目前的问题。如果面对问题而碍于其它人情面子因素，导致问题不能被提出和解决，那么对最终的结果是要承担责任的。从这点来说，我在光芒工作时，没有做到（只在最后VP的挽留时，提了出来，其实这时提出问题，自己已经没有去解决问题的初衷了），因此我也是有责任的。
工作就是为了完成一个任务和下一个任务，为了完成任务而解决一个问题和下一个问题。一次任务是我们职业生涯中的一次战术，有成有败；而这一次一次的战术，最终成就我们的职业生涯战略。
从那时起，我一直头脑里有着一个战略和战术的概念，虽然不那么懂哲学，但是这对个人的工作和发展还是很有意义的。从光芒离开时，虽然公司还在盈利，但是长远的战略已经失败了，这样继续发展下去，也就没有什么机会了。
最近有了一个新的想法:人的职业规划，也是一个战略。
职业之路曲曲折折，磨练的是我们的能力和素质，一次不成功的经历可以让我们自己更加成熟，一次不成功的经历可以让我们自己变得更加坚强，让我们的职业生涯更加充满希望。人的成败最终归于性格和习惯，失败的经历会给我们强烈的信号，需要对自己的习惯进行规避或培养。
抱怨是没有用的，对职业生涯真正有帮助的，就是立刻去解决目前的问题。如果面对问题而碍于其它人情面子因素，导致问题不能被提出和解决，那么对最终的结果是要承担责任的。从这点来说，我在光芒工作时，没有做到（只在最后VP的挽留时，提了出来，其实这时提出问题，自己已经没有去解决问题的初衷了），因此我也是有责任的。
工作就是为了完成一个任务和下一个任务，为了完成任务而解决一个问题和下一个问题。一次任务是我们职业生涯中的一次战术，有成有败；而这一次一次的战术，最终成就我们的职业生涯战略。
2007年5月14日星期一
步子太快了，也许走的就飘
工作5年了，当了1年半的老师（期间和朋友一起创业过，公司维持了一年后转手；然后和师弟作了个软件工作室，半年后因为自己加入金山而停止），在金山工作了1年半，在facio工作了三个月，在Roxbeam工作了1年，现在在目前这个公司里。
当年离开金山，是因为看到自己做的产品没有机会再做下去了，即使做下去，自己发挥的空间也很有限了；
离开Facio的原因，是facio用不上我，招聘过去时，是准备开发即时通讯的，但是过去后不到一个月，即时通讯的项目就因为联通的原因取消了；后来做了个Brew上的Push Mail,和CEO谈了下，认为这样发挥不了自己的优势，而自己又在自己人生的黄金发展时期，不愿等待机会，就离开了。
离开先拿到的CA的offer，但是自己认为自己属于比较能够向前冲的人，在大公司可能不能发挥我的优势；所以就来到了roxbeam,一个刚刚创立2个月的新公司。在Roxbeam我尽了我的全力工作，但是公司的弊病一年后显现了出来，过于软弱的中层使得项目难以顺利进行；复杂的人际关系使我也难以发挥自己的优势；正好这时我以前金山的市场总监出来创业，聊过几次后，感觉他是个能创业成功的人，对人、对事都非常的完美；由于当时我正在做Roxbeam的核心项目的第二版本，心里想怎么也要把这个项目作完，不然对不起研发的VP。正好这个项目作完后，在项目公测上，又遇到了难以理解的管理问题，我很无奈的提出了离职，离开这个自己寄托了很大希望的公司，加入了今天的公司。
在roxbeam,我参与了最早的核心版本的产品化和bug fix,用Python/C++两次重新写内核，使用新的算法重写了一次内核，如果不是对这个公司寄托了很大的希望，我现在也很难想象，我能在一年的时间里做完这些事情。当然，这里也有我的问题，我写代码太快，在大部分人难以想象的时间里，我就把大部分功能都实现，我本来也认为我就是在开发产品的第一个版本，本来就没打算是非常稳定的，但显然我的leader没有这么认为，在我还没有去稳定系统的时侯，诘责我的代码不稳定，这对一个全心投入工作的人来说，是很大的伤害。这也让我在后来自己带team的时候，对自己的team member非常的有耐心，有问题的时候基本不去诘责，而是立刻商量解决办法和需要不需要更多的engeering resource和QA resource,因为我相信他们认真工作了，。
在现在这个公司，我有机会和CEO交流，从他身上学到很多的思考方法和做事、为人的态度。这些让我受益菲浅，我开始真正用头脑分析每件事情的可行性。但是我毕竟只有27岁，不深的从业经历和浅薄的社会阅历，难以支撑我很好的做出判断。
工作以来，我基本一直是以一种跳跃的方式在发展，我知道我为此付出了别人几倍的努力，但是毕竟这不是一个事物发展的客观规律，在我的跳跃中，我少了很多经历，这对我可能是危险的。我想我现在应该静下心来好好想想，为了支撑我的工作和以后的发展，我必须补上什么？
当年离开金山，是因为看到自己做的产品没有机会再做下去了，即使做下去，自己发挥的空间也很有限了；
离开Facio的原因，是facio用不上我，招聘过去时，是准备开发即时通讯的，但是过去后不到一个月，即时通讯的项目就因为联通的原因取消了；后来做了个Brew上的Push Mail,和CEO谈了下，认为这样发挥不了自己的优势，而自己又在自己人生的黄金发展时期，不愿等待机会，就离开了。
离开先拿到的CA的offer，但是自己认为自己属于比较能够向前冲的人，在大公司可能不能发挥我的优势；所以就来到了roxbeam,一个刚刚创立2个月的新公司。在Roxbeam我尽了我的全力工作，但是公司的弊病一年后显现了出来，过于软弱的中层使得项目难以顺利进行；复杂的人际关系使我也难以发挥自己的优势；正好这时我以前金山的市场总监出来创业，聊过几次后，感觉他是个能创业成功的人，对人、对事都非常的完美；由于当时我正在做Roxbeam的核心项目的第二版本，心里想怎么也要把这个项目作完，不然对不起研发的VP。正好这个项目作完后，在项目公测上，又遇到了难以理解的管理问题，我很无奈的提出了离职，离开这个自己寄托了很大希望的公司，加入了今天的公司。
在roxbeam,我参与了最早的核心版本的产品化和bug fix,用Python/C++两次重新写内核，使用新的算法重写了一次内核，如果不是对这个公司寄托了很大的希望，我现在也很难想象，我能在一年的时间里做完这些事情。当然，这里也有我的问题，我写代码太快，在大部分人难以想象的时间里，我就把大部分功能都实现，我本来也认为我就是在开发产品的第一个版本，本来就没打算是非常稳定的，但显然我的leader没有这么认为，在我还没有去稳定系统的时侯，诘责我的代码不稳定，这对一个全心投入工作的人来说，是很大的伤害。这也让我在后来自己带team的时候，对自己的team member非常的有耐心，有问题的时候基本不去诘责，而是立刻商量解决办法和需要不需要更多的engeering resource和QA resource,因为我相信他们认真工作了，。
在现在这个公司，我有机会和CEO交流，从他身上学到很多的思考方法和做事、为人的态度。这些让我受益菲浅，我开始真正用头脑分析每件事情的可行性。但是我毕竟只有27岁，不深的从业经历和浅薄的社会阅历，难以支撑我很好的做出判断。
工作以来，我基本一直是以一种跳跃的方式在发展，我知道我为此付出了别人几倍的努力，但是毕竟这不是一个事物发展的客观规律，在我的跳跃中，我少了很多经历，这对我可能是危险的。我想我现在应该静下心来好好想想，为了支撑我的工作和以后的发展，我必须补上什么？
简单的错误 --> 巨大的损失
2000年2月1日，阿拉斯加航空公司的261次航班，搭载84名乘客和5名机组人员，永远的消失在了茫茫的大海上。89个生灵，没有再能回到他们的家。
空难调查的结果，非常让人沮丧。如此巨大的事故的起因，尽然是尾部稳定器的螺钉和螺母上，没有润滑油所致。John Liotine是一个机械维修师，他曾经检举阿拉斯加航空公司违反飞机维修和保养的规定。但是FAA和交通部的调查持续3年后，没有起诉任何人，只是罚款了事。
然而John为了他自己的仗义直言付出了代价，他被公司辞退了。
事故发生后，John检查了自己的工作记录，早在1998年，他就建议过更换失事飞机的尾部稳定器装置，但是他的建议没有被接纳。
89个生命，多少个幸福的家庭，在一个事故中丧失。留下来的，是责任人和非责任人的巨大的良心谴责。如果航空公司没有唯利是图，如果John Liotine能够继续强硬表达自己的观点，如果监管部门能够更认真地对待John Liotine的投诉，89个生命，本来是可以和我们继续留在一起的。
这个本可以避免的事故留给我们很多遗憾，希望每个人都能够认真地对待自己的工作，对自己的工作负责；人可能因为自己的错误，而承担一辈子的良心谴责，不是所有的错误都可以弥补的。
空难调查的结果，非常让人沮丧。如此巨大的事故的起因，尽然是尾部稳定器的螺钉和螺母上，没有润滑油所致。John Liotine是一个机械维修师，他曾经检举阿拉斯加航空公司违反飞机维修和保养的规定。但是FAA和交通部的调查持续3年后，没有起诉任何人，只是罚款了事。
然而John为了他自己的仗义直言付出了代价，他被公司辞退了。
事故发生后，John检查了自己的工作记录，早在1998年，他就建议过更换失事飞机的尾部稳定器装置，但是他的建议没有被接纳。
89个生命，多少个幸福的家庭，在一个事故中丧失。留下来的，是责任人和非责任人的巨大的良心谴责。如果航空公司没有唯利是图，如果John Liotine能够继续强硬表达自己的观点，如果监管部门能够更认真地对待John Liotine的投诉，89个生命，本来是可以和我们继续留在一起的。
这个本可以避免的事故留给我们很多遗憾，希望每个人都能够认真地对待自己的工作，对自己的工作负责；人可能因为自己的错误，而承担一辈子的良心谴责，不是所有的错误都可以弥补的。
2007年5月9日星期三
Console程序如何不显示界面
用UltraEdit打开你要调用的Console程序，在位置 0x130~0x13f 之间找个数值03，将它变为02，保存，然后正常调用即可。
呵呵，从google上找来的最简单的方法:)
呵呵，从google上找来的最简单的方法:)
C++模板元编程 - 把程序运行时间转移给编译器
还闲自己的程序不够快? 来看看模板元计算吧.
模板元计算实际上是利用编译器在编译时,需要把模板展开的特性，进行计算的。
例子: 计算X的Y次方
template
class X_exp_Y
{
public:
enum { result_ = X * X_exp_Y(Base, Exp-1)::result_; };
};
结束条件: (当模板展开到这个层次时,结束)
template
class X_exp_Y
{
public:
enum { result = 1; };
};
再看主程序:
int main()
{
int result = X_exp_Y<10, 5>::result_;
std::cout << "10 exp 5 is: " << result << std::endl;
return 0;
}
这样,在编译期间,就会对X_exp_Y<10, 5>进行展开，过程中会对result_进行计算. 这样实际运行时,呵呵，得到的结果相当于对result进行赋值操作.
这样就实现了把一部分计算工作转交给编译器. 模板元计算特别适合于递归操作. 但是编译器有展开层次的限制,C++标准建议最小为17层.
g++可以指定展开层次: -ftemplate-depth-1000, 把展开层次增加到1000层.
模板元计算实际上是利用编译器在编译时,需要把模板展开的特性，进行计算的。
例子: 计算X的Y次方
template
class X_exp_Y
{
public:
enum { result_ = X * X_exp_Y(Base, Exp-1)::result_; };
};
结束条件: (当模板展开到这个层次时,结束)
template
class X_exp_Y
{
public:
enum { result = 1; };
};
再看主程序:
int main()
{
int result = X_exp_Y<10, 5>::result_;
std::cout << "10 exp 5 is: " << result << std::endl;
return 0;
}
这样,在编译期间,就会对X_exp_Y<10, 5>进行展开，过程中会对result_进行计算. 这样实际运行时,呵呵，得到的结果相当于对result进行赋值操作.
这样就实现了把一部分计算工作转交给编译器. 模板元计算特别适合于递归操作. 但是编译器有展开层次的限制,C++标准建议最小为17层.
g++可以指定展开层次: -ftemplate-depth-1000, 把展开层次增加到1000层.
[转]C++热点问题一席谈 （下）
C++热点问题一席谈 （下）
— Bjarne Stroustrup 2005新春专访
荣耀/刘未鹏 译
荣耀: 根据您掌握的资料，模板和泛型编程在业界被广泛采用了吗？还是主要局限于库作者？您认为对于普通程序员（而非库作者）来说，面向对象和泛型编程哪一个更重要？为什么？您认为今后模板和泛型编程应该比今天得到更普遍的应用吗？
Bjarne: “加法和乘法哪个更重要？”大多数情况下这是个愚蠢的问题。同理类推，“面向对象编程和泛型编程哪个更重要？”的问题也毫无意义。关键在于，它们都是基础性的东西，并且是互补的。对于许多问题而言，最佳解决方案往往要求将它们结合运用。
从理论的角度来说，你是在“ad-hoc 多态”和“参数化多态”之间做出选择。而从实现角度来说，则是在“运行期多态”和“编译期多态”之间进行选择。你必须对两者都有所了解，并且恰当地使用它们。和“ad-hoc多态”（在C++中以类继承来表达）相比，“参数化多态”（在C++中以模板来表达）更具规则性，更利于逻辑或抽象思考。这就是为什么它被称为“ad-hoc”、为什么模板代码通常具有更好的性能、以及为什么当个体表达式和语句的性能很重要时我们应该考虑泛型编程的原因之所在。相反，类继承则能够在分离式编译和维护的代码块之间提供更为明晰的接口。
（译注：“ad-hoc”是“专门”的意思。事实上，多态一般分为“ad-hoc多态”和“universal多态”，前者一般指重载，后者一般指“参数化多态”（模板）或“包含多态”（类继承）。你可以从以下链接找到详细的解释：http://www.javaworld.com/javaworld/jw-04-2001/jw-0413-polymorph.html。）
我不能说哪个将会变得更重要，或者哪个应该更重要。那就好像是在加法和乘法之间偏袒某一方一样。但是我怀疑，和没有充分使用类继承和面向对象编程的人相比，有更多的人没有充分使用模板和泛型编程。因此，我更多的时候鼓励人们考虑并使用泛型编程而不是面向对象编程。我确信我们将会看到越来越多的泛型编程应用。泛型编程目前仍然没有被足够的理解和充分的使用。我们接受了近十年的面向对象的耳濡目染，所以我的感觉是面向对象常常被滥用了。值得注意的是，无论如何，泛型编程和面向对象编程这两种技术/风格都比使用一团乱麻似的选择语句、单薄的数据结构以及指针来解决问题要强得多。我们的目标应该是在代码中更为直接和优雅地表达思想，模板和类继承只是为了达到这个目的的工具。
我的感觉是许多“普通的程序员”确实使用了模板，而不仅仅是一些“库设计”方面的精英。当然，我们自己写的模板代码可能要比基础库里的代码简单一些，这很自然，因为对于其它编程技术来说，也存在同样的现象。
荣耀: 我想知道您对模板元编程的看法，您甚至选编了一本模板元编程的书。
Bjarne: 我想我并不愿意把泛型编程和模板元编程区别开来，它们的区别仅仅是在层次和侧重点上。我通常倾向于把这一块统称为泛型编程。事实上我认为模板元编程是一个非常重要的领域，而目前的C++对它的支持却不佳，以至于在生成的代码中它并不能发挥应有的潜力。我认为人们在这一领域所作的许多努力是实验性的，其中许多理应获得成功，因为比起替代方案来，它们能使代码更清晰地表达基础概念，并且具有更好的性能以及可维护性。然而C++98对这些技术的支持却不是很好，所以它们目前还不能成为主流。鉴于此，我在语言的改革方面所作的许多工作都跟泛型编程直接或间接有关。concept（用于分离式检查模板的使用和定义，以及用于更好地重载模板等），更好的初始化，以及更少的不规则性，都是对此有所帮助的努力，同样，用于支持标准库的设施（例如type traits）也会带来帮助。
荣耀: 我个人认为标准C++流库是面向对象和泛型编程结合运用的典范，您赞成这一点吗？对于准备尝试混合使用面向对象和泛型编程技术的程序员，您有什么建议或忠告？
Bjarne: 不，我认为流输入输出流是一个不错的早期尝试。然而，它仅仅是一个非常初步的尝试而已，随着时间的推移而显得过于精致而复杂（正如发生在大多数成功的系统中的那样）。我们现在可以做得更好。在我设计第一个流库时我意识到泛型编程的必要性，但是当时我并没有料到泛型编程最终会变成C++中如此重要的一个组成部分。
荣耀: 我必须得承认我也许太闭目塞听了，我真的没有看到过比标准C++输入输出流更好的面向对象编程和泛型编程的结合应用范例。您能给我一些线索吗？更重要的是，您能告诉我们有哪些是结合运用面向对象编程和泛型编程的最佳场合？谢谢！
Bjarne: 如果你面对的问题既需要某些运行期决议（需要面向对象编程），又具有一些能够从编译期决议中获益的方面（泛型编程的用武之地）的话，那么你就需要将面向对象编程和泛型编程结合起来。例如，面向对象编程的经典例子 — 将一个保存了shape的容器中的所有元素都显示出来就属于这类问题。几十年前我第一次在Simula中看到过这个例子，后来直到遇到了泛型编程，我才看到它的改进实现。考虑以下代码：
void draw_all(vector〈Shape*〉& vs)
{
for (int i=0; i〈vs.size(); ++i) vs[i]-〉draw();
}
我猜想这并不能被看作纯粹的面向对象编程，因为我直接利用了“vs是一个装有Shape*元素的vector”这个事实。毕竟，类型的参数化通常是被认为属于泛型编程的范畴。我们也可以消除这种对静态类型信息的使用（所谓“不纯粹的面向对象编程”）：
void draw_all(Object* container)
{
Vector* v = dynamic_cast〈Vector*〉(container);
for (int i=0; i〈v.size(); ++i)
{
Shape* ps = dynamic_cast〈Shape*〉(v[i]);
ps-〉draw();
}
}
但凡鼓励以上这种风格的语言，其语法通常都比较漂亮，然而这个例子却说明了当你把静态类型信息的使用减至最小的时候发生了什么。如今，在C++或其它语言中，仍然有人在使用这种风格。我只是希望他们在错误处理方面有系统化的准备。
在前一个例子中，vector〈Shap*〉依赖于对泛型编程的一个最简单的运用：vector的元素类型被参数化了，而且我们的示例代码正获益于此。在这个方向上我们还可以走得更远，即推而广之到所有标准库容器身上：
template〈class Container〉 void draw_all(Container& cs)
{
for (typename C::iterator p=cs.begin(); p!=cs.end(); ++p)
(*p)-〉draw();
}
例如，这段代码就既可以作用于vector上，又可以作用于list上。编译期决议确保我们不用为这种泛化处理付出任何运行期额外代价。我们还可以通过在draw_all()的使用接口中运用迭代器，从而进行进一步的泛化处理：
template〈class Iter〉 void draw_all(Iter fist, Iter last)
{
for (; first!=last; ++first)
(*first)-〉draw();
}
这就使内建数组类型都得到了支持：
Shape* a[max];
// 向a中填充Shape*类型的元素
draw_all(a,a+max);
我们还可以结合运用标准库算法for_each()和函数适配器mem_fun()来消除显式的循环：
template〈class Iter〉 void draw_all(Iter fist, Iter last)
{
for_each(first, last, mem_fun(&Shape::draw);
}
在这些例子中，我们结合了面向对象（对虚函数draw()的调用以及对类继承体系的假设）和泛型编程（参数化的容器和算法）技术。我看不出如果这两种编程风格（即所谓的“范型”）各自独立运用如何达到同样好的效果。这也是一个简单的“多范型编程”的例子。
我认为在设计和编程技术方面，我们还需要做更多的工作，以便确定出“关于何时采用哪种范型以及如何结合运用它们”的更为具体的规则。为此，我们还需要一个比“多范型编程”更好的名字。
注意，这也是一个关于编译错误信息变得可怕的例子，因为我们并没有显式地表达出我们的假设。例如，我们假设容器里的元素类型为Shape*，然而在代码中，这个假设却相当隐晦。这种情况下我们可以使用约束类（此处为Point_to）：
template〈class Iter〉 void draw_all(Iter fist, Iter last)
{
Points_to〈Iter,Shape*〉();
for_each(first, last, mem_fun(&Shape::draw);
}
然而我们又确实很想说明“first和last必须为前向迭代器”：
template〈Forward_iterator〈Shape*〉 Iter〉
void draw_all(Iter fist, Iter last)
{
for_each(first, last, mem_fun(&Shape::draw);
}
这是“concepts”可以大展拳脚的地方之一。
荣耀: 请原谅我重复一个老俗套问题。由于Java和C#今天都已经大获成功，您对Java和C#曾经的看法今天有无改变？我个人认为，与其说Java和C#的成功是语言自身的成功，还不如说是SUN的Java战略和微软的.NET战略的成功。
Bjarne: 在对它们的本质技术优点以及对它们的市场能量的估计上面，我都是正确的。低估市场的影响是不明智的，尤其当它背后有价值上百万美元的“免费”库所支持的时候。Java和C#是不坏的语言，而且SUN及其盟友以及微软及其盟友为其（过分夸张）的宣称提供重大的库和工具的支持。不过，这么说并不意味着我比喜欢C++更喜欢它们，对于要求严苛的应用而言更是如此。
荣耀: 您自觉或自发地使用过GOF描述的设计模式了吗？您对设计模式怎么看？您对Loki库中采用模板技术描述的静态设计模式怎么看？
Bjarne: 我并不喜欢根据特定的具名模式去思考，但我知道并且通常会使用这些在《设计模式》中描述的技术。顺便一提，《设计模式》是一本经典书籍，人们在搜寻最近最好的信息时不应该忘了这本书。其中的许多模式对于好的设计来说非常重要 — 给它们起什么名字倒无所谓。甚至你在TC++PL中也能够找到一些有关它们的运用。要想了解在某个特定领域中对模式有意识且系统的运用，可以参考“深入C++系列”中Schmit和Hunston的两本关于ACE的书。
除了明显的强大能力之外，我认为模式有两大弱点：
它倾向于鼓励“精致的专用术语”，这会阻碍新手的学习。
如果没有具体的“工具”支持，要想把一个思想广泛地传播到应用中是极其困难的。
例如，一个优秀的库本身携带了很多优秀的思想，并允许程序员（和设计者）直接利用这些思想在库中的实现品来工作。而模式只是对某个思想（或一系列互相关联的思想）的尽量一般性的描述，并刻意避免将这些思想作为库实现出来而招致的特殊性。这就导致了这些思想在传播上的问题，以及从代码中如何识别出模式的问题 — 特别是在代码被维护修改过之后。同样，要想从抽象层面上来理解一个模式也是非常困难的。在某个模式的抽象描述之后的实例代码进入我的视野之前，我倾向于对自己的理解持保留态度。我见到过一些人，他们认为自己是在使用某个模式，而实际上做的却是该模式被设计用来避免的事情。这些都说明思想的传授可能会异常困难。
可以让模式更具有可利用性的方式之一是为某些特定的环境提供模式的库的实现。Andrei Alexandrescu的书和他的Loki库可以被看成一次寻求结合高灵活性和高效率（和手写代码一样高效）编程风格的尝试。而模板元编程在大多数情况下都符合这个描述，STL亦然。为了从这种非常一般性的参数化中获益，设计（或编码）抉择必须从运行期转移到编译期，从而程序才更容易在时间或速度上得到优化。遗憾的是，许多编译器都不能很好地把握模板技术所提供的明显的优化机会，这通常是由于编译器过早地扔掉了类型信息，并试图去优化每一片代码，就好像它们是用弱类型风格的C所编写的一样。
荣耀: 您用过UML吗？您对UML怎么看？您认为它对C++程序设计很有用吗？
Bjarne: 我尝试过UML，但并不是为了一些严肃的事情，所以我的看法参考价值不大。对于我最常考虑的设计问题来说，UML不是特别有意义。我发现在设计和记录设计时草图是不可或缺的，但我并不认为把过多的细节加到草图中是个好主意。相比之下，代码更易于表达精确的关系。当然了，这么说并不意味着UML没有用，我所尊敬的一些人认为UML在文档化大型系统时非常重要。
荣耀: 您目前还在写书吗？或者有C++新书写作计划吗？
Bjarne: 我目前正基于我正在讲授的一门新手课程撰写一本面向初学者的编程书。这对于那些具有很少甚至没有编程背景但很想通过努力成为程序员的人应该有所帮助。此前我从未试图为非程序员写书，因为我对完全没有编程经验的人们所知甚少。现在我正教授初学者，这就让我有机会去尝试我的想法，并基于我的教学经验对之不断修改。对于任何瞄准于初学者的东西来说，这样做都是必不可少的。
我的目标是先教给新手最小的一套原则、技术以及语言设施，让他们可以先开始第一个实在的项目。基本上，我打算让那些想要成为职业C++程序员的人由此起步。为了达到这个目的，我一开始的讲授要涵盖很多背景知识，包括数据结构、算法、图以及类设计等，这在传统的教学中是不会很早涉及的。这比我了解到的当前大多数的教学方式更加雄心勃勃。当然，我使用C++作为编程语言，并且我会在讲授中涵盖STL的基础知识。
荣耀: 您能透露一下您的新书何时出版吗？
Bjrane: 我还没有写完呢，而且我还没有跟出版商（Addison-Wesley）协商好进度计划。至少我还需要半年时间来和我的学生们一起精化和锤炼这本书。理论上，我们（Lawrence Petersen是我的合作作者）在明年秋天大概可以完成，如果我们在重审的过程中发现了重大问题的话，那就得等到圣诞节之后才能付梓了。我知道出版商会督促我们早点完成，而我们则会争取更多的时间来检验这本书并采纳反馈。对于这样的一本书，我们是不可以草率对待的。
荣耀: 您对您负责编辑的“深入C++系列”（Addison-Wesley）有何评论？您是否认为其中一些书已经过时了？一些书仅对有限的读者群有作用？您对新近出版的几本书有何评价？还有哪些新成员即将加入这套丛书？我特别想听一听您对《Modern C++ Design》和《C++ Template Metaprogramming》这两本书的看法。
Bjarne: 过时？一些早期的书的确有点过时，但是从总体上来说，这些书都很好地经受住了时间的考验。新的书籍会以稳定的速度加进来。我的猜想是每年会增加三本新书。当然，我希望有更多，但是要想找到质量和实用性足够好的“轻薄洗练”的书并非易事。事实上我很期望能够看到更多精专的书，比如着眼于数值计算的特定方面的书，以及嵌入式系统编程方面的书。人们应该注意的是，这些书中的许多都是以专家或至少有经验的程序员为目标读者的。并且，作为一个专家，应该知道何时使用何种技术。我认为泛型编程和模板元编程是将来的一部分，但那只能算是基础，而STL这样的东西才是当前的主流。你所读到的一些书，像Alexandrescu和Abrahams的那两本书，会为你带来新的概念和可供试验的思想，但是你并不会在正准备部署的系统中立即应用这每一项技术。
荣耀: 您对Boost似乎情有独钟。“深入C++系列”中已经包含了《Boost Graph Library》和《C++ Template Metaprogramming》两本书，我猜将来还会有更多有关Boost的书会加入到这个系列中来，您对Boost怎么看？选编这方面的图书出于什么考虑？
Bjarne: 事实上，我并非根据它们是否是关于Boost的来选择书籍，“深入C++系列”中的大部分书籍都不是关于Boost的。我根据它们是否提供了有关编程技术、原则和概念的有用信息做出选择。恰巧Boost的作者在尝试“根据标准库的精神”来扩展基础库时，使用了有趣的技术去解决有趣的问题而已。
荣耀: 在过去的一年里，只出了有限的几本C++书籍。除了“深入C++系列”中的三本新书外，Addison-Wesley还出版了一本《Imperfect C++》，您对这本书怎么看？（译注：因本书由我们翻译，故有此一问。）另外， 您认为C++0x标准会催生更多的C++新书出版吗？
Bjarne: 人们好像没有以前那样喜欢读书了。今年的C++新书只有寥寥几本，不过已出版的C++书籍已经有很多。“老”书并不一定过时。我认为我自己的书就是很好的例子。《C++程序设计语言》卖得比大多数新近出版的书要好，而《C++语言的设计与演化》则刚刚被翻译成日语。类似地，K&R（译注：《C程序设计语言》）在25年后的今天仍然是最畅销的书！请不要忘了经典。我觉得有一个现象蛮有趣的，我附近的技术书店的Java部分的书几年来第一次比C++部分小了。
我看过《Imperfect C++》的草稿。如果它的页数可以降到原来的一半的话，我非常愿意把它加入到“深入C++系列”中去。该书作者是一个C++热爱者，他希望向开发者展示如何对付C++中诸多不完美之处，以便写出更好的代码，而这些代码在声称为“理想”的语言中更难实现。
我期望C++0x会催生一批新一代的C++书籍。不过，我希望这些新书能够集中于语言对编程风格和设计技术更强固的支持上，而不是简单地列举语言特性。我们已经看到了一大堆令人厌烦的列举语言规则的书。如果孤立开来看，任何语言特性都是无趣的，真正有趣的主题是编程。
荣耀: 由于您正在给C++新手讲解编程课，您愿意给世界上其他C++教师谈些教学经验吗？
Bjarne: 多年来，我一直对普遍的编程教育尤其是C++教学质量感到不愉快。当然，有很多好老师，而且也确实有很多学生变成了很好的程序员，然而，严重误导性的教学和被严重搞迷惑的程序员似乎没有个尽头。大概一年半前，有人建议我为编程新手设计一个全新的编程课程。我有过犹豫，但最终还是答应了，我和我们最具经验的讲师Lawrence Petersen合作，他会弥补我在教授新手方面的经验的不足。我们设计了课程并已讲授了两学期，并且基于我们的讲授方式、客观效果以及反馈（反馈是不可或缺的），不断加以改进。
当然，我并非仅凭个人的主观看法和所知的实验性的途径就一意孤行。事实上，我阅读了大量的口碑好的C++编程入门教材，看看它们到底好在何处。大约有两个星期，我烦躁地走来走去，抱怨着“要是那些玩意就是C++的话连我自己都不会喜欢它！”。我的感觉是许多教材彻底讹传了C++，可怜的学生们！所以，我们首先基于“一个学生成为职业程序员所需要的”知识列出了一个课程大纲，写了讲稿，列出了练习并附以大量的告诫。我们快速的重审材料并根据哪些可行、哪些不可行多次对其进行了调整。是年秋天，我们再次重审了材料，并且将课程的文字印刷成书。这下好多了，但是我们根据学生的反馈再一次调整了许多细节。我们的确越做越好，学生们的反响（包括口头反映和考试成绩）说明了这一点。今春，我们将会再一次讲授这门课，到了夏末时大概就可以进行更大范围的普及推广了。
我们把这种讲授方式称为“深度优先”，因为在课程一开始，我们会给学生介绍许多材料但并不深入细节。我们从第二周开始简单地使用STL，到了第五周学生就知道错误处理策略和类设计。在那之后，我们拓宽他们的知识面，并且让他们把知识应用到一些领域去，譬如文本处理、文件操纵以及绘图等。我认为这是一个充满雄心的教学方式，不过在好的（不一定是极好的）大学里好的学生身上效果不错。
荣耀: 虽然这个问题应该去问Alex Stepanov本人，不过由于最近您们二位结伴前来中国杭州参加一个嵌入式软件系统会议，我顺便想打听一下，Alex目前是否在为C++新标准库忙些什么？
Bjarne: 实际上你真的应该去问Alex本人。他的见解总是很有意思，而且往往出人意料。是的，他也参加了那个大会。在杭州，我们分别做了主题报告并给大学生们做了演讲。让很多人感到惊讶的是，他的报告是着眼于软件业的金融基础的，而绝大多数人所期望的是他能做一个关于STL的高性能应用的演讲。我讲的是有关将抽象映射到机器层结构上的东西，这是C++在嵌入式系统编程中高效应用的基础。我很多主要的想法都可以在C++标准委员会关于性能的技术报告中找到（见我的C++主页上的链接http://www.research.att.com/~bs/C++.html）。
荣耀: 尽管在一些领域C++受到其它语言的挤压，但我相信未来10年内C++仍然是最重要的系统开发语言，您是否赞同这个观点？
Bjarne: 我并不认为C++被“挤压”了多少。IDC的评估数据表明，今天的C++程序员数量大约是十年前的三倍，而且C++仍然比任何其它语言更多地被使用。我认为，更确切的描述应当是这样的：C++在过去的十年里，只吸收了软件开发巨大膨胀的一部分。C++也正在向一些新领域扩张，譬如硬实时的程序设计。我怀疑“最重要的系统开发语言”这一说法很难被量化评估，但勿庸置疑，C++仍将占据非常重要的地位。关于C++应用的多样性，可以看看我列出的应用程序清单：http://www.research.att.com/~bs/applications./html。
荣耀: 还有没有我没有问及而您又希望补充的内容？
Bjarne: 你没有问我容易回答的问题。谢谢。
谢谢您，Bjarne Stroustrup！
— Bjarne Stroustrup 2005新春专访
荣耀/刘未鹏 译
荣耀: 根据您掌握的资料，模板和泛型编程在业界被广泛采用了吗？还是主要局限于库作者？您认为对于普通程序员（而非库作者）来说，面向对象和泛型编程哪一个更重要？为什么？您认为今后模板和泛型编程应该比今天得到更普遍的应用吗？
Bjarne: “加法和乘法哪个更重要？”大多数情况下这是个愚蠢的问题。同理类推，“面向对象编程和泛型编程哪个更重要？”的问题也毫无意义。关键在于，它们都是基础性的东西，并且是互补的。对于许多问题而言，最佳解决方案往往要求将它们结合运用。
从理论的角度来说，你是在“ad-hoc 多态”和“参数化多态”之间做出选择。而从实现角度来说，则是在“运行期多态”和“编译期多态”之间进行选择。你必须对两者都有所了解，并且恰当地使用它们。和“ad-hoc多态”（在C++中以类继承来表达）相比，“参数化多态”（在C++中以模板来表达）更具规则性，更利于逻辑或抽象思考。这就是为什么它被称为“ad-hoc”、为什么模板代码通常具有更好的性能、以及为什么当个体表达式和语句的性能很重要时我们应该考虑泛型编程的原因之所在。相反，类继承则能够在分离式编译和维护的代码块之间提供更为明晰的接口。
（译注：“ad-hoc”是“专门”的意思。事实上，多态一般分为“ad-hoc多态”和“universal多态”，前者一般指重载，后者一般指“参数化多态”（模板）或“包含多态”（类继承）。你可以从以下链接找到详细的解释：http://www.javaworld.com/javaworld/jw-04-2001/jw-0413-polymorph.html。）
我不能说哪个将会变得更重要，或者哪个应该更重要。那就好像是在加法和乘法之间偏袒某一方一样。但是我怀疑，和没有充分使用类继承和面向对象编程的人相比，有更多的人没有充分使用模板和泛型编程。因此，我更多的时候鼓励人们考虑并使用泛型编程而不是面向对象编程。我确信我们将会看到越来越多的泛型编程应用。泛型编程目前仍然没有被足够的理解和充分的使用。我们接受了近十年的面向对象的耳濡目染，所以我的感觉是面向对象常常被滥用了。值得注意的是，无论如何，泛型编程和面向对象编程这两种技术/风格都比使用一团乱麻似的选择语句、单薄的数据结构以及指针来解决问题要强得多。我们的目标应该是在代码中更为直接和优雅地表达思想，模板和类继承只是为了达到这个目的的工具。
我的感觉是许多“普通的程序员”确实使用了模板，而不仅仅是一些“库设计”方面的精英。当然，我们自己写的模板代码可能要比基础库里的代码简单一些，这很自然，因为对于其它编程技术来说，也存在同样的现象。
荣耀: 我想知道您对模板元编程的看法，您甚至选编了一本模板元编程的书。
Bjarne: 我想我并不愿意把泛型编程和模板元编程区别开来，它们的区别仅仅是在层次和侧重点上。我通常倾向于把这一块统称为泛型编程。事实上我认为模板元编程是一个非常重要的领域，而目前的C++对它的支持却不佳，以至于在生成的代码中它并不能发挥应有的潜力。我认为人们在这一领域所作的许多努力是实验性的，其中许多理应获得成功，因为比起替代方案来，它们能使代码更清晰地表达基础概念，并且具有更好的性能以及可维护性。然而C++98对这些技术的支持却不是很好，所以它们目前还不能成为主流。鉴于此，我在语言的改革方面所作的许多工作都跟泛型编程直接或间接有关。concept（用于分离式检查模板的使用和定义，以及用于更好地重载模板等），更好的初始化，以及更少的不规则性，都是对此有所帮助的努力，同样，用于支持标准库的设施（例如type traits）也会带来帮助。
荣耀: 我个人认为标准C++流库是面向对象和泛型编程结合运用的典范，您赞成这一点吗？对于准备尝试混合使用面向对象和泛型编程技术的程序员，您有什么建议或忠告？
Bjarne: 不，我认为流输入输出流是一个不错的早期尝试。然而，它仅仅是一个非常初步的尝试而已，随着时间的推移而显得过于精致而复杂（正如发生在大多数成功的系统中的那样）。我们现在可以做得更好。在我设计第一个流库时我意识到泛型编程的必要性，但是当时我并没有料到泛型编程最终会变成C++中如此重要的一个组成部分。
荣耀: 我必须得承认我也许太闭目塞听了，我真的没有看到过比标准C++输入输出流更好的面向对象编程和泛型编程的结合应用范例。您能给我一些线索吗？更重要的是，您能告诉我们有哪些是结合运用面向对象编程和泛型编程的最佳场合？谢谢！
Bjarne: 如果你面对的问题既需要某些运行期决议（需要面向对象编程），又具有一些能够从编译期决议中获益的方面（泛型编程的用武之地）的话，那么你就需要将面向对象编程和泛型编程结合起来。例如，面向对象编程的经典例子 — 将一个保存了shape的容器中的所有元素都显示出来就属于这类问题。几十年前我第一次在Simula中看到过这个例子，后来直到遇到了泛型编程，我才看到它的改进实现。考虑以下代码：
void draw_all(vector〈Shape*〉& vs)
{
for (int i=0; i〈vs.size(); ++i) vs[i]-〉draw();
}
我猜想这并不能被看作纯粹的面向对象编程，因为我直接利用了“vs是一个装有Shape*元素的vector”这个事实。毕竟，类型的参数化通常是被认为属于泛型编程的范畴。我们也可以消除这种对静态类型信息的使用（所谓“不纯粹的面向对象编程”）：
void draw_all(Object* container)
{
Vector* v = dynamic_cast〈Vector*〉(container);
for (int i=0; i〈v.size(); ++i)
{
Shape* ps = dynamic_cast〈Shape*〉(v[i]);
ps-〉draw();
}
}
但凡鼓励以上这种风格的语言，其语法通常都比较漂亮，然而这个例子却说明了当你把静态类型信息的使用减至最小的时候发生了什么。如今，在C++或其它语言中，仍然有人在使用这种风格。我只是希望他们在错误处理方面有系统化的准备。
在前一个例子中，vector〈Shap*〉依赖于对泛型编程的一个最简单的运用：vector的元素类型被参数化了，而且我们的示例代码正获益于此。在这个方向上我们还可以走得更远，即推而广之到所有标准库容器身上：
template〈class Container〉 void draw_all(Container& cs)
{
for (typename C::iterator p=cs.begin(); p!=cs.end(); ++p)
(*p)-〉draw();
}
例如，这段代码就既可以作用于vector上，又可以作用于list上。编译期决议确保我们不用为这种泛化处理付出任何运行期额外代价。我们还可以通过在draw_all()的使用接口中运用迭代器，从而进行进一步的泛化处理：
template〈class Iter〉 void draw_all(Iter fist, Iter last)
{
for (; first!=last; ++first)
(*first)-〉draw();
}
这就使内建数组类型都得到了支持：
Shape* a[max];
// 向a中填充Shape*类型的元素
draw_all(a,a+max);
我们还可以结合运用标准库算法for_each()和函数适配器mem_fun()来消除显式的循环：
template〈class Iter〉 void draw_all(Iter fist, Iter last)
{
for_each(first, last, mem_fun(&Shape::draw);
}
在这些例子中，我们结合了面向对象（对虚函数draw()的调用以及对类继承体系的假设）和泛型编程（参数化的容器和算法）技术。我看不出如果这两种编程风格（即所谓的“范型”）各自独立运用如何达到同样好的效果。这也是一个简单的“多范型编程”的例子。
我认为在设计和编程技术方面，我们还需要做更多的工作，以便确定出“关于何时采用哪种范型以及如何结合运用它们”的更为具体的规则。为此，我们还需要一个比“多范型编程”更好的名字。
注意，这也是一个关于编译错误信息变得可怕的例子，因为我们并没有显式地表达出我们的假设。例如，我们假设容器里的元素类型为Shape*，然而在代码中，这个假设却相当隐晦。这种情况下我们可以使用约束类（此处为Point_to）：
template〈class Iter〉 void draw_all(Iter fist, Iter last)
{
Points_to〈Iter,Shape*〉();
for_each(first, last, mem_fun(&Shape::draw);
}
然而我们又确实很想说明“first和last必须为前向迭代器”：
template〈Forward_iterator〈Shape*〉 Iter〉
void draw_all(Iter fist, Iter last)
{
for_each(first, last, mem_fun(&Shape::draw);
}
这是“concepts”可以大展拳脚的地方之一。
荣耀: 请原谅我重复一个老俗套问题。由于Java和C#今天都已经大获成功，您对Java和C#曾经的看法今天有无改变？我个人认为，与其说Java和C#的成功是语言自身的成功，还不如说是SUN的Java战略和微软的.NET战略的成功。
Bjarne: 在对它们的本质技术优点以及对它们的市场能量的估计上面，我都是正确的。低估市场的影响是不明智的，尤其当它背后有价值上百万美元的“免费”库所支持的时候。Java和C#是不坏的语言，而且SUN及其盟友以及微软及其盟友为其（过分夸张）的宣称提供重大的库和工具的支持。不过，这么说并不意味着我比喜欢C++更喜欢它们，对于要求严苛的应用而言更是如此。
荣耀: 您自觉或自发地使用过GOF描述的设计模式了吗？您对设计模式怎么看？您对Loki库中采用模板技术描述的静态设计模式怎么看？
Bjarne: 我并不喜欢根据特定的具名模式去思考，但我知道并且通常会使用这些在《设计模式》中描述的技术。顺便一提，《设计模式》是一本经典书籍，人们在搜寻最近最好的信息时不应该忘了这本书。其中的许多模式对于好的设计来说非常重要 — 给它们起什么名字倒无所谓。甚至你在TC++PL中也能够找到一些有关它们的运用。要想了解在某个特定领域中对模式有意识且系统的运用，可以参考“深入C++系列”中Schmit和Hunston的两本关于ACE的书。
除了明显的强大能力之外，我认为模式有两大弱点：
它倾向于鼓励“精致的专用术语”，这会阻碍新手的学习。
如果没有具体的“工具”支持，要想把一个思想广泛地传播到应用中是极其困难的。
例如，一个优秀的库本身携带了很多优秀的思想，并允许程序员（和设计者）直接利用这些思想在库中的实现品来工作。而模式只是对某个思想（或一系列互相关联的思想）的尽量一般性的描述，并刻意避免将这些思想作为库实现出来而招致的特殊性。这就导致了这些思想在传播上的问题，以及从代码中如何识别出模式的问题 — 特别是在代码被维护修改过之后。同样，要想从抽象层面上来理解一个模式也是非常困难的。在某个模式的抽象描述之后的实例代码进入我的视野之前，我倾向于对自己的理解持保留态度。我见到过一些人，他们认为自己是在使用某个模式，而实际上做的却是该模式被设计用来避免的事情。这些都说明思想的传授可能会异常困难。
可以让模式更具有可利用性的方式之一是为某些特定的环境提供模式的库的实现。Andrei Alexandrescu的书和他的Loki库可以被看成一次寻求结合高灵活性和高效率（和手写代码一样高效）编程风格的尝试。而模板元编程在大多数情况下都符合这个描述，STL亦然。为了从这种非常一般性的参数化中获益，设计（或编码）抉择必须从运行期转移到编译期，从而程序才更容易在时间或速度上得到优化。遗憾的是，许多编译器都不能很好地把握模板技术所提供的明显的优化机会，这通常是由于编译器过早地扔掉了类型信息，并试图去优化每一片代码，就好像它们是用弱类型风格的C所编写的一样。
荣耀: 您用过UML吗？您对UML怎么看？您认为它对C++程序设计很有用吗？
Bjarne: 我尝试过UML，但并不是为了一些严肃的事情，所以我的看法参考价值不大。对于我最常考虑的设计问题来说，UML不是特别有意义。我发现在设计和记录设计时草图是不可或缺的，但我并不认为把过多的细节加到草图中是个好主意。相比之下，代码更易于表达精确的关系。当然了，这么说并不意味着UML没有用，我所尊敬的一些人认为UML在文档化大型系统时非常重要。
荣耀: 您目前还在写书吗？或者有C++新书写作计划吗？
Bjarne: 我目前正基于我正在讲授的一门新手课程撰写一本面向初学者的编程书。这对于那些具有很少甚至没有编程背景但很想通过努力成为程序员的人应该有所帮助。此前我从未试图为非程序员写书，因为我对完全没有编程经验的人们所知甚少。现在我正教授初学者，这就让我有机会去尝试我的想法，并基于我的教学经验对之不断修改。对于任何瞄准于初学者的东西来说，这样做都是必不可少的。
我的目标是先教给新手最小的一套原则、技术以及语言设施，让他们可以先开始第一个实在的项目。基本上，我打算让那些想要成为职业C++程序员的人由此起步。为了达到这个目的，我一开始的讲授要涵盖很多背景知识，包括数据结构、算法、图以及类设计等，这在传统的教学中是不会很早涉及的。这比我了解到的当前大多数的教学方式更加雄心勃勃。当然，我使用C++作为编程语言，并且我会在讲授中涵盖STL的基础知识。
荣耀: 您能透露一下您的新书何时出版吗？
Bjrane: 我还没有写完呢，而且我还没有跟出版商（Addison-Wesley）协商好进度计划。至少我还需要半年时间来和我的学生们一起精化和锤炼这本书。理论上，我们（Lawrence Petersen是我的合作作者）在明年秋天大概可以完成，如果我们在重审的过程中发现了重大问题的话，那就得等到圣诞节之后才能付梓了。我知道出版商会督促我们早点完成，而我们则会争取更多的时间来检验这本书并采纳反馈。对于这样的一本书，我们是不可以草率对待的。
荣耀: 您对您负责编辑的“深入C++系列”（Addison-Wesley）有何评论？您是否认为其中一些书已经过时了？一些书仅对有限的读者群有作用？您对新近出版的几本书有何评价？还有哪些新成员即将加入这套丛书？我特别想听一听您对《Modern C++ Design》和《C++ Template Metaprogramming》这两本书的看法。
Bjarne: 过时？一些早期的书的确有点过时，但是从总体上来说，这些书都很好地经受住了时间的考验。新的书籍会以稳定的速度加进来。我的猜想是每年会增加三本新书。当然，我希望有更多，但是要想找到质量和实用性足够好的“轻薄洗练”的书并非易事。事实上我很期望能够看到更多精专的书，比如着眼于数值计算的特定方面的书，以及嵌入式系统编程方面的书。人们应该注意的是，这些书中的许多都是以专家或至少有经验的程序员为目标读者的。并且，作为一个专家，应该知道何时使用何种技术。我认为泛型编程和模板元编程是将来的一部分，但那只能算是基础，而STL这样的东西才是当前的主流。你所读到的一些书，像Alexandrescu和Abrahams的那两本书，会为你带来新的概念和可供试验的思想，但是你并不会在正准备部署的系统中立即应用这每一项技术。
荣耀: 您对Boost似乎情有独钟。“深入C++系列”中已经包含了《Boost Graph Library》和《C++ Template Metaprogramming》两本书，我猜将来还会有更多有关Boost的书会加入到这个系列中来，您对Boost怎么看？选编这方面的图书出于什么考虑？
Bjarne: 事实上，我并非根据它们是否是关于Boost的来选择书籍，“深入C++系列”中的大部分书籍都不是关于Boost的。我根据它们是否提供了有关编程技术、原则和概念的有用信息做出选择。恰巧Boost的作者在尝试“根据标准库的精神”来扩展基础库时，使用了有趣的技术去解决有趣的问题而已。
荣耀: 在过去的一年里，只出了有限的几本C++书籍。除了“深入C++系列”中的三本新书外，Addison-Wesley还出版了一本《Imperfect C++》，您对这本书怎么看？（译注：因本书由我们翻译，故有此一问。）另外， 您认为C++0x标准会催生更多的C++新书出版吗？
Bjarne: 人们好像没有以前那样喜欢读书了。今年的C++新书只有寥寥几本，不过已出版的C++书籍已经有很多。“老”书并不一定过时。我认为我自己的书就是很好的例子。《C++程序设计语言》卖得比大多数新近出版的书要好，而《C++语言的设计与演化》则刚刚被翻译成日语。类似地，K&R（译注：《C程序设计语言》）在25年后的今天仍然是最畅销的书！请不要忘了经典。我觉得有一个现象蛮有趣的，我附近的技术书店的Java部分的书几年来第一次比C++部分小了。
我看过《Imperfect C++》的草稿。如果它的页数可以降到原来的一半的话，我非常愿意把它加入到“深入C++系列”中去。该书作者是一个C++热爱者，他希望向开发者展示如何对付C++中诸多不完美之处，以便写出更好的代码，而这些代码在声称为“理想”的语言中更难实现。
我期望C++0x会催生一批新一代的C++书籍。不过，我希望这些新书能够集中于语言对编程风格和设计技术更强固的支持上，而不是简单地列举语言特性。我们已经看到了一大堆令人厌烦的列举语言规则的书。如果孤立开来看，任何语言特性都是无趣的，真正有趣的主题是编程。
荣耀: 由于您正在给C++新手讲解编程课，您愿意给世界上其他C++教师谈些教学经验吗？
Bjarne: 多年来，我一直对普遍的编程教育尤其是C++教学质量感到不愉快。当然，有很多好老师，而且也确实有很多学生变成了很好的程序员，然而，严重误导性的教学和被严重搞迷惑的程序员似乎没有个尽头。大概一年半前，有人建议我为编程新手设计一个全新的编程课程。我有过犹豫，但最终还是答应了，我和我们最具经验的讲师Lawrence Petersen合作，他会弥补我在教授新手方面的经验的不足。我们设计了课程并已讲授了两学期，并且基于我们的讲授方式、客观效果以及反馈（反馈是不可或缺的），不断加以改进。
当然，我并非仅凭个人的主观看法和所知的实验性的途径就一意孤行。事实上，我阅读了大量的口碑好的C++编程入门教材，看看它们到底好在何处。大约有两个星期，我烦躁地走来走去，抱怨着“要是那些玩意就是C++的话连我自己都不会喜欢它！”。我的感觉是许多教材彻底讹传了C++，可怜的学生们！所以，我们首先基于“一个学生成为职业程序员所需要的”知识列出了一个课程大纲，写了讲稿，列出了练习并附以大量的告诫。我们快速的重审材料并根据哪些可行、哪些不可行多次对其进行了调整。是年秋天，我们再次重审了材料，并且将课程的文字印刷成书。这下好多了，但是我们根据学生的反馈再一次调整了许多细节。我们的确越做越好，学生们的反响（包括口头反映和考试成绩）说明了这一点。今春，我们将会再一次讲授这门课，到了夏末时大概就可以进行更大范围的普及推广了。
我们把这种讲授方式称为“深度优先”，因为在课程一开始，我们会给学生介绍许多材料但并不深入细节。我们从第二周开始简单地使用STL，到了第五周学生就知道错误处理策略和类设计。在那之后，我们拓宽他们的知识面，并且让他们把知识应用到一些领域去，譬如文本处理、文件操纵以及绘图等。我认为这是一个充满雄心的教学方式，不过在好的（不一定是极好的）大学里好的学生身上效果不错。
荣耀: 虽然这个问题应该去问Alex Stepanov本人，不过由于最近您们二位结伴前来中国杭州参加一个嵌入式软件系统会议，我顺便想打听一下，Alex目前是否在为C++新标准库忙些什么？
Bjarne: 实际上你真的应该去问Alex本人。他的见解总是很有意思，而且往往出人意料。是的，他也参加了那个大会。在杭州，我们分别做了主题报告并给大学生们做了演讲。让很多人感到惊讶的是，他的报告是着眼于软件业的金融基础的，而绝大多数人所期望的是他能做一个关于STL的高性能应用的演讲。我讲的是有关将抽象映射到机器层结构上的东西，这是C++在嵌入式系统编程中高效应用的基础。我很多主要的想法都可以在C++标准委员会关于性能的技术报告中找到（见我的C++主页上的链接http://www.research.att.com/~bs/C++.html）。
荣耀: 尽管在一些领域C++受到其它语言的挤压，但我相信未来10年内C++仍然是最重要的系统开发语言，您是否赞同这个观点？
Bjarne: 我并不认为C++被“挤压”了多少。IDC的评估数据表明，今天的C++程序员数量大约是十年前的三倍，而且C++仍然比任何其它语言更多地被使用。我认为，更确切的描述应当是这样的：C++在过去的十年里，只吸收了软件开发巨大膨胀的一部分。C++也正在向一些新领域扩张，譬如硬实时的程序设计。我怀疑“最重要的系统开发语言”这一说法很难被量化评估，但勿庸置疑，C++仍将占据非常重要的地位。关于C++应用的多样性，可以看看我列出的应用程序清单：http://www.research.att.com/~bs/applications./html。
荣耀: 还有没有我没有问及而您又希望补充的内容？
Bjarne: 你没有问我容易回答的问题。谢谢。
谢谢您，Bjarne Stroustrup！
[转]C++热点问题一席谈（上）— Bjarne Stroustrup 2005新春专访
C++热点问题一席谈（上）
— Bjarne Stroustrup 2005新春专访
荣耀/刘未鹏 译
荣耀: Herb Sutter和Stan Lippman目前正在微软主持C++/CLI的设计工作，意图将动态的、基于组件的.NET编程模型和ISO C++集成在一起。您对此有何评价？您认为C++需要.NET吗？您认为C++/CLI会取得成功吗？
Bjarne: 不，C++根本不需要.NET，C++只需要最小限度的运行时支持，用于new/delete、异常处理以及RTTI等，而且仅当你使用这些特性时才需要。C++程序通常可以使用每一分可用的资源，在硬件上直接跑。C++的这些能力使其非常适合于系统级编程以及嵌入式系统任务。当然，也有些C++应用需要.NET，比如那些为了和微软.NET框架和服务紧密集成而专门设计的应用。然而，C++语言和标准库的宗旨是远离这些平台相关性的纠缠。另一方面，许多.NET设施都依赖于C++，因为除了C++之外，再也找不到更通用、更高效的语言来很好地完成这个任务，从这个意义上说，.NET需要C++。
从“很多人将会使用它”这个意义上来说，C++/CLI是会成功的。使用.NET CLI，开发者选择甚少，而C++则是最佳选择之一，而且很明显在Windows上也是，因为微软给予C++最好的支持。话虽如此，我仍然倾向于在设计系统时保持良好的移植性，而将对平台相关或专有特性的使用限制在特定的代码块中，并使用以ISO标准C++所表达的接口去访问它们。
荣耀: 尽管我现在相信这是一个毫无意义的问题，不过我想我最好还是澄清一下。当我说“C++需要.NET吗？”，我的意思是想问“我们需要.NET来使C++更普及吗？”。这就好比问“世界和平需要美国吗？”，或者，“我们需要美国来维护世界和平吗？”。当然了，我们都不喜欢讨论政治性话题，也许这个比方很不合适。
Bjarne: 政治关乎可行性。从这个意义上来说，我们必须考虑政治，而你的问题当然也是合理的。鉴于微软在软件领域的地位以及它对.NET强大而完全的支持（将.NET的系统接口以CLI来表达），.NET的地位会变得很重要。要想在微软的世界里玩得转的话，C++必须很好地绑定到.NET。事实上这种绑定（C++/CLI）已经建立了，微软还为之申请了ECMA标准。.NET跟我理想中的尚有些差距，而C++/CLI如果让我来设计的话可能也不会是这个样子，然而不可否认的是，C++/CLI在.NET上的确是能力非常强的语言，也是迄今为止为.NET设计的语言中能力最强的。如果微软未考虑将C++作为.NET上的关键语言之一，或者.NET平台上的应用创建者没有坚持对C++提供第一流支持的话，情况会糟很多。
所以，为了能够在微软的世界里流行，C++需要一个良好的CLI绑定。我仍然鼓励人们将C++/CLI仅仅视作一个绑定物。这就是说，把对C++/CLI特性的使用隔离到一些特定的区域里，并且通过ISO标准C++设施去访问它们。C++/CLI的一些设施使其成为一门具有吸引力的语言，然而和标准C++却相去甚远，所以如果你在代码中到处使用这些C++/CLI设施的话，那么你将失去平台无关性，并有损失性能优势的潜在危险。
荣耀: 鉴于Herb Sutter的双重身份：ISO C++标准委员会主席和微软软件架构师，C++/CLI对C++0x标准会产生什么样的影响？这种可能的影响是您希望看到的吗？
Bjarne: C++/CLI会在一些领域对C++产生影响，因为将会有许多人使用它。显而易见，在使用中人们将会建议加入一些新的设施，以便和ISO C++平滑地互操作。在确保ISO C++平台中立的前提下，这些建议会依据其优点而被评估。我并不认为Herb的双重身份会带来任何负面影响。请注意，ISO委员会的会议召集人的角色属于管理方面的。我认为微软将Herb的才能贡献到标准化进程中是一个积极的信号。一如往常，微软在实践着其“拥抱并扩展”策略，但至少他们拥抱的是ISO C++而非某种C++方言。
荣耀: C++0x标准大概可于哪一年颁布？目前标准化工作进展如何？我们在这个新标准中预期可以看到哪些新特性？
Bjarne: 我希望三、四年内能够颁布，不过目前我们还没有一个明确的进度表。
我们打算在语言的扩展上持保守态度，并在与C++98的兼容性方面仔细斟酌。改进的关键可能会落在对泛型编程更好的支持以及对新手更易学习上。我们期望一个关于模板实参的类型系统“concepts”能成为泛型编程的基石。
在标准库的扩展方面我们打算胆子更大一些。新标准库技术报告也许会使你对它的发展方向有一些认识。我们的关键目标是使标准库成为一个更广泛的系统编程平台！
荣耀: 一个冒昧的问题。为什么C++标准委员会主席是Herb Sutter而不是您？我记得您是进化工作组主席，我们都很有兴趣知道您在目前标准化过程中具体从事什么工作。
Bjarne: 我并不想担当会议召集人的职务。Herb和他的前任们在那个职位上比我所能做到的要出色得多。会议召集人主要负责管理性和组织性的事务。我的（非正式的）角色在于努力维持语言一致性的方向。我是语言进化工作组的主席，这个工作组负责处理所有语言扩展方面的提议。这个职位意味着绝大部分定义语言改变的文本都是我写出来的，而这些文本最终形成了标准文档。
作为进化工作组的主席，目前我正致力于三件事情：“concept”，改进的初始化设施，以及对C++新手的更好支持。你可以从我的主页上以下链接看到人们对标准下一个修订版（即“C++0x”）建议的期望特性列表：http://www.research.att.com/~bs/C++.html。简单的数一下你就会发现这些特性根本不能全部塞到标准中去，所以，我们需要一些优先级上的考虑。此外，我们还需要把注意力集中到一些相互关的问题上，而不是每次单独处理这些个体提议。如果把每个特性都单独考虑的话，你无论如何也不能得到一个内在一致且易教学的语言。正如语言本身一样，特性必须是为解决问题而设计的，而不仅仅是一个一个地“看上去很美”。
让我扼要介绍一下我眼下正以高优先级进行的三个语言扩展：concepts，初始化，以及“消除一些令人不愉快的瑕疵”：
在《C++语言的设计与演化》（D&E）中对模板的讨论部分，我花了整整三页来讨论模板实参的约束。很明显，我觉得它需要一个更好的解决方案。在使用模板（例如标准库算法）时哪怕出一丁点儿差错都可能招致极其“壮观”而无用的错误信息。问题在于，模板代码对其模板实参的“期望”是隐式的。让我们考虑一下find_if()：
template〈class In, class Pred〉
In find_if(In first, In last, Pred pred)
{
while (first!=last && !pred(*first)) ++first;
return first;
}
这里，我们对类型In和Predicate作了若干假设。从代码中我们可以看出，In必须支持!=、*和++，并且这些操作符还必须具有恰当的语义。另外，我们必须能够拷贝In类型的对象作为实参和返回值。类似地还可以看出，我们可以“以*作用在In对象上所返回的值”作为实参来调用Pred，并且把“!”运用到该调用返回的结果上，从而得到一个可以在语义上看成是布尔值的东西。然而，这些约束在代码中都是隐式表达的。标准库为前向迭代器（此处为In）以及谓词（此处为Pred）小心翼翼地记录了各自要求的条件，但编译器可不会阅读文档！试试以下错误的代码，看看你的编译器会有什么反应：
find_if(1,5,3.14); // 错误！
我以前的想法提供了一个不完备、但相当高效的解决方案，即使用一个构造函数来检查对于模板实参的假定条件（见D&E 15.4.2），这个解决方案现在得到了广泛运用，被称为“concepts（概念）”或“constraints classes（约束类）”。你可以从我的主页上的技术FAQ中找到一些例子：http://www.research.att.com/~bs/bs_faq2.html#constraints。
然而，我们真正想要告诉编译器的是“我们期望模板实参是什么样子的”或者“我们期望模板实参满足哪些要求”，例如：
template〈Forward_iterator In, Predicate Pred〉
In find_if(In first, In last, Pred pred);
假设我们可以表达Forward_iterator和Predicate是什么，编译器就能够在不用查看find_if()定义的情况下检查对它的调用是否正确。这里我们所要做的就是为模板实参构建一个类型系统。在现代C++中，这种“类型的类型”被称为“concepts”。有多种方式可以用于表达concepts，眼下我们暂且把它们看成一些受到直接的语言支持并具有优雅语法的“约束类”。一个concept表明了一个类型必须提供哪些能力，但并不强制规定它们如何提供这些能力。理想的concept（例如〈Forward_iterator In〉）应该非常类似于数学抽象（对于任意的In，它必须可被递增（++）、解引用（*）以及拷贝），就像原来的形式“〈class T〉”从数学上来说是“针对所有的类型T”那样。
这样一来，在仅仅给出find_if()的声明的情况下，我们可以写：
int x = find_if(1,2,Less_than〈int〉(7));
这将会失败，因为int并不支持解引用（*）。换句话说，这个调用将不能通过编译，因为int并不是一个Forward_iterator。很重要的一点是，这将会使编译器更容易在该调用首次被看到的那一点上报告用户所犯的错误。
遗憾的是，仅仅知道iterator实参是Forward_iterator以及predicate实参是Predicate还不足以保证对find_if()的调用能够成功编译。这两个实参类型之间是有着交互作用的。说得详细一点就是，predicate所接受的实参是一个被解引用的iterator （pred(*first)）。我们的目标在于对模板进行“和调用相分离”的完全检查以及无需查看模板定义就能对每次调用进行的完全检查，所以，concept必须具有足够强的表达力，以便处理这种模板实参之间的交互关系。方式之一是对concept本身也进行参数化，就像模板本身的参数化那样。例如：
template〈Value_type T,
Forward_iterator〈T〉 In, // 对一个T序列进行迭代
Predicate〈bool,T〉 Pred〉 // 接受一个T并返回一个bool
In find_if(In first, In last, Pred pred);
在这儿，我们要求Forward_iterator必须指向一个T类型的元素，而该元素的类型必须和Predicate的实参类型一样（译注：实际上只要类型兼容即可）。
这方面的工作正在进行中。你可以从C++委员会的文件、学术文献以及有关C++0x的讨论中找到这方面更多的信息，在这里我没有太多的时间或地方进行更详细地阐述。“concept”的目标是提供模板使用和模板定义的完美的分离式检查，同时不引入任何运行期负担（译注：在C#的所谓的泛型中，concept只不过是间接函数调用的语法糖而已，运行期额外负担仍然存在。）以及不必要的concept耦合（译注：在C#所谓的泛型中，concept要求模板实参继承自一个公共基类，因此耦合仍然存在。）。
换句话说，我们想要把静态类型检查的好处引入到C++中的高度抽象的层面上去，同时不损及目前的模板技术所提供的灵活性和效率。
C++的基本思想之一是“对用户定义类型提供和内建类型一样良好的支持”（见D&E4.4）。但考虑下面这个例子：
double vd[ ] = { 1.2, 2.3, 3.4, 4.5, 5.6 };
vector〈double〉 v(vd, vd+5);
我们可以直接使用“初始化列表”来直接初始化数组，而对于vector，最好的情况是我们可以先创建一个内建数组然后再用它来初始化vector。如果只有很少的几个初始化值，我可能会倾向于使用push_back()以避免将初始值的数目显式“写死”在代码中（上面例子中的初值是5个）：
vector〈double〉 v;
v.push_back(1.2);
v.push_back(2.3);
v.push_back(3.4);
v.push_back(4.5);
v.push_back(5.6);
我想任何人都不会认为这两种解决方案有任何“优雅”可言。要想得到可维护性更好的代码并且让vector比内建（具有固有的危险性）数组更“讨人喜欢”的话，我们需要这样的能力：
vector〈double〉 v = { 1.2, 2.3, 3.4, 4.5, 5.6 };
或者：
vector〈double〉 v ({ 1.2, 2.3, 3.4, 4.5, 5.6 });
由于实参传递是依据初始化来定义的，因此这对接受vector为参数的函数同样奏效：
void f(const vector〈double〉& r);
// …
f({ 1.2, 2.3, 3.4, 4.5, 5.6 });
（译注：这里即是说，实参传递和初始化的语义是一样的，例如：
void f(T a);
f(x);
这里“把x作为实参传递给a”的过程等同于
T a = x;
这是个初始化表达式。）
我相信这种初始化器（initializers）的一般形式将会成为C++0x的一部分，这不过是将成为对构造函数进行全面检修的一部分，因为人们已经发现了有关构造函数的不少弱点，这些弱点看起来可以通过对构造函数进行一些修整来解决，例如“转发构造函数（forwarding constructor）”、“有保障的编译期构造函数（guaranteed compile-time constructors）”以及“继承的构造函数（inherited constructors）”等。
第三件事是“剔除语言里的一些令人不愉快的瑕疵”，也就是说，修整一些细小的不合常规或不方便的东西，它们对有经验的C++老手不会产生什么影响，然而却可能严重打击C++新手。一个非常简单的例子就是：
vector〈vector〈double〉〉 v;
在C++98中，这里有一个语法错误，因为“〉〉”被看成一个单独的词汇标记，而不是两个“〉”。正确的写法如下：
vector〈 vector〈double〉 〉 v;
对于C++98这样一个“不近人情”的规则，虽然有足够技术上的理由，但这不应该强加给任何背景的新手（包括其它语言的专家）。如果编译器不接受前一种最为明显的v的声明形式的话，那么C++用户和教师都会在这上面浪费大量的时间。我希望这个“〉〉问题”以及其它一些瑕疵都会在C++0x中消失。事实上，在和Francis Glassborow以及其他一些人的工作中，我一直努力去系统地消除出现频率最高的此类语言瑕疵。
荣耀: 和大多数人一样，我认为C++缺乏一个大一统的库是阻碍C++更为广泛地使用的关键原因，您认为现在C++社群有足够的资源来开发一个像Java或.NET那般规模的库了吗？如果没有，我们该怎么做？我发现使用形形色色的第三方库非常不方便（一个插曲。我在使用微软Visual C++时，有时希望使用STL组件，例如vector，但由于我大幅使用了MFC，而MFC中也有类似的容器，所以，虽然vector更好用，但为了避免因链接两个不同的库而导致文件体积增大，我最终往往放弃使用标准库。不过，倘若标准库提供了MFC所提供的所有功能，我将肯定全部改用标准库）。
Bjarne: 毫无疑问，MFC是迄今为止被广泛运用的最糟糕的基础库。它违反了一个好的C++设计应该遵循的大多数原则。它严重地扭曲了许多程序员对于“什么是C++”的看法！
当然，我也认为缺乏全面且标准的基础库是C++社群的一个主要问题。对于个体程序员来说，这也许是他们面对的最困难的问题。我在《C++语言的设计与演化》中谈到了这一点，至今我仍然坚持这一点。
C++社群没有一个有钱的公司来支持“平台中立的”标准库的开发 — 从来没有，跟其它专有语言（以及它们的“标准”库）相比，这一直是阻碍C++发展的一道藩篱。和专有的基础库的扩展速度相比，我们对标准库的扩展是很慢的（不过和其他ISO标准库相比，我们的扩展速度应该算是比较快的）。我们还期望能够和新兴的非标准库（译注：如Boost）逐渐达成更为平滑的整合。别忘了，当年MFC以及其它“后80年代”风格的库被设计出来投放市场之际，尚无任何标准库可作它们的构建基础。因此，我希望今后的专有库和开源库都能充分尊重标准库，以便使它们之间的互操作变得容易 — 至少容易一点点。
C++社群并不是为大规模设计和实现而组织的。C++社群中也没有什么传统或惯例。和其它社群相比，我们缺少一个“统帅”，他可以有效地激励新库的创建，否决或“保佑”我们的努力和成果。然而，我对“统帅模式”是否可行心里没底 — 除非你所做的事情只是基本的模仿而已。Boost（www.boost.org）是一个优秀的成果，它的某些方面已经超出了模仿的范畴，然而它仍然缺乏一个明确的目标以及用于维持自身发展的权威机构或权威人物。
在以下三个相关的领域中，大规模的合作努力对于C++社群而言是必需且有意义的：基本的并发编程库（包括线程、锁和lock-free算法等）；平台无关的操作系统服务库（目录和文件操纵以及套接字等）；以及GUI编程库。前两个看起来是可行的，但要想建立一个标准的GUI库，也许从技术上、经济上尤其是政治上都显得太困难了。
荣耀: 是的，我相信对于许多C++程序员而言，一个标准的GUI库是极其重要的。许多人以为GUI库不是一个太复杂的问题，但我却认为这可能是最棘手的问题。为了解决它，我们可能需要难以置信的大量的资源。同时我认为政治问题可能是其他问题的根源。举个例子，我们知道Windows的GUI风格和Java的GUI风格是不一样的，甚至不同版本的Windows的GUI风格也不一样。而且我们知道GUI风格很不稳定，它发展演化得非常快，而且很容易被微软这样的大公司所引导和操纵。
Bjarne: 在这个问题上，资源（包括财力和人力）是一个关键问题，与“保持设计蓝图的一致性”同样重要。另外，即使我们已经有了这三样东西：蓝图、人力（数打甚至更多）、以及财力（至少要担负得起一些优秀的人在这个项目上的全职工作），这仍然会是个需要N年才能完成的项目。而SUN、微软、苹果以及其他主要竞争对手将会做些什么呢？毕竟包含了一个工业强度的GUI库的ISO标准C++对于它们的专有系统可不啻一记重击啊！我的猜测是它们大多会通过强大的市场手段来保护既得利益，标准委员会可不是为了在这种市场环境中呼风唤雨而组织起来的，我们至少还需要一个工业社团的支持以及和开源社群主力军的联盟。
荣耀: 在您看来，C++要想继续向前发展，除了开发一个更为广泛、更具威力的库以外，我们还应该做些什么？
Bjarne: 我认为库方面的工作是关键。标准委员会没有足够的资源去创建一个全新的库，而且无论如何“让委员会设计”都不是个好主意。如果人们创建了新的库，在紧密相关的领域把它们的努力融合起来以达到冲突最小，并且文献记录良好（并非只记录细节，还有设计原则），那么他们也许可以把这些东西带到委员会来，并有希望让它们成为标准。如果没有成为标准的话，至少他们的努力有最大的机会成为“准”标准。有此打算的人应该把C++真正当作“C++”（使用继承、模板以及异常等）来看待，而不是从其它特性不是那么丰富的语言中抄袭设计而来。如果一个库的设计被发现没有用C++最佳地表达出来，那么它被接受为标准的几率微乎其微。
另一个可作贡献的领域是对技术的开发和推广。C++往往被以“很不理想”的方式使用着，MFC就是一个典型的例子，它甚至还达不到80年代中期对一个良好的OO设计的看法！我所说的“不理想”，是指没有达到它所能达到的可维护性的设计（通常这是由于对设计决策的糟糕的分解、低劣的封装以及对概念的拙劣表达而造成的），而并非指在外部压力下要尽快把项目赶出来的个体程序员或团队的“不理想”。通常，一个较好的设计和现有的实践是背道而驰的，后者往往需要立即付出代价（往往在很短时间内）。显然，任何显著的改进都需要在“一切照常”的基础上，并且至少追加学习所需的代价以及时间上的延迟。
这就把我们带到了最重要并且也许是最明显的改进实践的途径面前：教育。我们对编程和设计的教育必须比当前做得更好。新的语言特性、新技术以及新库碰到了不能理解并使用它们的人仍然是无用之刃。遗憾的是，我们恰恰缺乏优秀的C++入门书籍。Francis Glassborow的新书《You Can Do It》（译注：中文版《C++编程你也行》即将由人民邮电出版社出版）和Koenig & Moo的《Accelerated C++》是打破旧式而令人厌烦的教育方式的例子。那种教育方式把C++当作一个“稍微好一点的C”或者一门在实现“真正的面向对象”方面失败的语言。前者倾向于用一大堆语言技术细节来迷糊和恼怒读者，偏离了学习好的编程及设计技术的正确道路。后者通常除了存在这些问题之外，还没能够教会在性能攸关的领域里编程的必要技术，而且没有让人感受到静态类型系统的价值。尤其遗憾的是，Glassborow和Koenig & Moo的书的风格都不是编程入门教材的传统风格，这也阻碍了它们的广泛普及。
我自己的两本书《C++程序设计语言》和《C++语言的设计与演化》的目标读者则是已经知道如何去编程然而不知道如何使用C++的人。这两本书确实满足了这部分读者，但我们要做的还不止这些。
任何时候只要有可能，程序员都可以通过将程序的主要部分用ISO C++来写，并将系统依赖性封装起来，从而来支持标准。也就是说，把系统依赖性限定到特定的区域，并通过以标准C++表达的接口去访问它们。通常这并不容易做到，因为厂商总是怂恿程序员在代码中使用专有的、排他性的特性，但这就影响了可移植性，从而使程序移植到其他系统上非常困难。然而，站在应用构建者的立场来说，从长远来看，挣脱厂商的束缚、维持可移植性是一件好事，这种隔离系统依赖性的努力终将从经济和技术两方面都得到回报。
— Bjarne Stroustrup 2005新春专访
荣耀/刘未鹏 译
荣耀: Herb Sutter和Stan Lippman目前正在微软主持C++/CLI的设计工作，意图将动态的、基于组件的.NET编程模型和ISO C++集成在一起。您对此有何评价？您认为C++需要.NET吗？您认为C++/CLI会取得成功吗？
Bjarne: 不，C++根本不需要.NET，C++只需要最小限度的运行时支持，用于new/delete、异常处理以及RTTI等，而且仅当你使用这些特性时才需要。C++程序通常可以使用每一分可用的资源，在硬件上直接跑。C++的这些能力使其非常适合于系统级编程以及嵌入式系统任务。当然，也有些C++应用需要.NET，比如那些为了和微软.NET框架和服务紧密集成而专门设计的应用。然而，C++语言和标准库的宗旨是远离这些平台相关性的纠缠。另一方面，许多.NET设施都依赖于C++，因为除了C++之外，再也找不到更通用、更高效的语言来很好地完成这个任务，从这个意义上说，.NET需要C++。
从“很多人将会使用它”这个意义上来说，C++/CLI是会成功的。使用.NET CLI，开发者选择甚少，而C++则是最佳选择之一，而且很明显在Windows上也是，因为微软给予C++最好的支持。话虽如此，我仍然倾向于在设计系统时保持良好的移植性，而将对平台相关或专有特性的使用限制在特定的代码块中，并使用以ISO标准C++所表达的接口去访问它们。
荣耀: 尽管我现在相信这是一个毫无意义的问题，不过我想我最好还是澄清一下。当我说“C++需要.NET吗？”，我的意思是想问“我们需要.NET来使C++更普及吗？”。这就好比问“世界和平需要美国吗？”，或者，“我们需要美国来维护世界和平吗？”。当然了，我们都不喜欢讨论政治性话题，也许这个比方很不合适。
Bjarne: 政治关乎可行性。从这个意义上来说，我们必须考虑政治，而你的问题当然也是合理的。鉴于微软在软件领域的地位以及它对.NET强大而完全的支持（将.NET的系统接口以CLI来表达），.NET的地位会变得很重要。要想在微软的世界里玩得转的话，C++必须很好地绑定到.NET。事实上这种绑定（C++/CLI）已经建立了，微软还为之申请了ECMA标准。.NET跟我理想中的尚有些差距，而C++/CLI如果让我来设计的话可能也不会是这个样子，然而不可否认的是，C++/CLI在.NET上的确是能力非常强的语言，也是迄今为止为.NET设计的语言中能力最强的。如果微软未考虑将C++作为.NET上的关键语言之一，或者.NET平台上的应用创建者没有坚持对C++提供第一流支持的话，情况会糟很多。
所以，为了能够在微软的世界里流行，C++需要一个良好的CLI绑定。我仍然鼓励人们将C++/CLI仅仅视作一个绑定物。这就是说，把对C++/CLI特性的使用隔离到一些特定的区域里，并且通过ISO标准C++设施去访问它们。C++/CLI的一些设施使其成为一门具有吸引力的语言，然而和标准C++却相去甚远，所以如果你在代码中到处使用这些C++/CLI设施的话，那么你将失去平台无关性，并有损失性能优势的潜在危险。
荣耀: 鉴于Herb Sutter的双重身份：ISO C++标准委员会主席和微软软件架构师，C++/CLI对C++0x标准会产生什么样的影响？这种可能的影响是您希望看到的吗？
Bjarne: C++/CLI会在一些领域对C++产生影响，因为将会有许多人使用它。显而易见，在使用中人们将会建议加入一些新的设施，以便和ISO C++平滑地互操作。在确保ISO C++平台中立的前提下，这些建议会依据其优点而被评估。我并不认为Herb的双重身份会带来任何负面影响。请注意，ISO委员会的会议召集人的角色属于管理方面的。我认为微软将Herb的才能贡献到标准化进程中是一个积极的信号。一如往常，微软在实践着其“拥抱并扩展”策略，但至少他们拥抱的是ISO C++而非某种C++方言。
荣耀: C++0x标准大概可于哪一年颁布？目前标准化工作进展如何？我们在这个新标准中预期可以看到哪些新特性？
Bjarne: 我希望三、四年内能够颁布，不过目前我们还没有一个明确的进度表。
我们打算在语言的扩展上持保守态度，并在与C++98的兼容性方面仔细斟酌。改进的关键可能会落在对泛型编程更好的支持以及对新手更易学习上。我们期望一个关于模板实参的类型系统“concepts”能成为泛型编程的基石。
在标准库的扩展方面我们打算胆子更大一些。新标准库技术报告也许会使你对它的发展方向有一些认识。我们的关键目标是使标准库成为一个更广泛的系统编程平台！
荣耀: 一个冒昧的问题。为什么C++标准委员会主席是Herb Sutter而不是您？我记得您是进化工作组主席，我们都很有兴趣知道您在目前标准化过程中具体从事什么工作。
Bjarne: 我并不想担当会议召集人的职务。Herb和他的前任们在那个职位上比我所能做到的要出色得多。会议召集人主要负责管理性和组织性的事务。我的（非正式的）角色在于努力维持语言一致性的方向。我是语言进化工作组的主席，这个工作组负责处理所有语言扩展方面的提议。这个职位意味着绝大部分定义语言改变的文本都是我写出来的，而这些文本最终形成了标准文档。
作为进化工作组的主席，目前我正致力于三件事情：“concept”，改进的初始化设施，以及对C++新手的更好支持。你可以从我的主页上以下链接看到人们对标准下一个修订版（即“C++0x”）建议的期望特性列表：http://www.research.att.com/~bs/C++.html。简单的数一下你就会发现这些特性根本不能全部塞到标准中去，所以，我们需要一些优先级上的考虑。此外，我们还需要把注意力集中到一些相互关的问题上，而不是每次单独处理这些个体提议。如果把每个特性都单独考虑的话，你无论如何也不能得到一个内在一致且易教学的语言。正如语言本身一样，特性必须是为解决问题而设计的，而不仅仅是一个一个地“看上去很美”。
让我扼要介绍一下我眼下正以高优先级进行的三个语言扩展：concepts，初始化，以及“消除一些令人不愉快的瑕疵”：
在《C++语言的设计与演化》（D&E）中对模板的讨论部分，我花了整整三页来讨论模板实参的约束。很明显，我觉得它需要一个更好的解决方案。在使用模板（例如标准库算法）时哪怕出一丁点儿差错都可能招致极其“壮观”而无用的错误信息。问题在于，模板代码对其模板实参的“期望”是隐式的。让我们考虑一下find_if()：
template〈class In, class Pred〉
In find_if(In first, In last, Pred pred)
{
while (first!=last && !pred(*first)) ++first;
return first;
}
这里，我们对类型In和Predicate作了若干假设。从代码中我们可以看出，In必须支持!=、*和++，并且这些操作符还必须具有恰当的语义。另外，我们必须能够拷贝In类型的对象作为实参和返回值。类似地还可以看出，我们可以“以*作用在In对象上所返回的值”作为实参来调用Pred，并且把“!”运用到该调用返回的结果上，从而得到一个可以在语义上看成是布尔值的东西。然而，这些约束在代码中都是隐式表达的。标准库为前向迭代器（此处为In）以及谓词（此处为Pred）小心翼翼地记录了各自要求的条件，但编译器可不会阅读文档！试试以下错误的代码，看看你的编译器会有什么反应：
find_if(1,5,3.14); // 错误！
我以前的想法提供了一个不完备、但相当高效的解决方案，即使用一个构造函数来检查对于模板实参的假定条件（见D&E 15.4.2），这个解决方案现在得到了广泛运用，被称为“concepts（概念）”或“constraints classes（约束类）”。你可以从我的主页上的技术FAQ中找到一些例子：http://www.research.att.com/~bs/bs_faq2.html#constraints。
然而，我们真正想要告诉编译器的是“我们期望模板实参是什么样子的”或者“我们期望模板实参满足哪些要求”，例如：
template〈Forward_iterator In, Predicate Pred〉
In find_if(In first, In last, Pred pred);
假设我们可以表达Forward_iterator和Predicate是什么，编译器就能够在不用查看find_if()定义的情况下检查对它的调用是否正确。这里我们所要做的就是为模板实参构建一个类型系统。在现代C++中，这种“类型的类型”被称为“concepts”。有多种方式可以用于表达concepts，眼下我们暂且把它们看成一些受到直接的语言支持并具有优雅语法的“约束类”。一个concept表明了一个类型必须提供哪些能力，但并不强制规定它们如何提供这些能力。理想的concept（例如〈Forward_iterator In〉）应该非常类似于数学抽象（对于任意的In，它必须可被递增（++）、解引用（*）以及拷贝），就像原来的形式“〈class T〉”从数学上来说是“针对所有的类型T”那样。
这样一来，在仅仅给出find_if()的声明的情况下，我们可以写：
int x = find_if(1,2,Less_than〈int〉(7));
这将会失败，因为int并不支持解引用（*）。换句话说，这个调用将不能通过编译，因为int并不是一个Forward_iterator。很重要的一点是，这将会使编译器更容易在该调用首次被看到的那一点上报告用户所犯的错误。
遗憾的是，仅仅知道iterator实参是Forward_iterator以及predicate实参是Predicate还不足以保证对find_if()的调用能够成功编译。这两个实参类型之间是有着交互作用的。说得详细一点就是，predicate所接受的实参是一个被解引用的iterator （pred(*first)）。我们的目标在于对模板进行“和调用相分离”的完全检查以及无需查看模板定义就能对每次调用进行的完全检查，所以，concept必须具有足够强的表达力，以便处理这种模板实参之间的交互关系。方式之一是对concept本身也进行参数化，就像模板本身的参数化那样。例如：
template〈Value_type T,
Forward_iterator〈T〉 In, // 对一个T序列进行迭代
Predicate〈bool,T〉 Pred〉 // 接受一个T并返回一个bool
In find_if(In first, In last, Pred pred);
在这儿，我们要求Forward_iterator必须指向一个T类型的元素，而该元素的类型必须和Predicate的实参类型一样（译注：实际上只要类型兼容即可）。
这方面的工作正在进行中。你可以从C++委员会的文件、学术文献以及有关C++0x的讨论中找到这方面更多的信息，在这里我没有太多的时间或地方进行更详细地阐述。“concept”的目标是提供模板使用和模板定义的完美的分离式检查，同时不引入任何运行期负担（译注：在C#的所谓的泛型中，concept只不过是间接函数调用的语法糖而已，运行期额外负担仍然存在。）以及不必要的concept耦合（译注：在C#所谓的泛型中，concept要求模板实参继承自一个公共基类，因此耦合仍然存在。）。
换句话说，我们想要把静态类型检查的好处引入到C++中的高度抽象的层面上去，同时不损及目前的模板技术所提供的灵活性和效率。
C++的基本思想之一是“对用户定义类型提供和内建类型一样良好的支持”（见D&E4.4）。但考虑下面这个例子：
double vd[ ] = { 1.2, 2.3, 3.4, 4.5, 5.6 };
vector〈double〉 v(vd, vd+5);
我们可以直接使用“初始化列表”来直接初始化数组，而对于vector，最好的情况是我们可以先创建一个内建数组然后再用它来初始化vector。如果只有很少的几个初始化值，我可能会倾向于使用push_back()以避免将初始值的数目显式“写死”在代码中（上面例子中的初值是5个）：
vector〈double〉 v;
v.push_back(1.2);
v.push_back(2.3);
v.push_back(3.4);
v.push_back(4.5);
v.push_back(5.6);
我想任何人都不会认为这两种解决方案有任何“优雅”可言。要想得到可维护性更好的代码并且让vector比内建（具有固有的危险性）数组更“讨人喜欢”的话，我们需要这样的能力：
vector〈double〉 v = { 1.2, 2.3, 3.4, 4.5, 5.6 };
或者：
vector〈double〉 v ({ 1.2, 2.3, 3.4, 4.5, 5.6 });
由于实参传递是依据初始化来定义的，因此这对接受vector为参数的函数同样奏效：
void f(const vector〈double〉& r);
// …
f({ 1.2, 2.3, 3.4, 4.5, 5.6 });
（译注：这里即是说，实参传递和初始化的语义是一样的，例如：
void f(T a);
f(x);
这里“把x作为实参传递给a”的过程等同于
T a = x;
这是个初始化表达式。）
我相信这种初始化器（initializers）的一般形式将会成为C++0x的一部分，这不过是将成为对构造函数进行全面检修的一部分，因为人们已经发现了有关构造函数的不少弱点，这些弱点看起来可以通过对构造函数进行一些修整来解决，例如“转发构造函数（forwarding constructor）”、“有保障的编译期构造函数（guaranteed compile-time constructors）”以及“继承的构造函数（inherited constructors）”等。
第三件事是“剔除语言里的一些令人不愉快的瑕疵”，也就是说，修整一些细小的不合常规或不方便的东西，它们对有经验的C++老手不会产生什么影响，然而却可能严重打击C++新手。一个非常简单的例子就是：
vector〈vector〈double〉〉 v;
在C++98中，这里有一个语法错误，因为“〉〉”被看成一个单独的词汇标记，而不是两个“〉”。正确的写法如下：
vector〈 vector〈double〉 〉 v;
对于C++98这样一个“不近人情”的规则，虽然有足够技术上的理由，但这不应该强加给任何背景的新手（包括其它语言的专家）。如果编译器不接受前一种最为明显的v的声明形式的话，那么C++用户和教师都会在这上面浪费大量的时间。我希望这个“〉〉问题”以及其它一些瑕疵都会在C++0x中消失。事实上，在和Francis Glassborow以及其他一些人的工作中，我一直努力去系统地消除出现频率最高的此类语言瑕疵。
荣耀: 和大多数人一样，我认为C++缺乏一个大一统的库是阻碍C++更为广泛地使用的关键原因，您认为现在C++社群有足够的资源来开发一个像Java或.NET那般规模的库了吗？如果没有，我们该怎么做？我发现使用形形色色的第三方库非常不方便（一个插曲。我在使用微软Visual C++时，有时希望使用STL组件，例如vector，但由于我大幅使用了MFC，而MFC中也有类似的容器，所以，虽然vector更好用，但为了避免因链接两个不同的库而导致文件体积增大，我最终往往放弃使用标准库。不过，倘若标准库提供了MFC所提供的所有功能，我将肯定全部改用标准库）。
Bjarne: 毫无疑问，MFC是迄今为止被广泛运用的最糟糕的基础库。它违反了一个好的C++设计应该遵循的大多数原则。它严重地扭曲了许多程序员对于“什么是C++”的看法！
当然，我也认为缺乏全面且标准的基础库是C++社群的一个主要问题。对于个体程序员来说，这也许是他们面对的最困难的问题。我在《C++语言的设计与演化》中谈到了这一点，至今我仍然坚持这一点。
C++社群没有一个有钱的公司来支持“平台中立的”标准库的开发 — 从来没有，跟其它专有语言（以及它们的“标准”库）相比，这一直是阻碍C++发展的一道藩篱。和专有的基础库的扩展速度相比，我们对标准库的扩展是很慢的（不过和其他ISO标准库相比，我们的扩展速度应该算是比较快的）。我们还期望能够和新兴的非标准库（译注：如Boost）逐渐达成更为平滑的整合。别忘了，当年MFC以及其它“后80年代”风格的库被设计出来投放市场之际，尚无任何标准库可作它们的构建基础。因此，我希望今后的专有库和开源库都能充分尊重标准库，以便使它们之间的互操作变得容易 — 至少容易一点点。
C++社群并不是为大规模设计和实现而组织的。C++社群中也没有什么传统或惯例。和其它社群相比，我们缺少一个“统帅”，他可以有效地激励新库的创建，否决或“保佑”我们的努力和成果。然而，我对“统帅模式”是否可行心里没底 — 除非你所做的事情只是基本的模仿而已。Boost（www.boost.org）是一个优秀的成果，它的某些方面已经超出了模仿的范畴，然而它仍然缺乏一个明确的目标以及用于维持自身发展的权威机构或权威人物。
在以下三个相关的领域中，大规模的合作努力对于C++社群而言是必需且有意义的：基本的并发编程库（包括线程、锁和lock-free算法等）；平台无关的操作系统服务库（目录和文件操纵以及套接字等）；以及GUI编程库。前两个看起来是可行的，但要想建立一个标准的GUI库，也许从技术上、经济上尤其是政治上都显得太困难了。
荣耀: 是的，我相信对于许多C++程序员而言，一个标准的GUI库是极其重要的。许多人以为GUI库不是一个太复杂的问题，但我却认为这可能是最棘手的问题。为了解决它，我们可能需要难以置信的大量的资源。同时我认为政治问题可能是其他问题的根源。举个例子，我们知道Windows的GUI风格和Java的GUI风格是不一样的，甚至不同版本的Windows的GUI风格也不一样。而且我们知道GUI风格很不稳定，它发展演化得非常快，而且很容易被微软这样的大公司所引导和操纵。
Bjarne: 在这个问题上，资源（包括财力和人力）是一个关键问题，与“保持设计蓝图的一致性”同样重要。另外，即使我们已经有了这三样东西：蓝图、人力（数打甚至更多）、以及财力（至少要担负得起一些优秀的人在这个项目上的全职工作），这仍然会是个需要N年才能完成的项目。而SUN、微软、苹果以及其他主要竞争对手将会做些什么呢？毕竟包含了一个工业强度的GUI库的ISO标准C++对于它们的专有系统可不啻一记重击啊！我的猜测是它们大多会通过强大的市场手段来保护既得利益，标准委员会可不是为了在这种市场环境中呼风唤雨而组织起来的，我们至少还需要一个工业社团的支持以及和开源社群主力军的联盟。
荣耀: 在您看来，C++要想继续向前发展，除了开发一个更为广泛、更具威力的库以外，我们还应该做些什么？
Bjarne: 我认为库方面的工作是关键。标准委员会没有足够的资源去创建一个全新的库，而且无论如何“让委员会设计”都不是个好主意。如果人们创建了新的库，在紧密相关的领域把它们的努力融合起来以达到冲突最小，并且文献记录良好（并非只记录细节，还有设计原则），那么他们也许可以把这些东西带到委员会来，并有希望让它们成为标准。如果没有成为标准的话，至少他们的努力有最大的机会成为“准”标准。有此打算的人应该把C++真正当作“C++”（使用继承、模板以及异常等）来看待，而不是从其它特性不是那么丰富的语言中抄袭设计而来。如果一个库的设计被发现没有用C++最佳地表达出来，那么它被接受为标准的几率微乎其微。
另一个可作贡献的领域是对技术的开发和推广。C++往往被以“很不理想”的方式使用着，MFC就是一个典型的例子，它甚至还达不到80年代中期对一个良好的OO设计的看法！我所说的“不理想”，是指没有达到它所能达到的可维护性的设计（通常这是由于对设计决策的糟糕的分解、低劣的封装以及对概念的拙劣表达而造成的），而并非指在外部压力下要尽快把项目赶出来的个体程序员或团队的“不理想”。通常，一个较好的设计和现有的实践是背道而驰的，后者往往需要立即付出代价（往往在很短时间内）。显然，任何显著的改进都需要在“一切照常”的基础上，并且至少追加学习所需的代价以及时间上的延迟。
这就把我们带到了最重要并且也许是最明显的改进实践的途径面前：教育。我们对编程和设计的教育必须比当前做得更好。新的语言特性、新技术以及新库碰到了不能理解并使用它们的人仍然是无用之刃。遗憾的是，我们恰恰缺乏优秀的C++入门书籍。Francis Glassborow的新书《You Can Do It》（译注：中文版《C++编程你也行》即将由人民邮电出版社出版）和Koenig & Moo的《Accelerated C++》是打破旧式而令人厌烦的教育方式的例子。那种教育方式把C++当作一个“稍微好一点的C”或者一门在实现“真正的面向对象”方面失败的语言。前者倾向于用一大堆语言技术细节来迷糊和恼怒读者，偏离了学习好的编程及设计技术的正确道路。后者通常除了存在这些问题之外，还没能够教会在性能攸关的领域里编程的必要技术，而且没有让人感受到静态类型系统的价值。尤其遗憾的是，Glassborow和Koenig & Moo的书的风格都不是编程入门教材的传统风格，这也阻碍了它们的广泛普及。
我自己的两本书《C++程序设计语言》和《C++语言的设计与演化》的目标读者则是已经知道如何去编程然而不知道如何使用C++的人。这两本书确实满足了这部分读者，但我们要做的还不止这些。
任何时候只要有可能，程序员都可以通过将程序的主要部分用ISO C++来写，并将系统依赖性封装起来，从而来支持标准。也就是说，把系统依赖性限定到特定的区域，并通过以标准C++表达的接口去访问它们。通常这并不容易做到，因为厂商总是怂恿程序员在代码中使用专有的、排他性的特性，但这就影响了可移植性，从而使程序移植到其他系统上非常困难。然而，站在应用构建者的立场来说，从长远来看，挣脱厂商的束缚、维持可移植性是一件好事，这种隔离系统依赖性的努力终将从经济和技术两方面都得到回报。
vector的连续空间分配算法及复杂度
Vector分配空间的策略是: 当vector空间满时, 在需要分配新空间以容纳新元素的情况下，将增加分配当前capacity的空间, 即vector的Capacity翻倍.
为什么这么设计呢? 原因是C++标准要求通过重复调用push_back而创建一个具有n个元素的vector耗费的时间不得超过O(n). 我们看看为什么这种方法可以达到要求。
假设现在需要给vector增加空间, 目前vector的capacity是N. 那么其中 N/2的数据，是没有经历过Copy的, N/4的数据的一半(N/8)是拷贝过两次的, N/8的数据的一半(N/16)的数据是拷贝过2次, N/16的数据的一半(N/32)的数据是拷贝过3次的, 依此类推:
Total_Move = N/2 * 1 + N/8 * 2 + N/32 * 3 + ... + N/(2^i + 1) * i
Lim(Total_move) = N.
因此, 使用新空间分配时倍增空间的方式，是可以达到内存拷贝复杂度为N的要求的。
另外一种每次给空间增加固定大小的方式，其复杂度是达不到要求的, 复杂度为o(N^2)级.
为什么这么设计呢? 原因是C++标准要求通过重复调用push_back而创建一个具有n个元素的vector耗费的时间不得超过O(n). 我们看看为什么这种方法可以达到要求。
假设现在需要给vector增加空间, 目前vector的capacity是N. 那么其中 N/2的数据，是没有经历过Copy的, N/4的数据的一半(N/8)是拷贝过两次的, N/8的数据的一半(N/16)的数据是拷贝过2次, N/16的数据的一半(N/32)的数据是拷贝过3次的, 依此类推:
Total_Move = N/2 * 1 + N/8 * 2 + N/32 * 3 + ... + N/(2^i + 1) * i
Lim(Total_move) = N.
因此, 使用新空间分配时倍增空间的方式，是可以达到内存拷贝复杂度为N的要求的。
另外一种每次给空间增加固定大小的方式，其复杂度是达不到要求的, 复杂度为o(N^2)级.
STL Map 无Reserve和Resize的原因 / Why STP MAP can not provide function Reserve() and Resize()
今天翻论坛,看到一些帖子问为什么STL Map不提供Reserve函数和Resize函数. 这个问题从MAP的实现比较容易理解.
MAP的低层实现是红黑树,要求每个节点都有一个不重复的key值. 如果提供Reserve和Resize功能，那么就要预分配一部分节点, 那么这些节点的key值设置成什么呢? 全为0不满足节点key不能重复的要求，又不能随即设置,因为那样会导致map根据key值重新排列. 所以MAP不可能可以提供Reserve和Resize的功能.
When reading bbs today, I found some ppl asking why STL map does not provide function Reserve() and Resize(). Considering this question from the technique machenism of STL MAP, the reason could be clear.
The low level data structure of STL map is RB Tree, it requires every node of it must have a unique key. If Reserver() and Resize() is provided, then the tree need pre-allocate some nodes. But how to initialize the key of this new nodes? If they were all filled zero, then the keys are repeated; If the are other random or different keys, it will cause a much more bad result: the tree need reassign the position of the nodes according to the keys.
So map must not provide function Reserver() and Resize().
MAP的低层实现是红黑树,要求每个节点都有一个不重复的key值. 如果提供Reserve和Resize功能，那么就要预分配一部分节点, 那么这些节点的key值设置成什么呢? 全为0不满足节点key不能重复的要求，又不能随即设置,因为那样会导致map根据key值重新排列. 所以MAP不可能可以提供Reserve和Resize的功能.
When reading bbs today, I found some ppl asking why STL map does not provide function Reserve() and Resize(). Considering this question from the technique machenism of STL MAP, the reason could be clear.
The low level data structure of STL map is RB Tree, it requires every node of it must have a unique key. If Reserver() and Resize() is provided, then the tree need pre-allocate some nodes. But how to initialize the key of this new nodes? If they were all filled zero, then the keys are repeated; If the are other random or different keys, it will cause a much more bad result: the tree need reassign the position of the nodes according to the keys.
So map must not provide function Reserver() and Resize().
订阅：
博文 (Atom)