以下是对部分读者朋友来信的答复与整理，希望能够发挥一些积极的作用。

前言

我于2003年6月底离开电力自动化研究院，调动到南京师范大学。陆续有读者朋友来信表示关心，问我原因。现正式回答如下：除了教书育人、努力成为大学生朋友的良师益友外，我希望过得更纯粹一些，更自主一些。在学校，我只负责教学和科研，不打算涉足管理之类的庶务。

“为人师表的感觉如何？” （读者朋友来信） 作为一名教师，我对自己的要求会更加严格，无论是技术本身，抑或是技术之外。

“在你的网站看到MIS课程目录，感觉进入中国传统教育的老套：理论多过实践、教条框框一大堆……”（读者朋友来信）。那是教学大纲要求。作为一名新任教师，我尊重（现有的）教学大纲和（现有的）教材以及授课对象。

对于教学大纲和教材无法跟上业界技术发展的问题，我不会发表什么负面看法 — 自有他人说闲话，不缺我一个。在此，我只给出正面解释：

写入大学教材的内容，往往都是经过验证的、达成共识的、已经成为一套理论体系的、完整的、成熟的东西 — 尽管有些东西“成熟”得已经成了“历史”。它们一般不会犯根本性的错误 — 至少摆在特定历史背景下来看如此。处于发展中的、前卫的、尚有争议性的东西，或许会出现于研究生（以上）教材之中，但短期来看，是不可能出现于大学生正式教材中的 — 假如给研究生教学，我甚至不需要教材 — 我想我找不到我想要的教材。

我相信，没有哪一位学生喜欢照本宣科的老师，也没有哪一位学生喜欢喜欢信口开河的老师。我不希望给“独立思维能力还不是那么强”的部分学生朋友造成恐慌和混乱 — 到底我是听你的，还是听教材的？

给学生授课，跟办培训班不一样，办培训班，和开研讨会又不一样。听课对象和演讲性质决定了我的讲解内容和方式。

我会在今后的教学实践中不断摸索，总结经验，尽快进入角色，并将这个角色扮演得出色，得到普遍认可。

此外，在我的第三张教学幻灯片上有如下文字：

序  言

将“日新月异”一词用于形容计算机技术的发展，是最贴切不过的了。管理信息系统这门应用性很强的学科和其它计算机基础理论课相比，发展变化得更快。开发工具、数据库、企业软件技术架构的更新速度甚至以月来计。同时，新的软件开发技术、思想也不断涌现：极限编程、敏捷开发、重构…… 不一而足，虽然缓慢 — 但也正逐渐被应用到MIS开发中去。在大型管理信息系统开发实践中，传统开发方法仍然居于支配性的地位，而新思想、新技术、新方法则在一定程度上丰富和发展了传统的开发方法。因此，在遵照大纲和教材的前提下，我也会视实际情况，适当简介一些最新的管理信息系统开发技术、思想以及来自项目一线的实践经验，但考核内容以大纲和教材为基准。

暂时不打算开放幻灯片。

C++的用场

Bjarne Stroustrup清晰地回答了这个问题。以下文字摘编自D&E简体中文版《C++语言的设计和演化》。

在以下领域，C++有着根本性的优势：低级系统程序设计、高级系统程序设计、嵌入式程序设计、数值科学计算、通用程序设计以及混合系统设计等等。让我们略微展开描述一下：

1.   低级系统程序设计：C++是迄今为止最好的低级程序设计语言。

2.   高级系统程序设计：包括操作系统核心、网络管理系统、编译系统、电子邮件系统、文字排版系统、图像和声音的编排系统、通讯系统、用户界面、数据库系统等等。

3.   嵌入式系统：包括照相机、汽车、火箭、电话交换机、汽车等等。

4.   数值/科学计算：包括仿真、实时数据获取和数据库访问等等。

Bjarne的个人主页上，有一页applications，那儿列出了一些（全部或大部分）使用C++编写的系统、应用程序和库。下面是一些例子：

1.   Adobe Systems：所有主要应用程序都使用C++开发而成，比如Photoshop & ImageReady、Illustrator和Acrobat等。

2.   Maya：知道“蜘蛛人”、“指环王”的电脑特技是使用什么软件做出来的吗？没错，就是Maya。

3.   Amazon.com：使用C++开发大型电子商务软件。

4.   Apple：部分重要“零件”采用C++编写而成。

5.   AT&T：美国最大的电讯技术提供商，主要产品采用C++开发。

6.   Google：Web搜索引擎采用C++编写。

7.   IBM：OS/400。

8.   Microsoft：以下产品主要采用C++（Visual C++）编写：

  Windows XP

  Windows NT：NT4、2000 

  Windows 9x：95、98、Me 

  Microsoft Office：Word、Excel、Access、PowerPoint、Outlook 

  Internet Explorer，包括Outlook Express 

  Visual Studio：Visual C++、Visual Basic、Visual FoxPro 

  .NET Framework类库采用C#编写，但C#编译器自身则使用C++编写而成。 

  Exchange 

  SQL Server 

  FrontPage 

  Project 

  所有游戏 

  ...... 

9.   KDE：K Desktop Environment（Linux）。

10.  Symbian OS：最流行的蜂窝电话OS之一。

我通常使用C++进行高端程序开发。

“通常”一词没什么好说的，有时只是出于公司文化或个人爱好方面的原因，选用了别的语言而不是C++，或者相反。我所说的“高端”是指：关键业务处理，效率要求极高，实时性要求高等等。

我看见几乎所有严肃的工控系统软件和实时数据采集、处理和表现（主要是图形）软件，都是采用C++（或C，少部分采用Java）编写而成的。

据我的了解，我原先所在的研究院几乎每一个研究所都在不同程度地使用C++（以及一些别的语言）。

想想看，迄今为止，现代Unix操作系统的各种变体上，最常使用的是什么开发语言？（C/C++） 

C++语言

C++语言是灵活，但首先要看看使用者能不能发挥它的灵活性；C++语言够强大，但要看看使用者有没有本事发挥它的强大功能。

使用C++语言和编译器编写一个快速的程序，并不难，不过编写一个强健而高效的大型程序，就不是那么容易了。

语言之间的区别，绝非只是大括号和begin、end或Sub、End Sub之间的区别。选择了一种语言，你就选择了一种思维方式，一种程序设计思想。要想跳出语言的束缚，首先要对语言有着深刻的认识和透彻的把握。世界上一些大师级的人物，也常常毫不掩饰自己对某种语言（我并没有专指C++）的偏爱。一些人对语言尚一知半解，就大谈要跳出语言的束缚了 — 你无需跳出，因为你根本不曾深入。

纯粹的技术性（学术性）研究，总能给人带来纯粹的快乐。C++语言复杂至极，可研究性极强，但一般来说，没有3~5年的持续学习、思考、使用，是不可能真正掌握C++的。

我不是唯语言论或唯工具论者，但我反对抹杀不同语言、不同开发工具之间的区别。抱持这种观点的人，若非无知，即是别有用心。这就好比杂牌笔记本电脑厂商最喜欢叫嚷“笔记本电脑已经进入同质时代”一样，杂牌机怎么能和“IBM”相比？

选择C++或选择Java，要看你个人爱好和对将来的打算。虽然只是语言上的差别，但由此决定的就业领域的确不一样。

不管你走什么样的技术路线，不管你用不用它做开发，学习C++总会带来长远的好处。一名熟悉C++的开发人员，假如他不是一个偏执狂的话，再学习Java或C#，都要容易得多。

C++不过是一门编程语言，我们总是要用它来解决实际问题，所以要学习开发工具（比如Visual C++），了解操作系统（比如API），熟悉领域知识（比如电力系统），掌握其他软件技术（比如数据库），等等。编写真正的代码，解决实际问题的能力，才是衡量一名程序员是否有真水平的唯一标准。

设计模式和统一建模语言

设计模式（Design Patterns）和统一建模语言（Unified Modeling Language，UML）是两个不同的概念。前者主要目标在于提供可重用的面向对象软件设计方案，后者则是一种描绘软件蓝图的标准语言。

当然了，可以使用UML来描述设计模式的结构。

UML所描述的模型可以映射成C++、C#、Java等语言代码，甚至可以映射到关系型数据库。映射过程可以是双向的，一般都有相应的软件工具（或插件）支持。

不同的语言，特性有所差别，这多少会影响设计模式在该语言中的实现（方式、难易）。比方说，假如使用C语言来描述设计模式，那么，继承、封装和多态等特性就变成了需要研究的设计模式，但在任何一门面向对象的语言中，这都纯属多余。

现在市面上还没有看到象样的以C#为手段讲述设计模式的书（我没有看到），但这并不打紧，倘若有兴趣，完全可以读一读《Design Patterns: Elements of Reusable Object-Oriented Software》（中文版名《设计模式》机械工业出版社）这本书，尽管它主要以C++和Smalltalk语言为讲解手段。

设计模式本身无所谓好坏，根据你要解决的目标问题，选择适当的设计模式。

系统架构

在企业级软件开发中，架构第一重要。架构有缺陷，系统就存在硬伤。优秀的架构来自于优秀的设计。这一点毋庸置疑。

任何成功的软件，即使它没有明确地使用建模思想、架构方法，但在骨子里、潜意识中，大都具有良好的设计思想和架构。

只有写过好多好多代码以后，只有做过一些够份量的企业级项目之后，才可能对软件架构形成清晰的认识。很难想像一个连几行像样的代码都没有写过的人，对程序思想和架构却有着深刻的认识。这种人，十有八九属于纸上谈兵之辈。

我们时不时会看到这种情况，软件的设计也不算太差，但程序员要么不知道怎么写实现代码，要么是代码写得缺乏效率，或不够强健，甚至有时连“架构师”自己对此都一筹莫展。

我们也常常听到一些声音，不要太拘泥于语言（技术）细节了，要从大处着眼，要有大局观，架构怎么怎么重要，这些都是大实话。不过现实情况往往是，很多程序员不是太拘泥于语言（技术）细节了，而是对语言（技术）细节掌握得还远远不够。

书本知识的重要性毋庸置疑，但绝不要以为读了两本书，自己就成了牛气的“架构师”、“设计师”或者什么“建模专家”。

从前的软件开发埋头实践而缺乏必要的理论指导。现在越来越走向另外一个极端：设计文稿越来越图文并茂，琳琅满目，但开发出来的软件却比以前差很多。这种表面文章，意义何在？

数据库

大多数软件都要和数据库打交道，并非只有MIS类软件如此，数据库知识几乎是非掌握不可的，无非使用深度和广度有别而已。迄今为止，我编写的每一个项目软件，都要访问数据库，有一个程序甚至同时要跟两个数据库打交道（Oracle和SQL Server）。

如果你上过任何一门“数据库基础理论”方面的课，或认真看过任何一本数据库基础理论方面的书，或许都不必再买更多的（类似的）书。二十多年以来，关系式数据库理论之稳定，远远超过C++语言的稳定:) 

SQL语法有标准，各种数据库又大都加入了自己的一些“方言”，但若通了一个，其它数据库的（基本）学用时间，可以小时计。

不过，不同的大型数据库的服务端编程技术，比如“存储过程”的语法，可能会有较大的区别。打一个不恰当的比方，有时语法差异之大，好比C++和Object Pascal之间的区别。

不是每一名程序员都需要熟练掌握数据库服务端编程技术的，要视其在开发团队中的角色而定。

MIS

MIS类软件开发门槛很低，要对自己有足够的信心（这么说，并不否认MIS类软件也讲究技术）。

学习任何一门语言，都要多看书、多思考、多写代码，一定要写几个正儿八经的、有些规模的软件，才可能真正掌握那种语言、开发工具，没有什么捷径可言。

大家都知道做项目软件辛苦，但项目软件的市场大，有钱赚，见效快，也不存在商品（产品）软件公司所头疼的盗版问题。目前在国内要将软件做成“产品”并实现“真正的商品化”，是极其困难的。这里原因很复杂，有技术层面的也有非技术层面的。但最主要的原因在于，做MIS本质上就是做业务，而实际上，没有任何两个组织的业务是相同的。从目前来看，即使提供了技术先进的MIS平台，也需要进行工作量可观的二次开发 — 假如想把业务做透的话。

开发一个MIS是不是很难，要看你的系统功能要求是不是很复杂。我参与的MIS都很复杂，要写好多好多代码。迄今为止，我很少使用数据感知控件（当然了，我并不反对别人使用数据感知控件）。以为单靠拖拽几个控件，设置几个属性，再补上几行代码，就可以轻松搞定一个数据库管理系统的，要么那个“系统”太低级，压根就算不上系统，要么那种开发工具太厉害，不是人类设计的 — 至少我没有见过。

尽管国内的确有公司、个人使用Visual C++进行实际MIS开发，但通常来说，除非有特别考虑，使用VC进行MIS开发，并非明智之选，至少目前（的VC）如此。

对于Windows上的MIS软件开发者来说，六年前，只凭FoxPro就可以打天下。四年前，开发人员发现，单单掌握VB、PB、Delphi这些开发工具还不够，至少还要学习一种大型数据库产品，比如Oracle、DB2、Sybase和SQL Server等。三年前，Windows DNA以及类似技术热火朝天，开发人员还要懂得如何编写COM组件，处理业务逻辑，甚至还要对付负载平衡、容错等问题。今天，.NET一下子带来这么多技术，开发人员必须学习许多新语言特性、至少部分框架类库以及五花八门的新概念，这甚至引起了相当一部分人的恐慌。怨天尤人是无济于事的，正确的做法是投入必要的时间，学习掌握.NET，因为它是Windows企业应用开发的未来。

技术学习

恐慌、迷惘和怀疑，往往都来自于新手。学了东西却不知道有没有用处，有什么用处，有多大用处，这种思潮在一些论坛的贴子上随处可见。

有些开发人员（我是指真正身处业界的某些开发人员，而不是指新手和学生），出于种种原因（有自身的，也有外在的，但归根结底是自身的原因），安于采用基本可行的技术完成编程任务，而忽视（或不愿意）学用更优雅、更高效的编程技术，这不是个好习惯。

同一个问题，可以采用效率低下、扩展性和维护性差的方式加以解决，也可以采用高效而优雅的方式解决，你倾向于哪一种？说得直白一点，编程高手和菜鸟的区别，往往也正在于此。高手编写的代码，常常会让菜鸟惊讶不已。

无论是学生朋友，还是一线开发人员，都不应该有“书读得足够多了”或者“读几本书就可以了”之类的糊涂念头。会有那么一天，当你打开另一本以为已经熟悉的书本时，却突然发现，有很多东西其实还陌生得很。

语言绝不是全部。任何一门语言，都有它能够发挥擅长的环境，都有它擅长解决的目标问题。单单学习语言本身是远远不够的，还要学习相关的库、相关的平台技术，说得更远一点，还要锻炼对目标问题的分析、归纳能力等等。

工作之前，技术路线自己作主，工作之后，绝大多数程序员将被公司技术路线左右。

业务知识（领域知识）

进入产业界，你总是从事某一个（或某几个）领域的软件开发（即便是Office这样的通用商品软件，也是有“领域”概念的，只不过这个“领域”范围广泛，不象“网络通讯”之类的领域来得那么集中），因此领域知识很重要 — 我们开发软件不就是为了解决该领域的问题的吗？

但是，领域知识是不可能在学生阶段学到位的，它更需要在工作中体会、思考、积累和磨练，也常常需要前辈帮、带。学生时代，是可以广泛涉猎、深入钻研“纯”技术的时间阶段，功底深厚的纯技术，是你应付任何领域问题的本钱。一旦进入业界，你就不得不将绝大部分时间和精力花费在特定领域问题之上。

对于软件开发来说，程序语言、开发工具（这两种东西往往搅和在一起）和领域知识同样重要。不过，客观地讲，业务知识一般要比技术本身容易学习一些，你甚至可以边做边学（当然了，若想成为一名领域业务专家，就不是朝夕之功了）。

一个初涉软件开发领域的新手不大懂得业务知识，比如说，电力行业的业务知识，这是可以理解的，但倘若不能比较自如地使用程序语言和开发工具，那就别扭了。

业务知识和经验可以成为一个人在某开发领域吃饭的本钱，但过硬的技术更是你纵横多种软件开发领域的利器。比如说，不做GIS又如何？你照样可以开发别的软件。

我并不是要否认业务知识的重要性 — 它非常重要。举个例子，一个MIS的实际效果不理想，往往并不是因为技术不够先进，而是因为没有在业务上做足功夫。

职业生涯

我无法为任何朋友谋划职业生涯。人是会变的，今天这么想，在现实的压力下（或诱惑下），明天可能又会产生相反的想法。

不过，一个人的性格是难以从根本上改变的，我相信“性格决定命运”。假如你认定自己只喜欢搞技术，不善于或不喜欢做技术之外的事情，那就应该努力寻求搞技术的环境。但不要一时兴起！三思而后行。我建议你的选择还是“中庸”一些比较稳妥。

同样，如果你对技术不感兴趣，那就好好练练你的技术之外的功夫。

一个人想法太多，希望太少，就会“惶惶不可终日”。或进或退，总得做出决断，方可从心理困境中解脱。

求职

我不是计算机科班（传统意义上的计算机专业）出身，我所认识的技术水准很高的朋友也大都不是科班出身，不必为自己的出身感到自卑。只要用心、用功，就一定会有所成。

说一个现实问题。用人单位在招聘时，通常会先看应聘对象的毕业院校和所学专业，可以想象有些朋友可能因此碰过壁。或许招聘单位的技术负责人还没有看到你的求职书，你就已经被“枪毙”掉了。有时的确不是个体（你，或者负责招聘的人）的错，现实社会评价体系就是这个样子。我建议，倘若自信（并且有可能的话），你完全可以直接到用人单位面谈。

面谈时不必过于感性，不要慷慨激昂，这无济于事，就谈你对技术的了解，并且有勇气、有能力参加用人单位的考试。

以能力服人，以技术服人。

可以做一份工整的个人简历，通过电子邮件方式多发给一些单位（使用google这样的搜索引擎就可以查到一些）。这种方式便捷，成本低廉，也符合软件开发公司的招人习惯。

面试非常重要。一旦有单位通知面试，在（针对该单位）做好技术准备的同时，一定要注意自己的着装、谈吐和行为举止等等。切记，程序员也是一个“社会人”！

给新手

大家懂的东西比你多，只是因为比你来得早。学习本来就是一个“从不知到知之”的过程，没有什么好自卑的。要想站稳脚跟，首先要学好和你当前职位相称的东西，一定要尽快熟悉公司的产品。

一名初涉软件开发行当的新手，往往会有两种心理：一是害怕，不知道自己究竟是否能胜任实际软件开发工作。二是过于自信，眼高手低。这都是不必要的。

不要害怕。不会就多下些功夫学习，不要羞于问身边的“高手”，他们大都热情，因为他们自己也都是从这个阶段过来的。不要过高估计自己，那样往往会跌跟头。

总之，不必自卑，别人只是先走了一步而已，只要用心、用功，你可以赶上并超过他们。

-完-