回 帖 发 新 帖 刷新版面

主题:转载->"对VC的批判”->高手来评论一下这小子说的!

一家之言,VC高手不妨过来指点指点,没有人骂我,我不高兴

                               作  者:bitfan ()

注:以下的观点主要指VC6。)

1.       背景我这人喜欢偷懒,VC我断断续续学过很长的时间,最终没有能成为我想成为的那种高手,在“程序人生”中的一个贴子《怎样克服学习过程中的浮躁,来者有分》

(http://www.csdn.net/expert/topic/635/635462.xml?temp=.8159601)中我看到有很多人都说VC难学,信然!拿我来说,最终真正派上用场的还是VB和C++Bulder之类RAD开发工具。 我在想,为什么大家都在说VC难学,却又想学,许多人是不是都象我刚学VC一样,人云VC如何如何,就去学VC了,但水平与能力有限,只能成为半罐子水,花钱不少,花时间不少,花精力不少,代价更不少,却没得到什么…… 为什么大家都要“明知山有虎,偏向虎山行”?特别是许多准备进入软件开发这一行业的,用过自已的大脑仔细想过为什么要学VC吗? 我的观点要打击大家学VC的积极性了……

2.为什么用VC干活的人工资高?我认为学VC可以对一个程序员的基本功做出最痛苦的锻炼,所以经过VC苦练的人大都是金刚不坏之身,再学其它的东西就感到游刃有余了。通过VC成为高手者自然人少,以VC之难能成为高手者自然能力超群, 牛人自然工资高,这有什么奇怪的?他们付出了更多罢了。

3.不学VC的最主要理由:技术进步!不知诸位正在学VC的想没想过技术进步这个因素?如果你学VC是为了有个收入高的好工作,那么我认为你还是别学好。现在.net已经推出,编程平台的转移是必然的,这个周期大约就在两三年之内。 VC6的核心就是两大类库:MFC和ATL,前者是基于win32 API的一种FrameWork,后者是开发COM组件的类库,两者开发的是传统的Windows应用程序,学VC不学MFC,不学ATL几乎可以说没学VC!但遗憾的是学VC的人没有几个不为MFC中那些复杂的类之间的关系,那些奇怪的代码而头痛,ATL也好不到哪去,如果你事先没系统地学习COM理论,用ATL来发基于COM的组件几乎是不可能的。事实上,MFC框架就是一种设计模式,只不过微软的开发人员将其设计得非常完善罢了。那本著名的《设计模式》经典书中就介绍了23种设计模式,其中介绍的MVC模型几乎就是MFC的精髓!用MFC开发软件,你就必须遵循它的思路,你所做的工作就是在这个框架上修修补补,(当然,这个框架做Windows界面还是非常完善的,几乎考虑到了程序对界面的所有需求),但我觉得强迫别人按照一个框架去解决问题这是对人的一种束缚!可悲的是还有那么多人沾沾自喜于此!我常用C++ Builder,我知道VC的高手对这类RAD心存蔑视,但我也知道我在C++Builder中可以非常方便地从头开始应用一种设计模式,而不用费心地考虑如何将我这种设计模式嵌入到某个框架之中(当然我也可以设计出很复杂的应用多种设计模式的程序框架,C++Builder把这个工作留给了程序员自已);同样的工作,对于一个对VC不熟的人,自建若干个新类,再将其引入到MFC中不是一件简单的事,其主要原因就是MFC的复杂性。C++Builder中只需新建若干个Unit,然后写你的类,再在窗体上加一个接钮,包含上新类的头文件,new一个对象就可以用了,对于初学者而言,你说哪种解决问题的方法更直观,从程序设计的角度,哪一个效率更高?

4.从微软的策略看VC的前途!微软的策略是先用.net提供一个新的环境,然后逐步修改其OS,最终完全抛弃NT内核,其最终目的是抢占被UNIX和LINUX占据的高端市场份额(这是Borland李维说的,我觉得有道理)。现在推出的.net框架还支持原来的技术(如COM+),VC.net中也还有MFC7,但这只是一个过渡时期的产品,就象Windows 3.1被Windows 95取代一样,最终是要被抛弃的。很明显,软件发展的趋势就是不断提高软件开发的效率,在.net中开发程序绝不会有现在VC6中用MFC这样复杂和繁琐,事实上,新的平台已不再有win32 API这种平面型的开发接口,已全面立体化(类似于在C++的类库,使用方式也与C++中类的使用方式类似),而且应用程序又回到了DOS时代的简洁,只需复制整个文件夹,就可以移动一个应用程序,程序是自说明的,注册表也没有了,意味着基于注册表的COM组件技术也将被取代。这一切的变化周期估计就在两三年之内。

5.现实的考虑:诸位想想:如果你花一到两年的时间去学VC6,尤其是MFC,就算你到时是VC的绝顶高手,你却空有屠龙之技而无龙可屠,岂不悲哉!想想如果有一个DOS时代的高手跨越时空来到现在,他的技术早已被时代所淹没,如果不更新知识,他会发现要找到一个饭碗都不容易。对于所有想学VC的人,我提出一个忠告:VC的巅峰期已过。 那现在为什么还有那么多公司想要招VC的程序员?有很大的原因是对过去资源的继承。过去的投资不能白费,这还用说吗?

6.如果你打算学VC,请端正你的目的!现在学VC的目的不是为了好找工作,好拿高薪,而是因为它的复杂是锻炼一个优秀程序员的最佳方法,就象奥运长跑选手为了提高身体素质而到高原上训练一样。对于想进入软件开发大门的人我的建议是直接学习最新的技术,而且最好是现在学习今后一到两年内会成为主流的技术,而那些有志于成为windows软件高手的人,VC是必修课,不经百炼哪能成钢?而且VC肯定还会生存很长一段时间,就象现在还有用Foxpro开发的系统一样.

7.我学软件喜新厌旧:对于象我这样的平庸之辈,我脚踏N只船:最早以VB入门,从3.0用到6.0,它给我带来的收获也最多;VC我是半桶水,学了一两年就没一点成就感;C++Builder是我的爱将,是我学习C++和各种软件理论最常用的开发工具,用它也做了不少东东;真的不错,准备娶过门来了;我还对Java心存向往,很想马上去学,不过个人能力有限,还是放一放罢…… 掌握多种开发工具有一个好处,那就是可以取长补短。比如有一个图象处理程序用VC开发,而其中的报表部分我则用C++Builder做出来,再以COM组件的方式给VC调;要操作Office我喜欢用VB,要写多层系统访问数据库我喜欢用C++Builder(现在还加上Delphi),所有这些都可以在COM的基础上统一起来…… 不过COM也快完蛋了,我也要学新的东东了,可惜了我买了那么多COM的书……对了,还要加一句,对COM了解即可,别钻进牛角尖里去了,COM又是一个无底洞,也许日后再发个贴子,就叫"对COM的批判"



谢谢horris(僧推月下门)的高论。 我想就horris贴子中涉及到的几个方面谈谈看法。

1)程序框架和设计模式: 程序框架的设计体现出设计模式理论,可以看成是一个未完成的系统,程序员在这个框架之上加入实际工作的代码而形成真实的系统。而这两者的出现与广泛应用是软件开发走向成熟的必然。 为什么要提出设计模式理论和应用程序框架?很简单,就是要提高软件产品的质量和生产率。 现在主流的开发工具中都有程序框架的应用,最典型的是MFC和VCL。那么,衡量一个框架好坏的标准是什么?我可以列出几条,但我可以肯定地指出,框架的可复用性是第一位的,而易用性是第二位的,运行效率则是第三位的。就可复用性而言,MFC和VCL难分高下,而易用性则差别巨大,我就不详细说了。    

2)“运行效率”vs“开发效率”; 运行效率和开发效率这两者谁更重要? 除非是开发实时系统和某些系统核心模块(这种模块在整个项目只占很小比例),大多数软件项目考虑的是开发效率和一些其它因素,对运行效率则要求不高。 所以,象开发效率、稳定性、易用性、易维护、可扩展等就成为首要考虑的因素,而运行效率则是在保证达到前面要求的前提下再去考虑的。 另外,是否VC做出来的东西就一定好和快呢?这取决于系统设计和程序员对语言和工具的把握程度。 举个例子: 在程序设计过程中,都要对系统功能进行封装。假设系统中要将ADO RecordSet封装成一个适合特定用途的数据存取类,用VC封装工作量是C++BUILDER的好几倍(因为C++BUILDER中有一个现成的类TADODataSet封装了ADO RecordSet,基于TADODataSet自然要少很多工作),除了少数VC高手,绝大多数人用VC实现的封装都无法与用TADODataSet的封装相比拟,为什么?很简单,你对原生的ADO RecordSet的封装达不到TADODataSet的水平!开发VCL的程序员是一批牛人,这批牛人的水平是绝大多数程序员所无法达到的,牛人们既熟悉语言和开发工具,也熟悉ADO的底层原理。你用VC做出的东西,与另一个用C++BUILDER或Delphi做出来的东西相比,可能你的稳定性更差,运行速度更慢! 既然费尽心机地用VC做出来的东西还不如另一个学了Delphi3个月作出来的东西,我为什么一定要哪壶不开提哪壶? 所以,从现实的角度,我不赞成大量的程序员为了“自己造轮子”而将大量精力花费在VC上,应尽可能地复用优秀的软件组件。 开发效率是程序员吃饭和公司生存的关键因素。

3)关于.net平台下的Unmanaged和managed应用: 毫无疑问,Unmanaged程序肯定快,但我可以肯定的说,managed今后将会大行其道,特别是在企业级信息网络中。 什么叫Unmanaged应用?直接调用OS的API,直接编译生成机器码的程序。而managed应用,就是运行在一个软件虚拟机上的程序,Java就是一个典型的例子,.net也是走的这条路!Java为什么这样火,M$为什么要跟进这个步伐?很简单,这种架构更适合于现代信息网络的要求。VC6只能开发managed应用,你说说它在现代的网络化软件中会居于一个什么地位? 另外,在企业级的软件中,最重要的是什么?一个是安全,另一个是集成多种信息源!运行效率的考虑是放在最后的。Java慢,但为什么还被广泛用来开发企业级应用程序?XML和Web Service为什么被称为下一代网络技术的核心?最关键的一点是它可以使不同平台的软件相互合作!

   4)现在可以做出一个小结: 对于需要高效率、与硬件打交道、运行于传统Windows平台下的程序而言,VC是重点选择的开发工具,有志于此的程序员必须花大力气去学VC; 对于开发企业级软件和电子商务等互联网应用领域的专业程序员,根本不要去学VC,而应将精力放在标准C++,Java,C#等语言的学习上,同时重点学习.net、J2EE等平台; 对于一般的软件开发爱好者来说,VC不是必经的一条道路,可以根据实际情况选一种开发工具和语言学习; 对于还在学校学习的计算机专业学生,C++和Java是必学的,至于VC,需不需要学还要看你将来想从事的领域。 我之所以发这个贴子,是看到有很多贴子总在夸耀VC的强大(这是实情),无形之中很多人被误导了,不管什么情况,好象一学软件开发必学C++,一学C++必学VC,然后浪费大量的时间和金钱于此,费事不少,收效则低!(我周围就有很多这样的情况,包括我,都成为VC的半瓶水)先不说成为不了专业程序员的人,就是以软件开发作为职业的人,从事的领域不一样,也不一定非学VC不可。有这时间,干些别的岂不更好? 至于VC的前景,我在本贴中提出了自己不乐观的看法。诸位兄弟姐妹想必会有更多的观点,我希望大家能多多讨论一下,这不是孰优孰劣的问题,而是如何把握技术发展趋势,然后根据发展趋势来选择自己的突破口的问题。如果有多方面的观点,对大家想必都是一种启发。 期待更多的发言

回复列表 (共77个回复)

沙发

^_^,我挺支持他的,谁都有说话的权利.有道理就看看,你觉得无道理就笑笑.我也是像他那么认为.

板凳

"作  者:bitfan ()

注:以下的观点主要指VC6。)

1.       背景我这人喜欢偷懒,"我也很喜欢偷懒,但是偷懒也有好处,"懒人改变世界!".如果人人都很勤奋,那么很多发明就不会出来了.VC写成类,BCB写成控件,都是"偷懒".

3 楼

我不想学VC了,哈哈我完了,

4 楼

不是吧,这你就不想学VC了?一点坚持都没有!就算他说的都是真的,那也是几年后的事情,你学VC不只是想拿高工资就这样吧,一点兴趣都没有?再说你没听他说吗,学VC可以段炼你的编程技巧啊~!

5 楼

1、关于VC。
我这个人比较注重细节。不知道大家注意到了没有,在bitfan的帖子里面的标题下面专门有一个注释:(“以下观点主要是针对VC6”)。我认为这是个关键性的细节!如果他的帖子里面提到的VC都是指的VC6,那么我赞成他的大部分观点。我个人也认为,今天才准备入门的初学者并没有必要从VC6开始学起。为什么?因为微软公司已经推出了VC系列的最新产品:VC7.0(就是VC.net),按照微软公司的一贯作法,其新版本软件的推出就意味着其旧版本软件的淘汰。我估计用不了两三年VC7.0就会取代原来6.0的地位。大家不要伤感,在软件行业就是这样,创新就意味着生存,保守就等于死亡!对于那些今天才准备入门的初学者来说,我建议他们现在就直接杀奔VC7.0而去!VC系列产品从最早的1.0发展到现在的7.0,已经走过了很长的路,这中间微软发布过许多的版本。我亲眼经历了VC5.0被6.0淘汰的过程:在VC6.0推出之前,光盘市场上到处都是VC5的光盘,书店里面摆满了VC5的书。当VC6推出以后,VC6的光盘和书立即就占领了市场和书店的最醒目位置,随后微软的宣传攻势扑天盖地展开,微软官方大力敦促人们把他们的开发工具立即由VS5.0升级到VS6.0,那种姿态让人觉得VS5(里面就包括了VC5)已经一文不值了!与此同时,市面上VS6的光盘和书迅速地挤占了原来的VS5的位置。没过多久,光盘市场上和书店里面都是VS6.0一统天下的局面了,原来那些风光一时的VS5的光盘和书都不见了。现在的初学者恐怕没有哪个会从VC5学起了,因为即使你想学也绝难找到适当的软件和书籍资料了。既然如此,今天才准备入门的初学者当然没有必要再在即将过时的软件和书籍资料上浪费钱了(这些东西都是很贵的)。但是对于那些已经在VC6.0上面花掉了时间和投资的初学者来说,我并不主张他们立即扔掉已经花下去了的投资和时间而去追赶时髦的VC7.0(VC.net)。因为VC系列产品直到现在的7.0为止都是向后兼容的!这就意味着你在VC6.0下面构建的工程可以不经过任何的修改而直接拿到VC7.0下面正常地编译、链接、运行成功。我自己已经对此专门进行过实验了!因此,你在VC6下面取得的经验和成果都可以在VC7的平台上派上用场。这同VB完全不同(以前的VB也是向后兼容的,但是VB6.0与VB.net之间却没能实现向后兼容。在VB6.0下创建的工程并不能直接拿到VB.net下面来编译,必须先加入一些被成为托管指令的代码,把原来的工程改造成符合.net规范的新工程,才能被VB.net平台所接受从而编译、运行。而这种改造的过程相当地麻烦,除非你首先学会了VB.net!)从这个方面来说,VC的程序员要比VB的程序员幸运得多!有些人看到VC7.0(VC.net)的用户界面与以前的6.0相比有了很大的变化,就认为VC7.0(VC.net)是一种全新的开发工具或语言。我个人不同意这种观点。我觉得界面的变化并不说明什么问题,对于VC的程序员来说7.0与6.0相比主要有了三大变化。首先是在旧版本中用的MFC类库是4.2版的,而新版本使用的MFC类库是7.0版的,增加了一些新的类,为开发工作提供了更好的类库支持。其次是新版本中增加了一些被称为托管指令的新的指令,如果我们在自己的程序中合理地运用这些新代码就可以充分利用微软的托管机制,比如,我们可以不必自己来回收在程序中动态分配的内存,而让微软的CRL(通用运行库)来负责这项工作。第三是增加了对.net平台的支持。也就是说新的版本可以编译生成MSTL(微软中间语言),为将来的跨平台运行创造了条件。

6 楼

2、关于VC程序员的前途。
当微软提出其.net战略的时候,这个问题曾经被炒得沸沸扬扬。原因在于微软的VS.net里面除了有VC.net以外又新增了一个叫作VC#.net的新语言。而微软对VC#的重视态度让人猜想传统的VC可能会被VC#所取代。并且VC#与VC++除了名称相似以外并无其他的相同点,尤其是两者的语法风格简直有很大的区别。VC++是基于标准的C++语言的,而VC#完全是微软自创的一种全新的语言,其语法和风格非常象java,但是又加入了一些C++的特色。这让许多传统的VC程序员在面对VC#的时候不知措。一想到自己花了大本钱的技术和经验可能会变得一文不值,任何人都会坐不住的。不过,局面很快就得到了澄清:微软并没有放弃VC++的打算!我在早些时候看到了一本今年十月份的《程序员》杂志,那上面有一篇人物专访,所访问的对象正是微软公司Visual C++项目的新任总设计师。该总设计师坦率地表示,微软公司无论是现在还是将来都没有在其.net框架中放弃其VC++系列语言的打算,相反,VC在.net框架下面将会担负起更加重要的角色:微软已经把VC定位于.net框架下的系统级语言!而且该总设计师再三表示,VC.net(VC7.0)是到目前为止.net框架下唯一在编译生成MSTL(微软中间语言)的时候进行了编译优化的开发工具。美国国家标准委员会(ANSI)和国际标准化组织(ISO)几乎每年都要开会,向C++的标准当中加入一些新的关键字和新语法,这使得C++语言也能象人类的自然语言那样进步、发展。但是这也同时产生了新的C++标准与已有的C++编译器之间的兼容性的问题。当该总设计师在被问到微软公司将如何实践其“将不断地推进Visual C++的兼容性”的承诺的时候表示,微软公司将会通过发行升级服务包(俗称补丁)和适时地推出新的版本的办法来保证微软的VC++与新的C++标准相兼容。不过该总设计师也表示,并非所有在C++新标准中提到过的新东西都会出现在VC++中,微软公司将会根据实际情况和用户的反映进行取舍。另外符合下列两种情况之一的新标准一定会被VC++所支持:a、由别的编译器已经实现了支持的新标准。b、用户广泛要求的、对编程工作确实有用的新标准。当被问到估计将有多少VC的程序员会转向VC#的时候,该总设计师表示,他认为无论是现在还是将来都不存在VC++程序员转向VC#的问题,但是将会有越来越多的VB程序员转向VC#。由以上这些信息,我觉得大家根本不必耽心学习VC的前途是否光明。只要你学好了VC,没有人能轻视你!而只要你善于不断地学习,那么永远不会出现“空有屠龙之技而无龙可屠”的情况,要知道技术熟练的开发人员永远都是需要的,有的时候甚至是供不应求的。

7 楼

3、关于技术进步的问题。
我们知道,在DOS时代,市面上固然有MS C/C++、QUICK BASIC等微软公司的开发工具,同时也有许多诸如:TURBO C/C++、TURBO PASCAL、DEBAS3、FOXBAS、FOXPRO之类的第三方的开发工具,并且后者更出名、使用得更广泛!当从DOS时代升迁到windows时代以后,固然微软的MS C/C++、QUICK BASIC等开发工具被淘汰了,然而同属于那个时代的TURBO C/C++、TURBO PASCAL、DEBAS3、FOXBAS、FOXPRO之类的第三方开发工具不也同时被淘汰了?覆巢之下焉有完卵?!因此,我们完全有理由相信,将来如果有某一天,由于技术进步的原因导致VC被淘汰了,那么与VC同一时代的、只能在windows平台上搞开发的这许多开发工具如:VB、BCB、DELPHI等等都逃脱不了被淘汰的命运!如果你是由于怕技术的进步而不想学VC,那你最好不要学编程,并且你干脆什么都不要去学!因为任何一种开发工具、任何一种技术最终都会过时、都会被淘汰的,这是客观规律。

8 楼

4、关于效率。
有人认为,在软件工程中开发效率应该优先于运行效率。我不同意这种观点。据我所知,对于开发所有的游戏软件和大部分的多媒体软件来说,程序的运行效率都是至关重要的,而在所有的实时应有领域,比如电脑虚拟仪器开发中的信号采集、分析、处理,和自动控制中的工业过程自动控制等方面更是对程序的运行效率有苛刻的要求。在上述领域,程序的运行效率显然应该摆在开发效率的前面。另外,在一些传统的被认为对运行效率的要求不高的应有领域,比如说开发象Word那样的字处理软件,当我们想加入一些高级功能的时候,例如:加入自动化的拼写(语法)检查、声音识别、手写体输入等,往往程序的运行效率就会变得非常重要了。早期的VB开发出来的程序由于是采用解释的方式运行的,运行的效率远低于delphi,因此虽然使用VB的开发效率更高,却远不是delphi的竞争对手。现在的java虽然具有跨平台运行的强大功能,然而由于用它开发的程序也是以解释的方式执行的,运行效率低下,所以除了在网页制作方面占有一席之地以外,java在其他的应有领域并没有取得应有的成功。我个人认为,专业的程序员应该始终把运行效率放在首要的地位来追求,宁可自己多付出些牺牲也要让客户用上速度最快的软件。

9 楼

5、关于学习标准的C/C++。
学好标准的C/C++当然是很有用的,但是光读死书是学不好的。为了把标准的C/C++学好、学精,我们很有必要上机实验,这对于我们巩固和加深对书本知识的理解大有好处。既然要在真正的计算机上编译和测试我们做练习用的c/c++源程序,就必须购买并安装一个实实在在的C/C++编译器,那么你们打算买个什么样的编译器呢,是Turbo C/C++还是Ms C/C++或者是Borland C++?即使你们想这么作也不可能了,因为你们根本就很难找到这些东西,而有关这些东西的资料就更少了。那么依我看,大家只有去买目前市面上最流行的VC或者BCB了。不过这两种软件对于初学者来说都比较复杂,因此在安装使用它们之前很有必要去买一本《Visual C++入门》之类的书来先学一下VC的操作。这样就又回到了我们的起点:学习VC!。

10 楼

iron前辈解释的太全面了~~希望多点因为看了此文章的编程爱好者能仔细把这评论看完才不至于盲目的放弃了VC~

我来回复

您尚未登录,请登录后再回复。点此登录或注册