孟岩为什么退出且慢?

孟基轿备岩之所以退出且慢，因为战略分歧。

孟岩在2019年的时候，因为战略规划和投资人不合，离开了且慢，后来就创建了有知有行，曾经是程序员的他是个热爱生活同时活的通透的40岁+的大叔，据说孟岩的粉丝都害怕他哪天看破红尘出家了。

APP首页就搏毁可以看到大把的干货，可以说汇总了各路优质的文章以及成体系的教程，也有孟岩本人创作的文章和音频。不像一些APP大红大绿的，有知有行的UI设计真的太优秀了，看文章是很舒服的感觉。

人生经历

且慢不是一个独立的公司帆激，是盈米基金（珠海盈米基金销售有限公司）旗下的品牌。由于和盈米基金的管理层在公司整体战略发展上的分歧，盈米基金和孟岩协议决定孟岩离开盈米。

2015年11月，孟岩加盟盈米开始追寻自己的梦想。4年里，和所有伙伴们一起，孟岩始终站在用户一边，为用户创造价值，从0把且慢打造成行业知名品牌。孟岩联合优秀的主理人一起推出了长赢指数投资计划、极简投资、Earl二八轮动、绿巨人、价值五剑等优秀的策略，孟岩推荐过用户去其它平台买基金、也中肯的给出过战略配售基金的建议。

线性代数是什么？

在大学数学学科中，线性代数是最为抽象的一门课，从初等数学到线性代数的思维跨度比微积分和概率统计要大得多。很多人学过以后一直停留在知其然不知其所以然的阶段，若干年之后接触图形编程或机器学习等领域才发现线性代数的应用无处不在，但又苦于不能很好地理解和掌握。的确，多数人很容易理解初等数学的各种概念，函数、方程、数列一切都那么的自然，但是一进入线性代数的世界就好像来到了另一个陌生的世界，在各种奇怪的符号禅氏芦和运算里迷失了。

我在初接触线性代数的时候简直感觉这是一门天外飞仙的学科，一个疑问在我脑子里浮现出来：

如果看到这个问题，你的反应是“这还用问，数学当然是客观的自然规律了”，我一点儿都不觉得奇怪，我自己也曾这样认为。从中学的初等数学和初等物理一路走来，很少人去怀疑一门数学学科是不是自然规律，当我学习微积分、概率统计时也从来没有怀疑过，唯独线性代数让我产生了怀疑，因为它的各种符号和运算规则太抽象太奇怪，完全对应不到生活经验。所以，我还真要感谢线性代数，它引发了我去思考一门数学学科的本质。其实，不止是学生，包括很多数学老师都不清楚线性代数到底是什么、有什么用，不仅国内如此，在国外也是这样，国内的孟岩写过《理解矩阵》，国外的Sheldon Axler教授写过《线性代数应该这样学》，但都还没有从根本上讲清楚线性代数的来龙去脉。对于我自己来讲，读大学的时候没有学懂线性代数，反而是后来从编程的角度理解了它。很多人说数学好可以帮助编程，我恰好反过来了，对程序的理解帮助了我理解数学。

本文的目标读者是程序员，下面我就带各位做一次程序员在线性代数世界的深度历险！既然是程序员，在进入线性代数的领域之前，我们不妨先从考察一番程序世界，请思考这样一个问题：

为什么要问这样一个看起来很蠢的问题呢？因为它的答案显而易见，大家对天天使用的程序语言的认识一定胜过抽象的线性代数，很显然程序语言虽然包含了内在的逻辑，但它们本质上都是人为的设计。所有程序语言的共同性在于：建立了一套模型，定义了一套语法，并将每种语法映射到特定的语义。程序员和语言实现者之间遵守 语言契约：程序员保证代码符合语言的语法，编译器/解释器保证代码执行的结果符合语法相应的语义 。比如，C++规定用new A()语法在堆上构造对象A，你这样写了C++就必须保证相应的执行效果，在堆上分配内存并调用A的构造函数，否则就是编译器违背语言契约。

从应用的角度，我们能不能把线性代数视为一门程序语言呢？答案是肯定的，我们可以用语言契约作为标准来试试。假设你有一个图像，你想把它旋转60度，再沿x轴方向拉伸2倍；线性代数告诉你，“行！你按贺带我的语法构造一个矩阵，再按矩阵乘法规则去乘你的图像，我保证结果就是你想要的”。实际上，线性代数和SQL这样的DSL非常相似，下面来作一些类比：

所以，从应用的角度看， 线性代数是一种人为设计的领域特定语言(DSL) ，它建立了一套模型并通过符号系统完成语法和语义的映射。实际上，向量、矩阵、运算规则的语法和语义都是人为的设计，这和一门语言中的各种概念性质相同，它是一种创造，但是前提是必须满足语言契约。

为什么要有线性代数？

可能有人对把线性代数当成一门DSL不放心，我给你一个矩阵，你就把我的图形旋转了60度沿x轴拉伸了2倍，我总感觉不踏实啊，我都不知道你“底层”是怎么做！其实，这就像有的程序员用高级语言不踏实，觉得底层才是程序的本质，老是想知道这句话编译成汇编是什么样？那个 *** 作又分配了多少内存？别人在Shell里直接敲一个wget命令就能取下一个网页，他非要用C语言花几十分钟来写一堆代码才踏实。其实，所谓底层和上层只是一种习惯性的说法，并不是谁比谁更本质。 程序的编译和解释本质上是不同模型间的语义映射 ，通常情况下是高级语言映射为低级语言，但是完全也可以把方向反过来。Fabrice Bellard用JavaScript写了一个虚拟机，把Linux跑在JavaScript虚拟机上，这就是把机器模型往JavaScript模型上映射核闹。

建立新模型肯定依赖于现有的模型，但这是建模的手段而不是目的，任何一种新模型的目的都为了更简单地分析和解决某一类问题。线性代数在建立的时候，它的各种概念和运算规则依赖于初等数学的知识，但是一旦建立起来这层抽象模型之后，我们就 应该习惯于直接利用高层次的抽象模型去分析和解决问题 。说到线性代数是为了比初等数学更容易地分析和解决问题，下面我们通过一个例子来实际感受一下它的好处：

初等数学中三角形面积最著名的计算公式是area = 1/2 * base * height ，当三角形有一条边恰好在坐标轴上时我们就很容易算出它的面积。但是，假如同样一个三角形我们把坐标轴旋转一下，让它的边不在坐标轴上，怎么办？我们还能得到它的底和高吗？答案肯定是可以的，但是就明显复杂了，而且还要分很多种情况去分别讨论。

相反，如果我们用线性代数知识来解决这个问题就非常轻松。在线性代数中两个向量a，b的叉积(Cross Product)是一个向量，其方向与a，b垂直，其大小等于a，b构成的平行四边形的面积:

我们可以把三角形的边视为向量，所以三角形的面积等于两个边向量的叉积向量的长度除以二：

注：length表示取向量长度，cross_product表示两个向量的叉积。

这样一个在初等数学里面有点儿小难的问题在线性代数中瞬间搞定！可能有人会说，你直接基于叉积来做，当然简单了，但是叉积本身不是也挺复杂的吗？你把它展开试试看呢？是的， 模型的作用就是把一部分复杂性隐藏到模型中 ，使得模型的使用者可以更加简单地解决问题。曾经有人质疑C++太复杂，C++之父Bjarne Stroustrup这样回答：

在特定环境下，问题的复杂性是由其本质决定的，C++把一部分的复杂性纳入了语言和标准库，目的是使得应用程序更为简单。当然，并非所有场合C++都使得问题更加简单，但是从原理上讲，C++的复杂性是有道理的。除了C++，Java、SQL、CSS等各种语言和框架莫不如是，想象一下，如果不使用数据库，动不动就自己去做数据存储和管理是多么复杂啊！这样我们就不难理解为什么线性代数要定义叉积这样奇怪的运算了，它和C++把很多常用的算法和容器纳入STL是同一道理。同样的，甚至你还可以在线性代数中定义自己想要的运算拿来复用。所以，数学一点儿不死板，它和程序一样是活活泼泼的，你理解了它的来龙去脉就能驾驭自如。说到这里，我们就顺便回答一个很常见的疑惑：

其实，和程序复用一样，线性代数定义点积、叉积和矩阵运算是因为它们的应用非常广，有很大的复用价值，可以作为我们分析和解决问题的基础。比如，很多问题都涉及到一个向量到另一个向量的投影或是求两个向量的夹角，那么就会考虑专门定义点积(Dot Product)这个运算：

点积概念的提出属于设计，有发挥创造的余地；一旦设计定了，具体公式就不能随意发挥了，必须符合逻辑，保证它映射到初等数学模型的正确性。这就像一门高级语言可以定义很多概念，什么高阶函数、闭包等等，但是它必须保证映射到底层实现时在执行产生的效果符合其定义的规范。

线性代数好在哪里？

上面说了，线性代数是一种高层次抽象模型，我们可以采用学习一门程序语言的方法去学习它的语法和语义，但是这一认识不只针对线性代数，它是对每一门数学学科通用的，可能有人会有疑问

这就问到了根本上， 线性代数的核心：向量模型 。我们在初等数学中学习的坐标系属于笛卡尔所提出的解析模型，这个模型很有用，但同时也有很大的缺点。坐标系是人为加上的虚拟参考系，但是我们要解决的问题，比如求面积，图形旋转、拉伸等应用都是和坐标系无关的，建立一个虚拟的坐标系往往无助于解决问题，刚才三角形面积的例子就是这样。

向量模型很好地克服了解析模型的缺点，如果说解析模型代表了某种“绝对性”的世界观，那么向量模型就代表了某种“相对性”的世界观，我推荐把向量模型和解析模型看作对立的两种模型。

向量模型中定义了向量和标量的概念。向量具有大小和方向，满足线性组合法则；标量是只有大小没有方向的量（注：标量的另一种更深刻的定义是在旋转变换下保持不变的量）。 向量模型的优点之一是其坐标系无关性 ，也就是相对性，它在定义向量和运算规则的时候从一开始就抛开了坐标系的束缚，不管你坐标轴怎么旋转，我都能适应，向量的线性组合、内积、叉积、线性变换等等运算全部都是坐标系无关的。注意，所谓坐标系无关性不是说就没有坐标系了，还是有的，刚才三角形例子的顶点就是用坐标表示的，只是在解决问题的时候不同的坐标系不会构成影响。用一个比喻，Java号称平台无关，不是说Java就是空中楼阁，而是说你用Java编程时底层是Linux还是Windows往往对你没有影响。

向量模型有什么好处呢？除了刚才三角形面积问题是一个例子，下面我再举一个几何的例子：

这个问题如果是要从解析几何的角度去解决几乎复杂到没法下手，除非是平面恰好是过坐标轴的特殊情况，但是如果从向量模型考虑就很简单：根据平面方程，平面的法向量(Normal Vector)是v=(a, b, c)，设从平面上任意一点(x, y, z)到(x0, y0, z0)的向量为w，那么通过点积dot_product(w, v)算出w到v的投影向量p，其大小就是(x0, y0, z0)到平面a*x + b*y + c*z + d = 0的垂直距离。这里用到了向量模型的基本概念：法向量，投影向量，点积，整个问题解决过程简洁明快。

下面再给大家留一道相似的练习题（熟悉机器学习的朋友可能会发现这是线性代数在线性分类中的应用）：

离开向量，下面我们要请出线性代数的另一个主角：矩阵(Matrix)。

线性代数定义了矩阵和向量、矩阵和矩阵的乘法，运算规则很复杂，用来做什么也不清楚，很多初学者都不能很好地理解，可以说矩阵是学好线性代数的拦路虎。遇到复杂的东西，往往需要先避免一头陷入细节，先从整体上把握它。其实，从程序的角度看，无论形式多么奇怪，它无非是一种语法，语法必然对应了语义，所以理解矩阵的重点在于理解其语义。矩阵的语义不止一种，在不同的环境中有不同的语义，在同一环境中也可以有不同的解读，最常见的包括：1)表示一个线性变换；2)表示列向量或行向量的集合；3)表示子矩阵的集合。

矩阵作为一个整体对应的是线性变换语义：用矩阵A乘以一个向量v得到w，矩阵A就代表了v到w的线性变换。比如，如果想要把向量v0按逆时针方向旋转60度得到v'，只需要用旋转变换矩阵（Rotation Matrix)去乘v0就可以了。

除了旋转变换，拉伸变换也是一种常见的变换，比如，我们可以通过一个拉伸矩阵把向量沿x轴拉伸2倍（请试着自己给出拉伸矩阵的形式）。更重要的是，矩阵乘法有一个很好的性质：满足结合率，这就意味着 可以对线性变换进行叠加 。举个例子，我们可以把“沿逆时针旋转60度”的矩阵M和“沿x轴拉伸2倍”的矩阵N相乘，得到一个新矩阵T来代表“沿逆时针旋转60度并沿x轴拉伸2倍”。这是不是很像我们Shell中把多个命令通过管道进行叠加呢？

上面重点介绍了向量模型的坐标系无关性，除此之外， 向量模型的另一优点是它能描述线性关系 ，下面我们来看一个熟悉的Fibonacci数列的例子：

首先，我们构造两个向量v1=(f(n+1), f(n))和v2=(f(n+2), f(n+1))，根据Fibonacci数列性质，我们可以得到从v1到v2的递推变换矩阵：

并进一步得到：

这样就把线性递推问题转化为了矩阵的n次幂经典问题，在O（log n）时间复杂度内解决。除了线性递推数列，初等数学中著名的n元一次方程组问题也可以转化为矩阵和向量乘法形式更容易地解决。这个例子是想说明，凡是满足线性关系的系统都是向量模型的用武之地，我们往往可以把它转化为线性代数得到简洁高效的解决方案。

总结

本文提出了一种观点：从应用的角度，我们可以把线性代数视为一门特定领域的程序语言。线性代数在初等数学基础上建立了向量模型，定义了一套语法和语义，符合程序语言的语言契约。向量模型具有坐标系无关性和线性性，它是整个线性代数的核心，是解决线性空间问题的最佳模型。向量的概念、性质、关系、变换是掌握和运用线性代数的重点。

程序员》推荐C++ 图书三人谈

主持人：熊节（透明），《程序员》杂志编辑，C-View成员

嘉 宾：孟岩（梦魇）,联想公司掌上设备事业部应用开发处任职，C-View成员。与侯捷先生合译《C++ Standard Library》一书

金尹（恶魔），上海天宇公司CTO，在《程序员》连载有圆丛做“自由与繁荣的国度”系列文章

透明：“学C++用哪本书入门”，这是被问得最多的一个问题。但是哪一本书是最好的入门书？似乎很难找到答案。《C++ Primer》太厚，《Effective C++》对读者要求比较高，《Essential C++》又常常被批评为“太浅”。

其实说穿了：no silver bullet。想从一本书学会C++，那是不可能的。有朋友问我如何学C++，我会建议他先去找本数据结构书，把里面的习题全部用C++做一遍，然后再去看《Effective C++》。myan经常说“要在学习初期养成好习惯”，我对此颇不以为然。

个人认为，《Essential C++》适合作教材，《C++ Primer》适合作参考书，《Effective C++》适合作课外读物。

恶魔：很后悔当初买了《C++ Primer》。因为从我个人角度来看，它的功能效用基本是和《The C++ Programming Language》重合。当然对于入门来说，它还是很不错的。但是《C++ Primer》太厚，一来导致看书极其不方便，二来系统学习需要花比较长的时间。对于目前这个越来越快餐化的时代来说，的确有很多不适合的地方，不过可以作为初学者的参考书。现在我以一块K3 CPU的代价把它借给了别人，希望我那位同事能够从中得到一些益处。

如果已经具备了C基础，我建议看国内的书，例如钱能的《 C++大学教程（第二版） 》。(如果没有C的基础还是看谭浩强的C语言)。这本书对C讲得还算比较清晰，有很多习题值得一做，特别是最后的struct和union两个部分。其中的一些算法比较拖沓和繁琐（比如树和链表的遍历算法），读者可以尝试修改这些例子，作为最后对C语言的一些总结测试。

梦魇：这个问题让我想起四五年前的情形。今天对于橘衡C++有一点认识的人，多半是从那几年就开始学C++了。那时根本没有品牌观念。从书店里找一本C++书，如果看着还算明白，就买下来。我记得那时候宛延闿、张国锋、麦中凡教授的书都受到很高的赞誉。我个人最早的一本C++书是Greg Perry的一本书，今天想起来，其实是一本打着C++旗号的C语言教程。对我作用最大的一本书是国防科技出版社出版的一本书，书名记不得了，作者叫斯蒂芬·布莱哈。

透明：还记得以前曾批评过一本C++书，是北航出的，整本书就没有出现过class关键字。那本书，说穿了其实只是介绍了C语言和iostream库的用法，根本不能算C++。而当时我常常推荐的一本书是电子科技大学张松梅老师的C++教程。那本书，直到今天来看也没有太大的问题，唯一的缺憾就是由于年代久远，许多东西已经过时了。而对于一本技术书籍来说，“过时”是最不可接受的。

总体来说，那时使用C++的人真是在“盲人摸象”。不过这也有好处，就是对C++的很多细节能搞清楚，以后看到经典好书时比较容易理解；当然坏处就是概念不清，甚至都不知道C++和Visual C++、Borland C++到底有什么不一样。

梦魇：整个90年代，其实大部分人对于C++的认识都似是而非。一开始是等同于Borland C++，后来是等同于Visual C++和MFC。所以一般来说，打着BC和VC旗号的书卖得很好，人们觉得这就是C++。而我比较幸运，布莱哈的那本书虽然从现在的眼光来看谈不上高超，但基本路子是对的。可能是因为原书是给UNIX程序员的培训教材，所以没有让我一开始就形成“C++ == VC++”的认识。

其实一直到1996年，我们那里搞计算机的都是唯Borland C++马首是瞻的，到了VC 4.0出来，一下子格局全变了。1997年VC5推出之后，书店里MFC书铺天盖地，学MFC的人，头抬得都比别人高一些。不过现在看来，那时候大部分的MFC书都是三流货色。我曾经有一段时间认为，那一批程序员中间有不少被误导了。根本原因就是相对的封闭。

透明：我觉得一本书的价值有两方面：第一，教给你实用的技术；第二，促使你去思考。对于一本介绍VC（郑搭或者说MFC）使用方法的书，我根本不希望它能促使我有什么思考，所以我就一定要求它在技术上精益求精完美无瑕。我刚开始用VC的时候，买的第一本书就是潘爱民老师翻译的《VC技术内幕》（第四版），没有受到那些“三流货色”的误导，应该说是很幸运的。

梦魇：1999年机械工业出版社开始出版“计算机科学丛书”，其中的《Thinking in C++》第一版受到了广泛的欢迎。其实我一直不认为这本书很出色，虽然拿过一次大奖。然而我们都得承认，这本书在C++书籍领域里第一次建立了品牌观念，很多初学者开始知道，不是随便买哪一本都一样的。再往后就是2000年的《 深入浅出MFC（第二版） 》第二版，以及侯先生在《程序员》上发表的那一篇《C++/OOP大系》，加上整个大环境的变化，品牌观念深入人心，C++书籍市场终于开始逐渐与世界同步。

回想往事，我的感觉是，那个需要战战兢兢选择入门书的时代已经过去，今天的C++初学者，大可以放心地买口碑好、自己读起来思路顺畅的书，入门不再是太大的问题。还有一些程序员已经学了几年C++，但看到今天出版的一些新书，感觉比较陌生，这也不是什么问题。侯先生经常说“凡走过必留下足迹”，所谓“走弯路”，未必不是一件好事。

至于具体的推荐表，就不好一概而论了。总之在我的印象里，《Essential C++》、《C++ Primer》、钱能教授的C++教程，都不错。甚至有人一上来就看Bjarne Stroustrup的《The C++ Programming Language》，只要他喜欢，也没什么不可以。

透明：我同意你的观点。不管怎么说，编程是门实践性非常强的学问。要想对C++对象模型有深入的了解，最好的办法就是写一串程序去看结果；要想学会OOP，也只能从项目中学。对于初学者，最好的学习方法就是不停地写程序，写真正有用的程序，写到有问题的时候就去查书，于是自然就会知道哪本书好哪本书不好。不过我们的教育制度能不能让大学里的学生们有这样的学习机会，我表示怀疑。

以我的经验，学C++有两个门槛：入门和使用。完全看不懂C++，这是一个门槛，但是只要有一本合适的入门书，很快就能跨过。要想真正用上C++，却不是件很容易的事情。尤其对于学生来说，接触到的东西多是“玩具”，很难有实战的机会。所以经常看见有人问“C++到底能做什么”，这是C++学习中一个比较麻烦的问题。我们都是做了相当长时间的C++程序之后才看到一些真正经典的书，也正是因为走了相当长的弯路之后才知道这些书的经典之所在。所谓弯路，我想也是一种必须的积累。就算一开始就看《Essential C++》和《C++ Primer》，没有两三年的时间恐怕还是难有所得。

恶魔：有两句十分有道理的话，一是我大学的C语言老师说的“写程序不如说是抄程序”，另一句是一网友说的“好的设计来自借鉴，天才的设计来自剽窃”。对于我这个理性批判主义者来说，这两句话的确不太适合。但是无论从哪个角度来讲，对于初学者来说，剽窃大师的作品是通向成功的最快捷径。

我个人认为，对于C++的初学者来说，首先要确定自己专业领域内主要使用的特性的方向。因为C++的特性如此众多，初学者想贪多基本是不可能成功的。C++的编程范式基本可以分为ADT+PP、GP和OO三个方向。对于ADT+PP范式来说，初学者的主要问题不是学习C++，而是学习C的使用。对于这样的初学者，国内的几本书还是写得比较清楚，符合中国人的习惯，比如谭浩强的《C语言教程》、钱能的《C++语言大学教程》。这两本书我首推第一本，因为这一本我潜心研究了一年，这本书当中很多程序是可以剽窃的，而且可以对这些程序进行加工和提升。比如结构这一章中，它所给出的用struct来实现链表、二叉树的算法是相当蹩脚的。学习ADT+PP的初学者将这本书揣摩透以后可以尝试修改这两个程序。另外这本书的第二版稍微涉及了一些关于“类”的内容。学习ADT+PP的初学者，可以不被OO中的一些专有特性扰乱自己的思路，对于类层次扁平、无继承、无多态的程序编写是有很大好处的。

透明：你好象比较推崇国内教授写的书。现在社会上有种不好的风气：一捧就捧上天，一贬就贬下地。就好象对待谭教授的书，前几年是奉为经典，这几年又有很多人使劲批评。学C++更是有点“崇洋媚外”，总是觉得初学就应该看《Essential C++》。我看这种观点也是片面的。

恶魔：当然《Essential C++》也值得看看。但是我个人觉得这本书没有谭浩强的《C语言教程》来得好。主要原因是：第一，C++的所有特性都点到了，但是不深，看了以后会三心二意没有方向；第二，可以抄袭借鉴的例子太少。《C语言教程》中有很多有趣的问题，比如猴子吃桃、汉诺塔等等，这些例子对于刚刚涉及C/C++语言编程的人来说是学习编程很好的例子。《Essential C++》只能是前两本书看透以后，作为学习C++特性的一个过渡性的书籍。让读者真正领略到什么是C++的编程、和C编程的不同点在哪里。

透明：我发现一个很有趣的现象：初学者往往喜欢问“哪本书比较好”，这让我很是不解。这有点像一个刚学打篮球的人问“王治郅和科比谁比较厉害”。当然科比更厉害一些。但如果你是想学打篮球，这两个人都非常非常有资格教你，你跟谁学都能学得很强——关键不是在于你选哪个老师，而是在于你自己用多少功夫去学。

透明：回到原来话题。学会了C++的语法，能看懂C++代码之后，必须有些书来指导进阶（或者叫指点迷津）。我觉得《设计模式》很好，能够让读者看到一些精妙的用法。不过正如我经常说的，模式带来的麻烦和好处一样多，甚至麻烦还要更多。而且，C++本身的问题使得在C++中使用GoF模式愈加麻烦。

梦魇：《Design Patterns》这本书绝对是不可以没有的，而且中英文版都不可少。最初我看中文版，说实话看不懂，但是也不觉得人家翻译得不好，所以就想，大概是原文就很难懂，加上自己水平有限。于是总是想着再找几本patterns的书来看。后来找到几本书，口碑还不错，不过水平高下，一比就出来了，还是那本《Design Patterns》最经典，最耐看。英文版出来之后，两个版本对照看，明白多了。现在觉得，其实就设计模式来讲，把这本看明白了就很不错了，不用再花费很多心思找其他的书。我现在的包里始终夹着这本书，随身携带，有备无患。

至于说设计模式的副作用，和可能带来的弊端，我的体会也挺多。不过是这样，我们想一想，究竟什么情况下设计模式可以用得很好呢？一种是有经验丰富的人引导，比如要是Robert Martin带队，你在某个地方用错了设计模式，他就会指出来，说这里不对，将来会产生什么样的弊端。对于他来说，丰富的实践经验足以支持他进行“预测型”设计。但是大部分人没这个能力，因此我们只好走第二条路和第三条路，就是“试探型”设计和“重构型”设计。遇到一个问题，你觉得用某种模式挺合适的，就大胆地用了，成功是积累经验，发现不好，出了问题了，只好改回来，那也是积累教训。这叫做“试探型”。至于重构，应该算是最有组织、成功率最高的工程化方法。先把问题“quick and dirty”地解决了，所有的暗礁都暴露出来，然后再根据实际情况采用合适的模式优化设计。现在XP和UP都高度重视refactory，UP在Elaboration和Construction阶段都鼓励抽出专门的iterations进行重构。所以说如果组织快速的软件开发，当然比较倾向于这条路——打成功率嘛。

透明：讲到重构，我顺便说说《Refactoring》这本书的影响。从工程本身的角度来说，你所谓的“重构型设计”是没有什么问题的。但中国的开发者（也包括我在内）往往比较冲动，比较容易相信银d的存在。曾经有那么一段时间，我在Java中尝试过了重构的方法之后，又拿到C++中去尝试。结果发现，在Java中速度非常快的重构过程，到C++中就被减慢了。究其原因，就是因为C++和Java的约束条件不同。拿着Java中成功的案例直接套C++，不失败才怪。

所以，我必须说：《Refactoring》这本书很有价值。但对于C++程序员来说，它的价值是让你思考，思考这种方法的可行性。如果一个C++程序员没有打算迁移到Java，那么我必须告诉他：《Refactoring》这本书不是让你照着它用的，甚至不是让你去相信它的。对于C++程序员，《Refactoring》全书可以放心相信的只有第13章，其他的部分，都必须非常谨慎地对待。

梦魇：我还要就“试探型”的方法多说两句，我觉得对于个人发展来讲，“试探”也是必不可少的，撞墙不可怕，高水平的人不都是撞出来的吗？你失败了一次，就知道这个模式有什么潜在的问题，下次再用，就会多看几步，像下棋似的。撞的多了，路数就出来了。

我不知道你们是否有这个感觉：用错了模式，吃了亏，再回过头去翻翻《Design Patterns》，看到人家早就指出来这个问题，不过就是那么几句话，原来看上去干巴巴的，现在觉得句句都讲到心坎上，GoF的形象马上就高大起来，还带着光环，感觉是既兴奋又懊悔。

透明：现在回头来看，我更欣赏myan推荐给我的《Designing Object-Oriented C++ Applications Using Booch Method》。这本书能够帮助C++程序员理清思路培养习惯，可惜国内没有引进。相比后来商业味浓厚的UML系列书籍，我觉得这本书对于面向对象的阐释精辟独到，至今未有能出其右者。

梦魇：刚才我们两人都说到Robert Martin，他可是我的榜样。那本1995年的《Designing Object Oriented C++ Application》，我觉得是每一个C++软件工程师都应该反复研读的书。可惜不仅国内没有引进，在国外的名气也不大。如果你觉得面向对象的那些道理你好像都明白，可就是一遇到实际问题就使不上劲，那这本书就是你的最佳导师。

提到理清思路，还有一本书不得不提，就是Andrew Koenig的《Ruminations On C++》。每个人都应该问自己，我学了这么多年的C++，究竟什么是C++最基本的设计理念？遇到问题我第一个直觉是什么？第一个试探型的解决方案应该具有那些特点？如果你不能给出明确的答案，就应该认真地去读这本书，读完了你就有了“主心骨”。

透明：插一句话，谈谈“推荐书”的问题。入门书基本上是放之四海而皆准的，所以推荐的意义也不大。而入门后的发展方向，每个人不同，这个时候就需要“高人”的指点。举个例子：我学C++的时候，myan还不认识我，所以也没有给我推荐书，我还是学过来了，所以即使你当时向我推荐了《Essential C++》或者《C++ Primer》，我也不会太感谢你；但在我认真研究OO的时候，你推荐Robert Martin那本书给我，对我帮助就特别大，而且我从别的地方也很难找到类似的推荐，所以我就很感谢你。

一个程序员，必须有framework的意识，要学会用framework，还要主动去分析framework（在这方面，《Design Patterns》能有一定的帮助）。但是，真正高质量、成气候的framework的书恐怕也就只有针对MFC的。从这个角度来说，MFC纵有千般不是，C++程序员都非常有必要先去用它、熟悉它、研究它，甚至借助《深入浅出MFC》这样的书来剖析它。不然，很难有framework的意识和感觉。

当然，另一个framework也很好，那就是STL。不管用不用MFC、STL，对这两个东西的掌握和理解都是极有帮助的。最近我又在看《深入浅出MFC》，虽然已经不用MFC编程了，但帮助是一定有的。

梦魇：MFC和STL方面，我还是比较推崇侯先生的两本书《深入浅出MFC》和《STL源码解析》。

《深入浅出MFC》这本书，名气自然是大得不得了，不过也有不少人批评。其实书也没有十全十美的，批评当然是少不了的，不过有的时候我看到有人评论这本书，把它跟Inside VC相比，真的是牛头不对马嘴。

你刚才其实说得很对，程序员应该有一点framework意识。而这本《深入浅出MFC》与其说是在讲MFC编程，不如说通篇是在拿MFC为例分析Application Framework的架构和脉络。所以无论你对于MFC本身是什么态度，这本书对每一个C++程序员都有很大的益处。

透明：是的。《VC技术内幕》会告诉你“DYNAMIC_CREATE这个宏怎么用”，《深入浅出MFC》则告诉你“DYNAMIC_CREATE这个宏是怎么实现的”。所以，如果你只需要在VC下写一些小应用程序，《深入浅出MFC》的价值并不太大；但是，如果你需要设计一个稍微大一点的东西（不一定是framework），MFC的设计思想就会有所帮助。

梦魇：另外，我觉得对于MFC也应该有一个公允的评价。过去是吹捧得天上有地下无，书店里铺天盖地都是MFC的书，搞得大家只知有MFC，不知有C++，甚至直到现在还有人问：“我是学MFC呢，还是学C++？VC++是不是比C++更高级的语言？”MFC成了一尊神像，阻碍了人们的视线。所以得把它从神坛上拉下来。这就是过去一两年有很多人，包括我在内批评MFC的一个目的。可是现在大家视野开阔了，.NET也出来了，MFC不再是神像了，少数人就开始以贬损MFC为乐了。我觉得这种态度是不对的。

什么叫好的框架？我觉得在十几年的时间能够象MFC这样保持稳定并且不断进步的框架就是好的框架。可能我们在一些具体的设计问题上有不同看法，觉得“这个地方这么设计不是更漂亮吗？”很多时候是的，但是这不重要，重要的是MFC成熟稳定、有十几年的成功经验，这是最了不起的东西。

另外一点，MFC中间包括着学习Win32 API编程的最佳资料。这是除了其framework方面之外的另一个亮点。我现在使用Win32 API开发，但是经常参考MFC的源代码，收获很大。

透明：STL方面，我对于剖析它的源代码兴趣并不大，毕竟里面源代码多是算法问题。所以，《STL源码剖析》我也只是随便翻翻就束之高阁了。我觉得这本书用来做计算机系的数据结构和算法教材不错，不知道有没有老师乐意这样做。

对于STL，我的态度一向都是“应用至上”。不过，我一直认为SGI STL本身就是一本精彩的书，一本数据结构和算法的经典参考书，同时也是泛型技术的参考书。想知道一个算法是如何实现的，看看STL源代码就行；想知道如何使用type traits，STL源代码里面也有例子。看别人写的书，总觉得隔着一层纱，有点挠不到痒处的感觉。SGI STL的代码写得非常漂亮，一个C++程序员如果不看看这本书，实在是可惜。

梦魇：至于STL，除了《STL源码解析》之外，我举贤不避亲，强烈推荐侯先生与我合译的那本《The C++ Standard Library》。这本书质量之高是无需怀疑的。我现在手边常备此书，随时查阅，对我帮助很大。

透明：C++和Java相比，最大的优势就是它没有一个专门的公司来管它，最大的弱点也是它没有一个专门的公司来管它。Java程序员在学会简单的语法之后，立刻进入SUN提供的framework，一边用这个现成的framework做实际开发，一边在开发过程中继续学习Java一些幽深的特性。而这个时候，C++程序员恐怕还在问“VC和BCB哪个好”呢。这无疑是浪费时间。

梦魇：刚才你说Java和C++的优劣，这个话题已经成了我们这个年代永不消失的声波了。我也不想再谈这个。不过有一点我得说清楚：现在我们很多用C++的人吃了不少苦头，探过脖子去看看Java，觉得它真是太可爱了，这种印象是不准确的。另外，Java也不简单，而且会越来越庞大复杂。在很多场合，Java还不具有竞争力。至于将来如何，我看有些Java爱好者也过分乐观了，似乎计算机科学界几十年解决不了的问题都可以借着Java的东风解决掉，恐怕没那么容易。

透明：那当然。我再次强调：No Silver Bullet。读书很重要，但古人说“行万里路，读万卷书”，还是把“行路”放在“读书”前面。尤其对于技术书籍，如果它不能帮我解决问题、不能给我带来非常实际的利益，那么我是不会去读它的。恶魔说得对，我们这个社会很快餐，我们这个行业尤其很快餐，我们也只能努力适应它。

---