技术学习点滴

>>>  名人論史——近當代作家的史學觀點  >>> 簡體     傳統

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

前言

我于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这样的搜索引擎就可以查到一些)。这种方式便捷,成本低廉,也符合软件开发公司的招人习惯。

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

给新手

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

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

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

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

-完- 


轉載 2011-02-22 03:17:47

[新一篇] 2011:我們往哪里去?

[舊一篇] 從星空到心靈——易中天于丹演講對話錄
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表