学习C++的一些建议

1.把C++当成一门新的语言学习（和C没啥关系！真的。）；

2.看《Thinking In C++》，不要看《C++变成死相》；

3.看《The C++ Programming Language》和《Inside The C++ Object Model》,不要因为他们很难而我们自己是初学者所以就不看；

4.不要被VC、BCB、BC、MC、TC等词汇所迷惑——他们都是集成开发环境，而我们要学的是一门语言；

5.不要放过任何一个看上去很简单的小编程问题——他们往往并不那么简单，或者可以引伸出很多知识点；

6.会用Visual C++，并不说明你会C++；

7.学class并不难，template、STL、generic programming也不过如此——难的是长期坚持实践和不遗余力的博览群书；

8.如果不是天才的话，想学编程就不要想玩游戏——你以为你做到了，其实你的C++水平并没有和你通关的能力一起变高——其实可以时刻记住：学C++是为了编游戏的；

9.看Visual C++的书，是学不了C++语言的；

10.浮躁的人容易说：XX语言不行了，应该学YY；——是你自己不行了吧！？

11.浮躁的人容易问：我到底该学什么；——别问，学就对了；

12.浮躁的人容易问：XX有钱途吗；——建议你去抢银行；

13.浮躁的人容易说：我要中文版！我英文不行！——不行？学呀！

14.浮躁的人容易问：XX和YY哪个好；——告诉你吧，都好——只要你学就行；

15.浮躁的人分两种：a)只观望而不学的人；b)只学而不坚持的人；

16.把时髦的技术挂在嘴边，还不如把过时的技术记在心里；

17.C++不仅仅是支持面向对象的程序设计语言；

18.学习编程最好的方法之一就是阅读源代码；

19.在任何时刻都不要认为自己手中的书已经足够了；

20.请阅读《The Standard C++ Bible》(中文版：标准C++宝典)，掌握C++标准；

21.看得懂的书，请仔细看；看不懂的书，请硬着头皮看；

22.别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍；

23.请看《Effective C++》和《More Effective C++》以及《Exceptional C++》；

24.不要停留在集成开发环境的摇篮上，要学会控制集成开发环境，还要学会用命令行方式处理程序； 25.和别人一起讨论有意义的C++知识点，而不是争吵XX行不行或者YY与ZZ哪个好；

26.请看《程序设计实践》，并严格的按照其要求去做；

27.不要因为C和C++中有一些语法和关键字看上去相同，就认为它们的意义和作用完全一样；

28.C++绝不是所谓的C的“扩充”——如果C++一开始就起名叫Z语言，你一定不会把C和Z语言联系得那么紧密；

29.请不要认为学过XX语言再改学C++会有什么问题——你只不过又在学一门全新的语言而已；

30.读完了《Inside The C++ Object Model》以后再来认定自己是不是已经学会了C++；

31.学习编程的秘诀是：编程，编程，再编程；

32.请留意下列书籍：《C++面向对象高效编程（C++ Effective Object-Oriented Software Construction）》《面向对象软件构造(Object-Oriented Software Construction)》《设计模式（Design Patterns）》《The Art of Computer Programming》；

33.记住：面向对象技术不只是C++专有的；

34.请把书上的程序例子亲手输入到电脑上实践，即使配套光盘中有源代码；

35.把在书中看到的有意义的例子扩充；

36.请重视C++中的异常处理技术，并将其切实的运用到自己的程序中；

37.经常回顾自己以前写过的程序，并尝试重写，把自己学到的新知识运用进去；

38.不要漏掉书中任何一个练习题——请全部做完并记录下解题思路；

39.C++语言和C++的集成开发环境要同时学习和掌握；

40.既然决定了学C++,就请坚持学下去，因为学习程序设计语言的目的是掌握程序设计技术，而程序设计技术是跨语言的；

41.就让C++语言的各种平台和开发环境去激烈的竞争吧，我们要以学习C++语言本身为主；

42.当你写C++程序写到一半却发现自己用的方法很拙劣时，请不要马上停手；请尽快将余下的部分粗略的完成以保证这个设计的完整性，然后分析自己的错误并重新设计和编写（参见43）；

43.别心急，设计C++的class确实不容易；自己程序中的class和自己的class设计水平是在不断的编程实践中完善和发展的；

44.决不要因为程序“很小”就不遵循某些你不熟练的规则——好习惯是培养出来的，而不是一次记住的；

45.每学到一个C++难点的时候，尝试着对别人讲解这个知识点并让他理解——你能讲清楚才说明你真的理解了；

46.记录下在和别人交流时发现的自己忽视或不理解的知识点；

47.请不断的对自己写的程序提出更高的要求,哪怕你的程序版本号会变成Version 100.XX；

48.保存好你写过的所有的程序——那是你最好的积累之一；

49.请不要做浮躁的人；

50.请热爱C++!

你应当如何学习C++（以及编程）

Javascript是世界上最受误解的语言，其实C++何尝不是。坊间流传的错误的C++学习方法一抓就是一大把。我自己在学习C++的过程中也走了许多弯路，浪费了不少时间。

为什么会存在这么多错误认识？原因主要有三个，一是C++语言的细节太多。二是一些著名的C++书籍总在（不管有意还是无意）暗示语言细节的重要性和有趣。三是现代C++库的开发哲学必须用到一些犄角旮旯的语言细节（但注意，是库设计，不是日常编程）。这些共同塑造了C++社群的整体心态和哲学。

单是第一条还未必能够成气候，其它语言的细节也不少（尽管比起C++起来还是小巫见大巫），就拿javascript来说，作用域规则，名字查找，closure，for/in，这些都是细节，而且其中还有违反直觉的。但许多动态语言的程序员的理念我猜大约是学到哪用到哪罢。但C++就不一样了，学C++之人有一种类似于被暗示的潜在心态，就是一定要先把语言核心基本上吃透了才能下手写出漂亮的程序。这首先就错了。这个意识形成的原因在第二点，C++书籍。市面上的C++书籍不计其数，但有一个共同的缺点，就是讲语言细节的书太多——《C++ gotchas》，《Effective C++》，《More Effective C++》，但无可厚非的是，C++是这样一门语言：要拿它满足现代编程理念的需求，尤其是C++库开发的需求，还必须得关注语言细节，乃至于在C++中利用语言细节已经成了一门学问。比如C++模板在设计之初根本没有想到模板元编程这回事，更没想到C++模板系统是图灵完备的，这也就导致了《Modern C++ Design》和《C++ Template Metaprogramming》的惊世骇俗。这些技术的出现为什么惊世骇俗，打个比方，就好比是一块大家都认为已经熟悉无比，再无秘密可言的土地上，突然某天有人挖到原来地下还蕴藏着最丰富的石油。在这之前的C++虽然也有一些细节，但也还算容易掌握，那可是C++程序员们的happy old times，因为C++的一切都一览无余，everything is figured out。然而《Modern C++ Design》的出世告诉人们，“瞧，还有多少细节你们没有掌握啊。”于是C++程序员们久违的激情被重燃起来，奋不顾身的踏入细节的沼泽中。尤其是，模板编程将C++的细节进一步挖掘到了极致——我们干嘛关心涉及类对象的隐式转换的优先级高低？看看boost::is_base_of就可以知道有多诡异了。但最大的问题还在于，对于这些细节的关注还真有它合适的理由：我们要开发现代模板库，要开发active library，就必须动用模板编程技术，要动用模板编程技术，就必须利用语言的犄角旮旯，enable_if，type_traits，甚至连早就古井无波的C宏也在乱世中重生，看看boost::preprocessor有多诡异就知道了，连C宏的图灵完备性（预编译期的）都被挖掘出来了。为什么要做这些？好玩？标榜？都不是，开发库的实际需求。但这也正是最大的悲哀了。在boost里面因实际需求而动用语言细节最终居然能神奇的完成任务的最好教材就是boost::foreach，这个小设施对语言细节的发掘达到了惊天地泣鬼神的地步，不信你先试着自己去看看它的源代码，再看看作者介绍它的文章吧。而boost::typeof也不甘其后——C++语言里面有太多被“发现”而不是被“发明”的技术。难道最初无意设置这些语言规则的家伙们都是oracles？

因为没有variadic templates，人们用宏加上缺省模板参数来实现类似效果。因为没有concepts，人们用模板加上析构函数的细节来完成类似工作。因为没有typeof，人们用模板元编程和宏加上无尽的细节来实现目标„ C++开发者们的DIY精神不可谓不强。

然而，如果仅仅是因为要开发优秀的库，那么涉及这些细节都还是情有可原的，至少在C++09出现并且编译器厂商跟上之前，这些都还能说是不得已而为之。但我们广大的C++程序员呢？大众是容易被误导的，我也曾经是。以为掌握了更多的语言细节就更牛，但实际却是那些语言细节十有是平时编程用都用不到的。C++中众多的细节虽然在库设计者手里面有其用武之地，但普通程序员则根本无需过多关注，尤其是没有实际动机的关注。一般性的编码实践准则，以及基本的编程能力和基本功，乃至基本的程序设计理论以及算法设计。才是

真正需要花时间掌握的东西。

学习最佳编码实践比学习C++更重要。看优秀的代码也比埋头用差劲的编码方式写垃圾代码要有效。直接、清晰、明了、KISS地表达意图比玩编码花招要重要„

避免去过问任何语言细节，除非必要。这个必要是指在实际编程当中遇到问题，这样就算需要过问细节，也是最省事的，懒惰者原则嘛。一个掌握了基本的编程理念并有较强学习能力的程序员在用一门陌生的语言编程时就算拿着那本语言的圣经从索引翻起也可以编出合格的程序来。十年学会编程不是指对每门语言都得十年，那一辈子才能学几门语言哪，如果按字母顺序学的话一辈子都别指望学到Ruby了；十年学习编程更不是指先把语言特性从粗到细全都吃透才敢下手编程，在实践中提高才是最重要的。

至于这种抠语言细节的哲学为何能在社群里面呈野火燎原之势，就是一个心理学的问题了。想像人们在论坛上讨论问题时，一个对语言把握很细致的人肯定能够得到更多的佩服，而由于论坛上的问题大多是小问题，所以解决实际问题的真正能力并不能得到显现，也就是说，知识型的人能够得到更多佩服，后者便成为动力和仿效的砝码。然而真正的编程能力是与语言细节没关系的，熟练运用一门语言能够帮你最佳表达你的意图，但熟练运用一门语言绝不意味着要把它的边边角角全都记住。懂得一些常识，有了编程的基本直觉，遇到一些细节错误的时候再去查书，是最节省时间的办法。

C++的书，Bjarne的圣经《The C++ Programming Language》是高屋建瓴的。《大规模C++程序设计》是挺务实的。《Accelerated C++》是最佳入门的。《C++ Templates》是仅作参考的。《C++ Template Metaprogramming》是精力过剩者可以玩一玩的，普通程序员碰都别碰的。《ISO.IEC C++ Standard 14882》不是拿来读的。Bjarne最近在做C++的教育，新书是绝对可以期待的。

最后就以我在Bjarne的众多访谈当中摘录的一些关于如何学习C++（以及编程）的看法结束吧（没空逐段翻译了，只将其中我觉得最重要的几段译了一下，当然，其它也很重要，这些段落是在Bjarne的所有采访稿中摘抄出来的，所以强烈建议都过目一下）：

I suspect that people think too little about what they want to build, too little about what would make it correct, and too much about \"efficiency\" and following fashions of programming style.

The key questions are always: \"what do I want to do?\" and \"how do I know that I have done if?\". Strategies for testing enters into my concerns from well before I write the firat line of code, and that despite my view that you have to write code very early - rather than wait until a design is complete.

译：我感觉人们过多关注了所谓“效率”以及跟随编程风格的潮流，却严重忽视了本不该被忽视的问题，如“我究竟想要构建什么样的系统”、“怎样才能使它正确”。最关键的问题永远是：“我究竟想要做什么？”和“如何才能知道我的系统是否已经完成了呢？”就拿我来说吧，我会在编写第一行代码之前就考虑测试方案，而且这还是在我关于应当早于设计完成之前就进行编码的观点的前提之下。

Obviously, C++ is very complex. Obviously, people get lost. However, most peple get lost when they get diverted into becoming language lawyers rather than getting lost when they have a clear idea of what they want to express and simply look at C++ language features to see how to express it. Once you know data absreaction, class hierarchies (object-oriented programming), and parameterization with types (generic programming) in a fairly general way, the C++ language features fall in place.

译：诚然，C++非常复杂。诚然，人们迷失其中了。然而问题是，大多数人不是因为首先对自己想要表达什么有了清晰的认识只不过在去C++语言中搜寻合适的语言特性时迷失的，相反，大多数人是在不觉成为语言律师的路上迷失在细节的丛林中的。事实是，只需对数据抽象、类体系结构（OOP）以及参数化类型（GP）有一个相当一般层面的了解，C++纷繁的语言特性也就清晰起来了。

Well, I don't think I made such a trade-off. I want elegant and efficient code. Sometimes I get it. These dichotomies (between efficiency versus correctness, efficiency versus programmer time, efficiency versus high-level, et cetera.) are bogus.

I think the real problem is that \"we\" (that is, we software developers) are in a permanent state of emergency, grasping at straws to get our work done. We perform many minor miracles through trial and error, excessive use of brute force, and lots and lots of testing, but--so often--it's not enough.

Software developers have become adept at the difficult art of building reasonably reliable systems out of unreliable parts. The snag is that often we do not know exactly how we did it: a system just \"sort of evolved\" into something minimally acceptable. Personally, I prefer to know when a

system will work, and why it will.

There are more useful systems developed in languages deemed awful than in languages praised for being beautiful--many more. The purpose of a programming language is to help build good systems, where \"good\" can be defined in many ways. My brief definition is, correct, maintainable, and adequately fast. Aesthetics matter, but first and foremost a language must be useful; it must allow real-world programmers to express real-world ideas succinctly and affordably.

I'm sure that for every programmer that dislikes C++, there is one who likes it. However, a friend of mine went to a conference where the keynote speaker asked the audience to indicate by show of hands, one, how many people disliked C++, and two, how many people had written a C++ program. There were twice as many people in the first group than the second. Expressing dislike of something you don't know is usually known as prejudice. Also, complainers are always louder and more certain than proponents--reasonable people acknowledge flaws. I think I know more about the problems with C++ than just about anyone, but I also know how to avoid them and how to use C++'s strengths.

In any case, I don't think it is true that the programming languages are so difficult to learn. For example, every first-year university biology textbook contains more details and deeper theory than even an expert-level programming-language book. Most applications involve standards, operating systems, libraries, and tools that far exceed modern programming languages in complexity. What is difficult is the appreciation of the underlying techniques and their application to real-world problems. Obviously, most current languages have many parts that are unnecessarily complex, but the degree of those complexities compared to some ideal minimum is often exaggerated.

We need relatively complex language to deal with absolutely complex problems. I note that English is arguably the largest and most complex language in the world (measured in number of words and idioms), but also one of the most successful.

C++ provides a nice, extended case study in the evolutionary approach. C compatibility has been far harder to maintain than I or anyone else expected. Part of the reason is that C has kept evolving, partially guided by people who insist that C++ compatibility is neither necessary nor good for C. Another reason-- probably even more important--is that organizations prefer interfaces that are in the C/C++ subset so that they can support both languages with a single effort. This leads to a

constant pressure on users not to use the most powerful C++ features and to myths about why they should be used \"carefully,\" \"infrequently,\" or \"by experts only.\" That, combined with backwards-looking teaching of C++, has led to many failures to reap the potential benefits of C++ as a high-level language with powerful abstraction mechanisms.

The question is how deeply integrated into the application those system dependencies are. I prefer the application to be designed conceptually in isolation from the underlying system, with an explicitly defined interface to \"the outer world,\" and then integrated through a thin layer of interface code.

Had I had a chance to name the style of programming I like best, it would have been \"class-oriented programming\but then I'm not particularly good at finding snappy names. The school of thought that I belong to - rooted in Simula and related design philosophies - emphasizes the role of compile-time checking and flexible (static) type systems. Reasoning about the behavior of a program has to be rooted in the (static) structure of the source code. The focus should be on guarantees, invariant, etc. which are closely tied to that static structure. This is the only way I know to effectively deal with correctness. Testing is essential but cannot be systematic and complete without a good internal program structure - simple-minded blackbox testing of any significant system is infeasible because of the exponential explosion of states.

So, I recommend people to think in terms of class invariants, exception handling guarantees, highly structured resource management, etc. I should add that I intensely dislike debugging (as ah hoc and unsystematic) and strongly prefer reasoning about source code and systematic testing.

Pros: flexibility, generality, performance, portability, good tool support, available on more platforms than any competitor except C, access to hardware and system resources, good availability of programmers and designers. Cons: complexity, sub-optimal use caused by poor teaching and myths.

P.S. 关于如何学习编程，g9的blog上有许多精彩的文章：这里，这里，这里，这里„ 实际上，我建议你去把g9老大的blog翻个底朝天

再P.S. 书单？我是遑于给出一个类似《C++初学者必读》这种书单的。C++的书不计其数，被公认的好书也不胜枚举。只不过有些书容易给初学者造成一种错觉，就是“学习C++就应该是这个样子的”。比如有朋友提到的《高质量C/C++编程》，这本书有价值，但不适合初学者，初学者读这样的书容易一叶障目不见泰山。实际上，正确的态度是，细节是必要的。但细节是次要的。其实学习编程我觉得应该最先学习如何用伪码表达思想呢，君不见《Introduction to Algorithm》里面的代码？《TAOCP》中的代码？哦，对了它们是自己建立的语言，但这种仅教学目的的语言的目的就是为了避免让写程序的人一开始就忘了写程序是为了完成功能，以为写程序就是和语言细节作斗争了。Bjarne说程序的正确性最重要，boost的编码标准里面也将正确性列在性能前面。

此外，一旦建立了正确的学习编程的理念，其实什么书（只要不是太垃圾的）都有些用处。都当成参考书，用的时候从目录或索引翻，基本就对了。

学好VC++的十大良好习惯

每到年底各大媒体就争先恐后热火朝天地搞总结，什么十大人物，十大品牌，十大美女，十大帅哥等等五花八门乱七八糟的让人充满好奇充满怀疑，这事确实让人有点郁闷，就如同男足国家队的国产教练如沈墙扶们每一次踢球失败后都要说这么一句：我们回去后要好好总结，下次会打得更好！ 这话听了几十年了，耳朵都生虫了，但还是无法看到中国猪球队有象人样的表现。因此，总结在某一程度上来说只不过是一种形式罢了，总结不代表就能改过原有的不足，也不代表就能进步了，甚至有点俗不可耐，尽管如此，阿蒙亦明知故俗，前人说过了入乡了就要随俗，因此你生活在这种环境里，你无法对这些无聊无趣的东东置之不理，除非你是天才，天才往往在非天才的人看来是很怪异的，处处与现实格格不入，可阿蒙不是天才，所以还得赶快总结，要不就离题，又被大家骂了，：）

（一）充分利用MSDN，因为我个人觉得它胜过任何一本编程参考书；

MSDN是 Microsoft 当前提供的有关编程信息的最全面的资源，它包含微软最新的技术数据库，加上易学易用的全文检索功能，让您迅速找到任何您需要的技术参考数据，让您随时拥有与全世界菁英同步的技术，掌握最丰富的程序开发资源。我经常收到很多朋友的EMAILS，他们所提的问题往往都非常的简单，MSDN完全可以解答这些问题，但他们好象不太喜欢用，这是让我郁闷的地方，是因为英文不好呢，还是没有学会充分利用各种资源来解决问题的方法呢？

（二）提高英文水平，养成多上英文网站多看英文资料多买老外原版英文书；

有关程序员与英文水平的讨论已太多太多， 我个人认为要成为程序员，高中的英语水

平够了，甚至不懂英语的一些人，也同样可以成为较好的程序员，因为开发工具的发展将是越来越傻瓜，但如果你是仅仅满足于能运用某种工具开发某个软件模块，那是没话说了。真正热衷技术肯干钻研乐于接受挑战的程序员是不满足于现状的，他们总感觉有太多的未知，于是总在不停地学习，如今信息技术发展得太快，而大部分的技术最先出现的时候都是英文版本的，要几个月或者几年以后才有中文版本的书出来，因此要想跟上步伐，一定要努力提高自己的英文水平，这样才能同步跟上信息技术。你可能担心自己的英语水平不行，没关系，刚开始多查字典，“万事开头难”，必须有持之以恒的精神，不久你就会发现计算机英语其实很容易的。何况很多

英文技术站点确实比国内做得好啊！比如http：//www.codeguru.com，http：//www.codeproject.com，http：//www.programmersheaven.com 等等。

（三）加强自我管理，善于作自我总结，分析自已的优点及缺点。

中国境内百分之八十以上的领导人在百分之八十以上的场合的讲话中都有类似的观点，所以在这里我是不多说了，反正这一条用在什么行业什么地方都不会有错的，人生最大的敌人不是就是自已吗？管好自已认清自已，那还有什么搞不定的？

（四）养成良好的文档习惯

程序员大多都不喜欢写文档，我以前也是特讨厌，在我的思想里，所谓的文档就是一些废话，一句话硬是用十句话来代替的无聊透顶，就如同部分中文系男生的爱情表白，明明就是“我爱你”三个字，他硬是把月亮啊太阳啊大海啊高山啊石头啊天使啊乱七八糟的都拉上关系了，尽管听起来浪漫，但在我认为不实用，：）， 甚至太肉麻了，一个男子汉干嘛这么罗里罗嗦的„„良好的文档是正规研发流程中非常重要的环节，一个好的程序是先写好设计文档再进行编程的，在设计文档的指导下，才能写出安全的代码。如果你不写文档，一开始就写程序，这样你就不会按已设计好的路线走，而是想到哪写到哪。小功能还好说，要是大功能，就容易混乱甚至失控。那么如何写文档呢？其实我认为没有统一的标准，虽然国家及一些NB的人总结了很多的模板，但每个人的习惯不同，如果你不加以修改或创新，就套用某个标准，我相信写起来会很吃力及说不清的难受，因此我觉得只要能将你的设计思想及实现算法或步骤描述清楚就是好的文档，我强烈建议广大程序员朋友们在写文档时要善于用图表来说明你的思想，我们不是作家，也可能作文都经常性地不及格，写出五官端正的文章对我们来说可能不容易啊！好好地利用VISIO，ROSE或别的工具来表达你的思想吧！

（五）代码风格要规范，严谨，效率要高。

这个不用说了，所以一定要记住了！不过，这一点有时可能与人的性格有关，如果你是经常丢三落四经常胡子长长经常钮扣扣错经常吃个快餐要一个小时的人，那你在CODING的时候可千万要注意了，CODING是CODING，生活是生活，不要写出的程序也是那样就不好了！

（六）掌握好跟踪调试技巧。

跟踪调试程序是一件繁琐而又复杂的事情，所以掌握必要的调试策略及技巧却可以使这些工作变得轻松起来。强烈建议你去看一下老美Everett N。McKay及Mike Wooding写的书＜＜Debugging Windows Programs＞＞，你一不定受益匪浅。

（七）养成自我测试的习惯

测试工作应由测试工程师来做，但在你写完一个模块或一个软件时，还是要自已先测试一下，保证不要出现一些低级的错误，何况这些错误让测试工程师看到了，狂扁你一顿，你很没FACES的。

（八）善于交流善于沟通，特别是经常与一些高手交流一下学习的心得体会；

有人说，程序员的性格大多内向不喜欢说话，其实是有些误会了，不是不喜欢而是话不投机，我的脑袋一天到晚都在不停地转，函数，数据，算法啊充满了我的世界，我那还有时间与你谈一些无聊的话题，话要找对人了，才容易谈下去，书上说过“听君一席话，胜读十年书”，你要找的就是这种豁然开朗！现在技术的论坛越来越来，这将成为程序员交流一个重要的地方，也有人说：“读君一长贴，胜读十年书”，：）

（九）阶段性地做一下专题总结

知识要温故而知新，因此我建议程序员要养成阶段性地做专题总结的习惯，比如你这个月学习或在做与多线程有关的模块或项目，那么在你做完后，你就可以好好地总结一下所有与多线程相关的技术，包括理论知识，实践方法以及各种技巧及优秀文章等等，这对你各种能力的提高将有很大的帮助，你试过了吗，如果没有，那就快点行动吧！

（十）要有持之以恒的精神

这是废话，因为我揍不齐十大，所以将它也算上，中国自古以来喜欢号召大众学习某种精神，比如马克思的，列宁的，的，的，雷峰的等，这些精神使社会更安定人民生活更美好，那么程序员要有什么样的精神呢？我不是我说了就算了的，我只是想说明要学好任何一门技术，最好要有持之以恒精益求精的精神，特别是学一些比较抽象比较难的技术，比如VC＋＋，我想它应比别的开发语言都要难学些，或许你已经开始了两年了，但感觉还是不爽仿佛也没掌握什么，这个时候你除了思考一下你的学习方法以外，还必须坚定你的目标及信念！

第六篇： 导航：第一篇 第二篇 第三篇 第四篇 第五篇 第六篇 如何成为一名优秀的程序员?

一位仁兄说的“程序员写的程序不是算法+语法 ，而是要能够满足用户需求的工 具”我非常赞同，要想达到用户需求就必须从各个方面来考虑如业务、人机交互 、效率等方面，而不只是一个语言（语法）的问题，语言（语法）只是工具，只 知语法不知其他那就真是编程机器了！ 编程机器在印度高中生经过几个月培训，按照严谨的软工方法，加上较高的管理 ，就可以胜任了！大家相信吗，我是相信的！谈到这里我就不禁说到了国内教育 界最近

在探讨的问题“计算机科系的毕业生特别是本科大专生到底出来干啥、如 何适应社会要求”，大家也看到了很多计科系大学生说精通N种语言，熟悉N种工 具，不知道学校里的其他知识到那里去了，甘愿做编程机器，浪费了人民的纳税 ，干高中生能干的事，比较可惜吧！在国内现在就是这样了，看过一则帖子：清华的计科系毕业声在建筑院里搞开发还不如建筑专业的毕业生。说着说着就岔道 了，国内的软件开发业到底是需要那些人：如果仅仅是编码机器，那我估计中国 硅谷还是做梦去吧！

社会似乎也需要编码机器，翻翻招聘广告，做应用开发的都要求精通某某语言， 熟悉某某工具，很少需要懂管理懂软工的人。以我个人一点偏激的想法，民族软 件产业要腾飞，更需要的是能管理使用编码机器的人，即管理人员、国内软件产 业编码机器已经很多了。希望不要惹怒了那些编程高手！ system develop与Application develop在国内到底哪个能养活你，能赚钱，诸位 仁兄想必也知道，况且俺也没发现几家水平高的公司招这方面的人，毕竟OS，DB MS，COMPILER都被国外做了、另外也别跟我谈LINUX，毕竟还是少数烧钱的人做的 事情，我先喂饱肚皮再说。我手下的很多搞4GL语言的程序员都想转行学VC等所谓 的更低级的语言，我总是说“在XX城市，先用4GL工具生存，以后再学习VC吧！” ，说的简单一点先解决肚子问题。如何判断自己是否是编程机器？

1、面对需求不考虑用户，只是考虑用那些程序技术展示自己的语言语法技巧 . 2、学习了N种语言 .

3、从来不学习或实践软工 .

4、语法语言水平在众人中遥遥领先、特别是一些稀奇古怪的语法 凭着兴趣和创造力去干，却重复繁琐的劳动。 做着没有意义-唯一意义是赚钱，而且真是出了半斤力， 拿不足八两。 终日劳累，却不能学自己想学的。最终结果是跟不上社会科技的发展 ，人已衰老。悲哀！！！

开发软件的关键是要有想法，一个好的想法比什么都重要。尤其是有关 网络方面的就更是如此。

入门还可以，但是要继续深入了解可能要难点。 未必吧 偶觉得大学里的高数 数理方法之类的, 如果你不是做研究的话, 应该是很少能 用到的 不过如果说到离散之类的, 倒还是时不时的能有点用现在的程序员比起十年前是不是要花更多的时间来 查帮助呢。系统越来越大，手册越来越厚，软件开发的 周期是不是越来越多的淹没在查帮助之中了呢。 󰀀

实际上一个程序员最终的技术需要和实际相结合。真正在编写程序到达一定时候，语言的使用并不是最大的障碍，对整个项目的把握、软件工程的把握、数据库的设计以及执行效果的分析等等才是需要进一步考虑的东东！否则，为何大多数公司到要求有编程经验了！这些不是程序员必须学的。但数据结构，编译原理，操作系统原理等是必须要学好的，英文的多看，不懂计算机英语可不行。实我不是什么中专生,而是我读的中学和一个私人办的电脑学校联合开的电脑专业(并不是我中考考的差,而是这个学校太贪钱了,才被录取到这里,恼火,我们班里中考成绩从两百多到四百多的都有,我就是四百多分(重理轻文的结果,要不然...),当时读书的时候,我是班是的高手(其实只是比其它同学懂而已),大家叫我dos,因为当时学的都是dos的内容, 毕业后还没有对编程很感兴趣,只想找一个电脑的工作就可以了,哪怕是打字的,可是看报纸,去人才中心,看到都是要大学的,为此感到很失望.也对电脑失去了兴趣.后来学校打电话到我家,说厦门厦华公司要招工,要不要去,我很快就答应了,因为当时没工作,天天呆在家里.后来打工的时候,天天象一个机械人一样,重复着同一道工序,因此经常在深夜的时候,思索着自己的未来,由此重新生起了对电脑的感情,因此经常买电脑杂志和报纸看(可以堆成一座山

了).由于离我住的地方不远处,有一个电脑培训的,所以经常到那里上机,而在学校里学过的软件也只有FOXBASE和WPS,其它的不值一提,所以上机经常用foxbase,直到这时候,才对编程产生了浓厚的兴趣,一年后,自已买了一台电脑,开始认真学习编程.由于我是属于职业中专的,因此经常想,就算学得再好也没有用,所以想考程序员,而考程序员要懂得c语言,所以就学习turbo c,学完了,学数据结构,同时看'C高级实用程序设计',回归和2000年的两个晚上,我都是在编程中度过的.由于我这个人对书很感兴趣,经常在星期六,星期七去书店,而在书店里,也是看编程方面的书,而看到的编程书籍大部份都是windows方面的,为此也经常思索着学dos编程到底有没有用.后来,春节放假(要2月13日上班)回老家,天天去新华书店(正月初一也去),看到也都是windows编程方面的书多得像狗屎一样,所以就下决心学windows编程,因此正月初四(快餐店还没有开张)就去厦门了,很快买了delphi的书和d版delphi5,疯狂地学习(到目前为止,买了8本delphi的书,因为国人的写的书实在太烂),而由于遇到不懂的又不知道怎么办,为此想到了网络,但在外打工不可能上网(上网吧太贵),所以就辞职了(4月21日),现在,程序员考试快到了,是报还是不报一直犹豫不觉,困此才有此问题.打工的岁夜,我永远不会忘记,因为付出太多了,也失去了太多(坏了两个光驱,瘦了几斤),直到现在,脑海里还不时浮现起那几个无眠的夜晚.忠心感谢大家.我不认为编码的人就是机器, 而系统分析就不是机器, 其实系统分析员就是销售的机器, 所有职员有是老板的机器.它们之间这是不同工种吧了, 当然对系统分析要求要高一些, 薪水也高一些, 但更让人佩服的是销售, 是他们驱动了整个的运作.我也是个中专生, 还是学机械的(后来自学了计算机), 我非常了解在传统的制造业是如何的规范, 设计人员设计图纸, 然后经审核, 再到车间试样, 再根据情况, 修改图纸, 如此反复几次后才能一个产品定型,而在软件界, 就没那么好了, 领导会说, 这个你做, 那个他做, 也没有经过很细的分析(国内很多都是这样), 在我们这里也没有系统分析员, 每个人都是设计员, 也是编程员, 虽然这样对个人来说, 能学到很多东西, 但不利于项目.我国的软件过程水平,确实令人担忧, 目前为止只是, 几个人十几个人的小软件, 还没有能拿得手的大型软件.至于中专生编程问题, 我

认为只要入了这个行, 就不会比本科生差, 因为对他来说没有优越的学历条件, 那么只好埋头苦学, 但这正好适应当前计算机软件迅速发展的今天, 学历只能代表过去和基础, 更需要的是有能力的人, 解决问题的人, 实干的人.对我来说确实有时有点自卑, 没有上过高中和大学(由于那个年代, 我只知道能为父母减少一点负担就行了), 所有我一直在努力的学习(corba, uml, java, 软件过程等), 目前为止我并没有觉的我的构架能力和编码水平比他们差, 只是觉得E语言实在太差.过计算机本科又如何？我有几个同学到银行去搞业务了，有同学任教，有同学收税去了......60多个人真正现在搞计算机的还就只有几个人，再看看当时这些计算机本科生的毕业设计,//faint有的人到最后连vb都搞不定，但他们什么编译原理啦什么组成原理啦什么软件工程啦学的（应该是考试的分数）真还不

错，至少我感觉有些概念比我清楚（上课没听?)所以我觉的中专生并不比一般大学生差（当然有些重点学校除外//hehe)，有时中专生有更大的压力逼迫自己去学习，学历不是重要的，关键是一个人的素质.我们不能将目标定位在做程序员或编码员（Coder)上光会写代码有什么用？那叫“编码员”，在国外是属于体力劳动的，不像国内，会写程序的就叫高科技。重要的是分析问题、解决问题和规划的能力，系统分析，系统设计及项目规划才是正途。这就需要学习所谓的基础课程了，如：软件工程、离散数学、数据结构等等。从vb到现在开始学vc后，一个人捣鼓了几天也没有什么新发现。跟本不知道VC的编程思想是什么，请大虾们告诉我，它和VB的差别真是太大了。VC的博大在于MFC的操纵,它是Win32API的封装.思想在于怎样了解MFC的内幕,它的运行机制.差别也大，差别也不大！这要看你对API的理解了，虽然VC++的可视化没有VB的好，但是不是绝对没有的，其对而且对话框的编辑是跟VB一样的，不过不是像VB那样放在第一个界面罢了，VC++的博大精深是VB难

以望其项背的！：）而且VC++是完全面向对象的编程工具，而

VB是不够完全的面向对象编程工具，VC++是完全编译语言，VB是本地编译语言，不够完全，VC++效率高，封装性好，继承性高，VB效率相对低了很多，但界面友好，二者只能取其一，或者使用VC++，VB辅助(因为VB开发快)，当然Delphi，BCB也是不错的选择。

程序员不应依赖开发工具，程序员更应该拥有的是一种思维、一种精神、一种观念。就像Richard.M.Stallman一样，有自己的精神，为自由软件而奋斗。就像求伯君，为民族软件的振兴而奋斗。这才是真正的程序员。

应该说，他们更注重的不是技术，而是软件的思维，软件的灵魂！！我刚学ＶＣ的时候,还没有上网.身边也没有一个可以问的朋友,所以大部份都是自己啃的.那种感觉真是很痛苦. 现在在网上就不同了,可以得到太多的资料了,而且还可以得到在线帮助.但这些都不是学习的关键. 相信各位也知道ＶＣ的难度,并不是那么容易上手的,所以要想学会,学好ＶＣ,靠外力是不可能的.主要得靠自己. 自己要有一份难得的毅力,对编程的狂热也可以在一定程序上起到帮助.我就是这样的.起初,没有人帮我,我学习ＶＣ是三天打鱼两天晒网,学习进度很慢,幸好对编程的执著,使得自己坚持下来了. 如果你从来就没有接触过编程,那你学习ＶＣ的速度可能会比学过面向过程编程的人要慢一些,因为你要去理解命令及语句的含义.但只要你努力,并且可以得到别人的帮助,我相信在半年内会对ＶＣ有一定的认识. 请学赤面向过程编程的朋友也不要笑,因为面向过程与面向对象实在是区别太大了.就拿封装一词来说吧.当初我是左想右想才想通的.所以不要自己学过编程,就会在学习ＶＣ的通道上比别人轻松. 现在有一种现状应该让我们注意.我发现有很大一部份初学者觉得ＶＣ是一种语言,Ｃ++又是另一各语言.我在和一些初学者的交谈当中,查觉到了这一点.有的初学者竟然还认为我学ＶＣ为什么就一定要学Ｃ++?我想这个问题是我们大家都没有注意到的一个问题.就是向初学者讲述Ｃ++对ＶＣ学习的重要性. 我这有个例子,跟大家讲一下. 我有个同学,他接触编程比我要早,在我还在为ＶＣ中\"::\"符号怎么标记的时候,他已经在学习Ｃ了.后来,我对ＶＣ稍有理解的时候,他也发觉Ｃ的跟不上时代的脚步了.我便提议他从Ｃ++语言学起,可他认为自己有Ｃ的学习功底,根本就用不着再去学习Ｃ++.可在学习ＶＣ的当中,遇到的困难真是数不胜数.最近,他还是去买了一本学习Ｃ++的书.从头再来学习Ｃ++. 我希望通过这个例子,能让广大的初学者知道,Ｃ++对ＶＣ学习的重要性。

学习VC必须有狂热的编程热情，否则是很难坚持下来的，我周围就有几个这样的人，他们比我先学VC近半年，但现在仍然学不会，而我现在虽说不是很厉害，但基本的应用程序是不在话下，我就是天天看书，上机实践，几乎所有的时间都泡在里面，有时连吃饭都在想，为什么，因为我确实想啃下这块硬骨头，我不想半途而废，我觉得学习VC不仅仅是学到了更多的东西，最主要的是培养了我们自己一种坚持克服困难的毅力。 对于VC，我有几点经验： 1。技术为本，语言为次.

2。MFC的单个类有用，DOC/VIEW要小心。

3。OOP要小心，使用不当反而造成大量的工作和糟糕的代码。 4。如果可能，考虑选择使用Delphi(CBuilder+VCL)。 5。到了一定程度，一定要学COM。

要学VC，必须有对C++深刻的理解，对WINDOWS运行机制的深刻理解。尤其想成为VC高手。举例 ， 对于虚函数，不仅要知道有这么一个东东，更要知道它的内存镜像 。这样才能对VC中很多的东西举一反三，事半功倍。本人学习VC近2年，但自觉第一年由于心情浮躁，把VC的书翻了一遍又一遍，却每次都只看了一点就无法再深入。直到毕业前夕，痛定思痛，克服浮躁，认认真真的从最基本的开始学，把每一点都搞的水落石出，经过三个

月的刻苦，终于大成。直到现在，半月搞定COM/DCOM，都托当日刻苦之福，因此劝告想学VC的朋友，一定要顶住开始的艰难岁月。成功属于刻苦者。󰀀

每个人都有自己的学习方法,也许这种方法对我来说有用,但不见 得就对所有的人有用.所以,请不要盲目的跟着别人的学习方法学习,要思考属于自己的学习方法. 但我还是会向大家说出我自己认为比较好的一种方法. 学习编程其实与学习其它东西一样,要想掌握它,就要实践,实践,再实践.当你学到了一种新的技术或知识时,多实践是巩固学习的一种最好最有效的方法. 这个实践不是照著书上的例子做一遍,而是根据自己的能力,给自己出题,然后去完成它.只有这样,你才能发现自己的不足,同时又增加了自己的编程经验. 但要成为合格的程序员,光 会写代码是远远不够的,更重要的是思考.谋定而后动,是 不变的真理.

在我的理解，VC只是一个编程工具，就如BC、BCB、Delphi 一样，其实对于编程最根本的就是三个方面，语言、开发包、 操作系统API，他们三个方面应该说是相对比较的。

VC是MS开发的，所以针对的是windows api，你可以不会C++， 也可以在VC下用C写出很优秀的程序，当然如果你比较熟练C++， 并且熟悉开发包MFC的话，工作可能要轻松不少。所以在我看来，学习的过程可以是这样的：

1、先学习C或C++，在windows的console环境下编写不太深入涉及API的程序； 2、在基本上掌握了语法之后，开始接触简单的系统API，学习 Windows的编程原理和机制； 3、在可以编写简单的菜单程序，可以简单地在WM_PAINT下操作 GDI函数后，开始学习MFC，可以从Step tourist学起，看MFC的源代码，理解几个关键的宏的定义与实现，特别是MESSAGE MAP。 在学习的过程中为了给自己增加点挑战，尽量不要使用resource edit，试着自己编码实现控件的创建，消息的响应。 再就是看自己的造化了，动手做一些小工具，特别是自己平常需要的，对自己的提高也应该是很有帮助。 究竟我们要的是结果！良好的分析问题高效清晰地肢解问题的能力才是我们真正要不断学习的吧？

和学习其他知识一样，重要的是获得提出问题，分析问题，解决问题的能力，不是为编程而学习，你具有什么样的思想，就会写出什么样的程序。学一门语言，不能仅仅是语言，要注重语言背后的思想方法，看他是如何来解决某一问题的，为什么要这样去做，他总是要符合客观事实的，就像人说的话一样，存在某种逻辑，数据的组织，信息的传递，靠你自己的头脑去建立，然后看C++中有什么可以帮你的，该怎么样用他来表达自己的想法。只要你认真实践，努力去做，寻求乐趣，就会达到目标。我虽然 真正认真学习编程的时间不长，但现在我是认真的，就有了以上的体会。󰀀

学习VC++有相当的内容要学，而最后的深度则看个人的悟性与勤奋了。 1）掌握最新标准的C++。(2个月)

如果曾经在大学里自以为学过C/C++,还对dynamic_cast/static_cast/template/try/catch/throw/stl/...感到

陌生，那你该Refresh一下新的ANSI C++标准了。 ----此与VC++无甚关联，g++/bcb均有所支持。

2） 学习SDK编程；:-O （6个月） 痛苦是暂时的，必要的，坚持就是胜利！ 建议用Lccwin32/Masm32/Tasm编写小而精的工具软件； \"Windows Programming Guide.\" \"Advanced Windows programming \"

3） 研究MFC源代码。(6个月) 不要被一大堆的宏所蒙蔽，just track and dig into it!! 在知道MFC如何扩展，包装SDK之后，自可功力渐进，不被其MFC系统框架所困绕。\"MFC Internals\"

4） 研究OLE/COM技术。

COM/ActiveX技术是MS的核心技术，只有彻底洞察其理论精髓才可以体会现在的 操作系统的技术趋势，以不变应万变。 \"Inside Ole 2\"

***几点建议***：

1) Delphi/BCB/VB可以很快构筑界面，但对于想真正学习、理解系统不是一个好的平台，但如果有时间读一读VCL的源码，看看Borland是如何封装系统的，也可借鉴不少。 2) 学习ASM对理解C++有很大益处。Soft-ICE也是和VC++结合在一起的好工具;

3) 语言本身是皮毛，算法是筋骨；无论高级语言如何发展，在理解操作系统的基础上不断自我创新的能力是源源不断的；如果精髓一旦了然于胸，选择何种开发工具都可以驾御，一见如故了。󰀀

每个人学习的过程都会不同吧，我在98从TC转向VC时，对Windows的消息机制一点概念也没有，对着个MFC不知所措，几个月下来一点进展也没有。我于是暂时转向win32位编程。整整一年时间吧，我就是与API打交道，连编辑菜单条对话框等资源文件时也用Uedit32手工编写，为的是希望能对编译器的全过程有个感性的了解。之后我再转向MFC时，果然发现两者是相通的，虽然有一定的区加，不过有了win32位编程的基础再看MFC 时会发现它比win32位编程要方便了太多。 现在市面上的VC书很多，不过大多是入门书。我以为要精通VC（只是以为，本人自已距精通还远的很）应该多看多写程序，看书只能是入门，会用了而已。我不赞成滥用ActiveX，一来我以为它的性能很成问题，真是又大又慢又不稳定（可能是我有点偏激了吧），二来用了它您的程序今后就要被别人牵着鼻子走了。有次我用了个控件，程序都写了大半了，它给我来个继续使用请支付333美元，我两个多月的工钱，烦不烦人？现在我尽可能用别人写的类源代码(我已收集各类代码3-400MB了)，一样用起来方便，还能边用边学，必要时还能自已改造。 我以为在现代的网络时代，资料到处都有，无论什么先进的技术，今天我不会我只要查到资料，快的学上几天慢的一两个月我也能学会，现在已没有写不出的程序了，写不出是因为你没有耐心写完它。我以为现在的程序员不一定要多么聪明，而更需要他有完成枯燥项目的耐心，找BUG的细心，对于金钱的平常心

（不要为了早日拿到钱而赶进度），最后最重要是有顾全大局，团队协作的精神。 最后，王靖朋友的经历与我实在是有点相似，算是同病相伶吧，真心祝您早日实现自已的人生目标！学习VC是一项费时费力的艰苦学习过程。为了真正用好VC，你 不得不先从OOP开始学起，也许浏览一本纯理论的书要更有意思。 你将从另外的角度考察OO思想。接下来学习C++，学习WindowsAPI 学习MFC，剖析MFC，扩充MFC，创造自己的类库（不要企图写一个 和MFC同重量级的类库）。如果能够精通Microsoft C编译器的各种 参数，你就可以开始研究微软C/C++语言编译器的进化历史（结合 各种背景知识）。 掌握了编程的思想，征服VC只是时间问题。󰀀

学习VC是接受微软技术体系的过程。所需要学习的不仅仅是C++，MFC。 需要学习所有

微软的技术，包括Windows编程，Win32系统（实际上 Win32系统实现了很多我们在屏幕上能看到的东西，最起码NT的内核 并不大），COM（深入研究它，理解对象是如何跨越进程边界的，最终 能够自如地在Exe中实现自己定义的接口才算到家了。不过这多少有些 不太必要。），DCOM，ctiveX，Windows DNA... 如果你想成为大拿，学吧，没完没了。最起码，使用VC，你甚至于可以 开发自己的操作系统（当然与MFC没有一点关系）。󰀀