说说我之前的经历吧，大四的时候，学校安排来北京培训java（培训没什么丢脸的，出来找工作我也用的真学历真背景，不像某峰互联），之后我去了培训机构推荐的公司实习，那个时候，工资2k，然而工作也干得很开心，跟着前辈学到了不少东西，当时是做微信公众号开发的，我跟着前辈做微信后台开发，当时使用SpringMVC+MyBatis框架，刚接触的时候，我自己学了挺久才弄明白，后来弄明白之后想想，其实挺简单，对于逻辑开发的程序员来说，你只需要弄懂工作流程就好了，页面怎么跳转，跳转怎么传值，数据怎么处理，这些足够了，当然我是个不满足的人，我会去弄明白，为什么用这个框架、为什么不用别的、用这个有什么好处、如果让我自己来做这个后台、我会怎么搭建？带着这些问题，我会试着自己搭建一下后台框架（虽然前期大部分是复制粘贴）。除了框架部分，微信高级接口也是我研究的重点，我会去官方文档看看微信是怎么接入的，然后研究研究前辈的代码是怎么写的，所谓的干一行爱一行大概就是这样吧，当时我觉得，微信开发，是很有前途的，而我们公司用的框架，也是最先进的（后来看来，确实这个框架组合是当前最流行的框架，而当时，微信公众号也确实是当时互联网行业的一个风口，微信后来把h5带起来了，导致现在一个好的h5前端都是供不应求的，薪资很高）。
说了这么多，为什么后来又转行做游戏了呢？其实是这样的，当时在第一家公司，我的上级打算跳槽走了，带走整个下面的技术，而不带实习生，有那么一两个月，实习生就一直闲着没事做，对于我来说，这样过着就太无聊了，我喜欢挑战，于是我投简历，重新找了份实习工作，在一个游戏公司做java服务器开发，公司挺大的，几年前凭借一款slg页游称霸游戏行业（什么游戏我就不说了，说了就知道什么公司了），后来游戏行业往手游发展，这款slg也出了手游版，这一款游戏，几乎支撑了整个公司，再加上后来出的几款手游，公司发展挺好的，我所实习的部门做的是一款mmorpg手游，从实习做到了转正，做了近一年了，然而这款rpg手游的数据却不是太好，第一次封测次日留存23，第二次26（现在这家公司的游戏能达到80多次日留存），七日就更不用说了，而我也能感觉到，作为一款mmo游戏，玩家之间的交互实在太少，从头玩下来，我觉得这是一款单机，失去了mmo的本质，在项目组准备进行第三次封测的时候，我选择了离开，原因很多，不仅仅因为游戏数据不好，也有一些个人原因吧，不过说实话，是这家公司带我走进了游戏行业，我很感谢，我觉得游戏行业是一个非常有前景的行业，甚至比之前我认为最好的微信开发还要好，游戏行业非常暴利，在这家公司工作就能感受到，策划文档中，充满了挖坑预留的计费点，这一块可以正常玩儿，但你如果充钱，你就比别人牛逼。网络游戏，最重要的，就是控制好平民玩家跟普通玩家的占比以及游戏平衡（当意识到公司的游戏如此处心积虑想要坑钱的时候，我突然明白为什么公司的游戏大多被腾讯代理了，为什么腾讯控股，原来如此，没钱玩儿你**，哈哈）。由此也可以看出，游戏的商业化，已经把游戏公司带入了一个固定的模式——无条件坑钱，我觉得已经失去了游戏的本质，我看过一本书，叫《游戏人生》（当时在cocos2014年开发者大会上买的。觉得挺值的），书已经送人了，但内容我看了一大半，从游戏的产生，到玩家的心理，到为什么需要游戏，这本书都诠释的热别好（我觉得游戏策划都应该看看这本书，做良心游戏，拒绝一味坑钱）。啊，突然发现这一段说的有点偏了，说到底，我也只是做游戏服务器开发的，我也改变不了游戏行业，我只要做好我做的。其实大的游戏公司，就应该走这种商业化路线，凭借几款长生命周期的游戏，支撑公司流水。
从转行做游戏之后，我倒是觉得，游戏开发比web开发有趣多了，当然技术上也比web难多了，之前发过一篇讨论，web开发何和游戏开发的区别，http://gad.qq.com/content/wendetail/7082370，我把我的答案再粘贴一遍（实际上是别人要求我上他的号去回答的，于是我就自己回答了我自己的问题）：
1.从第三方支持来说，web后台有很多成熟的第三方框架，开发者不需要关心底层控制器跳转的实现，只需要一个或几个配置文件，就能完成核心控制器的部分，而开发者只需要关注web自身的业务逻辑，将逻辑与框架融合即可，使用框架一方面简化控制层代码，一方面很好的实现了业务逻辑的分层。而游戏后台开发中，因为各种游戏的需求差异性很大，从网络层，到业务逻辑层，各方面都必须根据自己游戏需求搭建适合自己的框架，因此很难有一些通用的东西能提炼出来一款成熟的框架，游戏后台开发基本上需要自己搭建适合自己的框架。
2.从业务逻辑层面来说，web后台基本上逻辑都是大同小异的，或许这一套系统，稍微改改，另一套系统就能用，而游戏就不同了，每个游戏都有自己的特色，根据策划的不同需求而实现不同的逻辑，不过也会有一些通用的模块，但整体上差异性还是很大的。
3.从数据持久化来说，web的数据基本上是很规整的，表与表之间关系很明确，并且以后也不会有太大的变化，而游戏中的数据多种多样，随着开服之后，数据的变化也是多种多样，甚至传统的关系型数据库根本无法满足游戏数据持久化的需求，游戏中有很多状态和数据是需要服务器来保存的，我个人认为，在游戏开发中，nosql比关系型数据库更实用。
4.从通信层来说，web中的用户都是一个个独立的个体，而游戏中是多人在线的一个游戏世界，在这个游戏世界中，玩家与玩家之间需要进行交互，这就需要服务器实时的向所有在线玩家进行消息广播，这一点很损耗服务器性能的，在这方面，游戏后台要比web做更多的处理，游戏服务器是一个IO密集的服务器类型。
以上便是我当时的答案，或许我的见解尚浅，毕竟我做游戏不到一年，不过对于后台开发这块，我还是有一点话语权的，从实习游戏开发开始，我便经历了一个转换的过程，几乎又是一个从零开始的学习过程，从mina框架到protobuffer，这些东西，我相信web开发很少接触（mina作为网络通信框架，web中几乎只有http通信，protobuffer作为通信协议，web最多用json，其实二者形式上差别不大，但数据大小千差万别）。而游戏的逻辑，也是比web复杂得多，不得不说，web后台成熟的第三方框架是做的真的很好。
经历了上家公司的洗礼，我想我对游戏后台开发有了足够的了解，于是我找到了我现在这家公司，这家公司目前只有我一个服务器后台，做两款游戏，一款是塔防类，准备由单机改成弱联网，服务器存档，并做登录支付验证，另一款，是比较庞大的slg手游，是准备带领公司走上巅峰的项目，说一款slg带领一个公司走上巅峰一点儿不为过，我上家公司就是这样的，凭借一款《xxxx》（哈哈，名字不透露），走上人生巅峰。我之所以接受这份工作，是因为我接受挑战，从底层写起，从架构写起，这是作为一年工作经验的我想都不敢想的，不过这是一个挑战自我，证明自我的机会，我愿意接受这个挑战，人生总会有很多爬坑的时候，但爬过了坑，就真的是人生巅峰了。我接受这个工作的另一个原因，就是公司发展确实不错，以前做的单机，都是很火的（虽然我认为我自己一个人也能做，我也是学过cocos的），而现在公司也准确的把握了游戏行业的风口——slg，coc和cok的成功案例就能证明一切，mmorpg也不一定能做起来了，moba倒是有可能，但你要跟lol做不到80%的相似，我估计没人愿意在手机玩儿moba，slg或许是性价比最高的了。这么有挑战的工作，还要从架构写起，这样的挑战，我喜欢！
说说互联网业的书吧，我认为这个行业的书，分为两种，理论型的和技术型的，所谓理论型，就是长篇大论互联网发展，行业模式等，而技术型，就是类似技术的工具书，是从技能入手的书，这两种书，我家里都有，但我发现买了之后，我很少有时间看，下班没多少时间，北京上班，大多数时间都浪费在地铁上了，上班时间，看看理论型的吧，觉得啰嗦，浪费时间（后来我发现，做这行，除了会技术，你还是需要去看看牛人眼中的互联网的，你需要透过前辈的眼光看世界，不要做IT民工，要做互联网从业者），看看技术型的吧，让别人看见了感觉你太low，所以我大多数时间还是能在网上down到pdf就在电脑看，down不到百度谷歌我要研究的技术，毕竟从事这行，还是用电脑学技术好点，主要是电脑看久了眼睛会疲惫，偶尔看看纸质的书也不错的。而以前面试的时候，面试官经常问，除了大学课本，你还看什么书啊？（如果是你们，恰巧又没看什么书，你们怎么说？），我一般会说，我会自学其他技术，如cocos2dx，然后买一些技术指南之类的书看。我觉得这已经算最大夸张化了，因为大学我真的很少看书，我记忆中就看过一本C++技术类的，一本C#的，一本Android，还有其他几本是什么都不大记得了，大学毕竟十几层的图书馆，除了英语四六级的时候进去复习，其他时间感觉都浪费了这十几层的图书馆。
说说成长过程中遇到的问题吧，如果遇到我解决不了的，以前是先自己百度谷歌，看看有没有办法解决，不行就问老大，而现在，先百度谷歌，看有没有办法解决，没办法在百度谷歌，实在不行还要看框架源码如何实现，上国外论坛看外国友人如何解决，问题总能解决的，总会有办法的。当我开始学习写架构的时候，我会开始关心游戏的网络层使用什么框架，mina还是netty，数据怎么存储mysql还是mongo，是否需要缓存redis存什么，memcached存什么，缓存什么数据，数据传输用什么协议，json还是protobuffer，怎么写效率高，最高支持多少并发等等，我想这些都是我现在需要考虑的问题，当然这些都需要根据游戏具体的需求来决定的，最终服务器能否高效稳定的运行，都是取决于我的架构是否高效稳定，所以这个过程我要不断学习，不断吸取别人的经验。刚到新公司的时候，我才体会到，自己写代码其实也是一种挑战，整个后端我自己一个人实现，代码是否规范，数据如何存储，都是我说了算，我想我的代码不仅要高效，还要让别人看得懂，后来的人能接着我的代码继续写下去。
最后说说Java的题外话，语言之争，从未停过，为什么有人拥护Java，有人拥护PHP，有人喜欢C#，有人喜欢C++，各个语言各有各的优势，业余时间，我也了解了不少其他语言，go，node.js我都有了解，我觉得go的语言层面支持协程并发以及node.js的异步，都是很适合游戏服务器的，我特别看好node.js，异步io真的是对游戏服务器很好的特性，并且加入对原声js支持的mongo模块也是很方便的（上面我有说到，我相信nosql是很适合存储游戏数据的）。说到游戏行业，我认为h5游戏的发展也是越来越快了，上次白鹭的h5开发者生态大会我去了，白鹭的一整套工作流程，以及web vr，真的很令人兴奋（第一轮抽奖我还抽了一个暴风魔镜，哈哈！），另外，大会的模特挺漂亮，哈哈！2015年，互联网行业也略呈下降趋势了，不少创业公司面临倒闭，泡沫经济破灭，因为很多老板抓不住当前经济形势，以为不管是啥，有个app就是创业了，其实全然不知一款app后面有多少运营模式、盈利模式，就像一句讽刺的话，“我有个绝壁好的idea，可以颠覆bat，什么都不缺，就缺个程序员了，等等，千万别告诉马云！”，哈哈，听到这句话，当时我就笑了，估计好多倒闭的创业公司老板都这么想的吧，他们并不能抓住用户真正的需求，只有抓住用户真正的需求，才会抓住用户的心，真正活下来的，才是用户真正需要的，然而，相对来说，游戏行业更是复杂多变，或许今天玩家喜欢这种游戏，明天玩家就喜欢另一种游戏了，就像我们永远也想不到，flappy bird、围住神经病猫这类的游戏竟然能活起来，愚公移山竟然也能让h5游戏变为付费的可能。就像一句话，“只要站在风口上，猪也能飞起来！”，只要抓住了玩家此时此刻真正想要的，产品就一定能做起来。
应该学计算机。软件开发是一项纯智力活动（现在人们都意识到长时间超负荷的连续写程序并不会提高软件生产率，反而会对软件品质造成很大负面影响，所以尽管很多程序员仍然长时间加班，但这种现象正在逐步减少并最终会消失，所以体力要求并不会比其他行业高），如果你不是一个智力高于平均水平的人，说实话，软件开发并不适合你，你基本不可能在软件开发领域取得很高的成就和地位，而且不久就会因为年龄的增长而被淘汰。
如果你以那些开发出共享软件的软件英雄和著名黑客为榜样，立志也要成为他们的一员，像武侠小说中的大侠一样仗剑江湖。我要先给你泼上大大一盆冷水，把你从幻想拉到现实中来。首先，现在的软件其复杂度和规模都远远超过以前，想一个人独力完成一个规模稍大的软件，基本没有可能（虽然还是有些特例，but trust me，那些仅仅是特例，请不要把自己想像成独一无二的超人、幸运儿）；其次，无论是软件英雄还是仗剑江湖的顶尖黑客，他们的软件开发功底和智力都远远超过软件行业从业者的平均水平，没有多年的积累和坚韧超常人的毅力，是不可能，换句话说，想成为他们的一员，可以，但请首先成为一个合格的软件开发人员。
如果你是因为传说中程序员的所谓“高薪”，对自己现在从事的工作不满意，而萌生转行的念头，我劝你还是再慎重考虑一下。程序员的待遇一般来说，是要比平均水平高一些，但远远谈不上高薪，而且以现在程序员的工作量来算，其实同样的付出，程序员所得到的能和平均水平看齐就不错了，程序员的竞争和淘汰也是异常残酷的。技术的更新速度更是其他行业所罕见，每个程序员都要不停的跑步跟上，不使自己落伍，所以在这个层面上来说，没有谁可以停下来休息，唯一能够积累下来的就是你的经验，但经验中能够为你的竞争力增添筹码的并不多。
说了这么多，并不是我故意贬低，而是希望告诉你我所知道的软件开发行业的真实情况，基于此请再慎重考虑你是不是真的要迈入软件开发领域。
返回页首
检验一下你是否适合当个程序员
在我看来，要做一个合格的程序员，你需要具备下面几个条件：
1. 强烈的好奇心和求知欲
2. 追求完美的精神
3. 良好的逻辑分析能力
其他方面的条件几乎所有类似的帖子都有提及：如果你不是准备单打独斗，那么团队合作能力必不可少；英语我就懒得说了，没有基本的阅读英文资料的能力，我劝你还是打消做个程序员的想法，没有为什么；数学能力也是必不可少的，如果不是做算法，高中水平的数学能力就足够了，但一定要成绩很好才行。
那么为什么我要强调上面列的三点呢？
具有强烈的好奇心和求知欲，能够让你跟上技术发展的步伐，仅仅靠危机感和责任感，你对技术的学习会有很强的功利性质，导致你的技术体系不能构成一个完整自包容的整体，而且很难对技术有高层次的认识和掌握。
我认识的一个资深系统设计师跟我说过：做软件，“做出来”和“做的好”完全是两个概念，所要求的投入和技术水平是天壤之别。现在国内很多程序员仅仅把软件开发当作养家糊口的谋生手段，国内计划经济时代凑合、马马虎虎干活的思想也渗透到了软件业，很多程序员仅仅是把功能做出来，根本不会去考虑提高重用性、可维护性，也不会去考虑提高稳定性、运行速度，甚至连代码也是乱七八糟，基本的编码规范都不遵守（在我看来，这样的人不配“程序员”这个称号），在我们大声谴责国内软件业环境不好，拉项目靠关系，没有质量保证体系，老板不重视程序员，疯狂剥削程序员的时候，我们是不是该问问自己，你是不是只把眼睛盯着别人？
现在各种软件开发包应有尽有，包罗万象，编程工具也异常强大方便，对于国内占主流的MIS系统来说，要完成一个功能实在不是很难的事情，但是如果把系统做为一个整体，则大多数都是运行缓慢、占用资源过大、兼容性差、可维护性差、不稳定的系统，你可曾尝试过开发一个优秀的系统，如果有，你就会发现开发优秀软件是多么困难，对技术的要求是多么高，而你在努力做到完美的过程中水平的提升是多么快。没有追求完美的精神，无论外部环境如何好，你也是不会开发出优秀软件的，等待你的是无休止的修改和维护～，你的技术水平也永远停留在简单的编码阶段，最终只有被迫转行。
返回页首
好了，我真的适合当个程序员，那我该如何开始？
首先选择一门编程语言和操作系统平台。
操作系统平台国内比较流行的基本有Windows、Linux（Unix）、Mac OS。一般来说大家都选择的是Windows平台，因为此平台是国内处于垄断地位的操作系统，而且有很多优秀的开发工具可供选择，缺点就是Windows平台的开放性不高，往底层探究比较困难（但我对于言必称底层的观点比较反感，不是所有搞开发的都要对底层非常了解，做出用户满意的系统才是我们追求的根本，玩些底层的trick只是一种自我满足罢了。当然我们需要有一些掌握底层技术的高手，但这个是个人选择的问题），而且用惯Windows的程序员在配置、脚本等方面比较弱。Linux是开源平台，当然从理论上你可以操纵Linux的一切，但是有几个人能够达到这一水平？刚刚开始学习开发的程序员，在Linux上也仅仅能够开发一些应用软件罢了。Linux下的开发工具不够人性化，但这种情况正在逐步得到缓解，Eclipse就是非常出色的开发平台。在Linux下开发，你可以得到大量优秀的源代码，并且一切都是透明的（只要你想），但你必须学习很多命令行指令，掌握各种系统和参数配置以及脚本方面的知识。
编程语言的选择更是令人头痛，我涉猎不多，对于有些语言，我无法给出任何建议，只好等这方面的高手来给大家补充了。我仅仅对C++和Java进行一些说明，当然这个也仅仅是基于个人体会，绝对不是权威观点 :P
C++仍然是目前占主流的开发语言（详细的可以阅读TCPL中的相关论述），而且一种语言的发展或消亡都是一个渐进的过程，在可以预见的将来，C++仍然是一门举足轻重的开发语言，但其所针对的领域和方向可能会有所调整，我认为最主要的变化是C++会逐步从商业MIS系统市场上退出。选择C++的理由是关于C++的优秀开发书籍和开发工具最多，相关的资源也异常丰富，待对于一般应用程序的开发掌握之后，无需过渡，就可以深入学习各种技术，因为现阶段讲述系统底层奥秘和高级技术的书籍，基本都是选用C\C++做为示例语言。加上微软精心打造的开发平台Visual Studio或Borland的C++ Builder系列，学习起来更是如虎添翼。但C++现在的缺点也是比较明显的，我最深的感触就是对于XP和Agile Development的支持不好。
Java简化了C++的语法，学习起来比较容易（但随着Java的日益普及和发展，是否能够继续保持这一优势，我不敢断言），Eclipse是非常优秀的Java开发平台，支持XP的整个过程：设计、测试、编码、重构……现阶段敏捷软件开发的主要语言就是Java。而且Java的跨平台特性更是非常大的优势。
实际上，选择哪门语言都没有关系，根据你的发展规划和目前身边的环境选择就可以，没有必要跟风，其后的坚持才是难点。
好，假设你选择了C++做为开发语言，在Windows平台上开发，那么我给你如下的学习建议（其他的选择请各位积极补充……）：
C++语言的学习当然是基础，这个阶段由于没有任何在特定平台上的开发经验，我们只能按照书中的例子一个一个输入运行，暂时告别熟悉的图形界面，回到古老的DOS了。参考书的选择是这个阶段很多朋友关心的，Stan Lippman的《Essential C++》和《C++ Primer》是我优先推荐的，而《Essential C++》因为篇幅较小，讲解内容适当，而且对C++ STL的运用有不少描述，显得相当实用，我认为最适合初学者使用。无论选择了那本书做为入门教材，都应该逐个例子逐个例子的消化，不要贪快，但同时要对重点内容有所侧重。我们学习任何东西都是为了解决实际问题，所以请把重点放在我们实际中最常用的部分，而不要过多的追究一些细节和艰深晦涩的不常用技术。
此刻我们会碰到很多过后看来非常简单幼稚的问题，比如为什么编译出错，为什么按照书中的例子输进去却无法通过编译，找不到头文件等等，大体上这是因为刚刚接触程序开发，对程序理解还很初级，以及对于所使用的开发环境不够了解，特定编译器对标准C++的支持程度不一导致。请多阅读关于所使用开发环境的各种文档，以及查阅帮助文档。以我最经常使用的Visual C++配合MSDN来说，当出现一个我不能理解的编译错误时，按F4键编辑器就会自动跳到当前错误地点，下面的输出窗口也会给出错误代码（比如C××××），把错误代码记下，打开MSDN，在索引一栏输入错误代码，就能够查到详细的关于此错误的说明，当然，是英文的（不要问你不会英文怎么办，这是基本要求）。现在的开发工具查错排错非常方便。当然，有时很多错误原因并不是编译器所提示的地方，而是往前或往后一些地方，长期的编程经验可以提高查错速度。此时也请多练习练习Debug技术。
此阶段只要能够掌握C++的基本语言要素，对结构化程序设计和基于对象的设计有一定理解，能够完成一些简单的小程序就可以结束了，毕竟DOS程序现在很难勾起我们学习的欲望了 :P 在此之后可以视自己的情况决定是否学习数据结构，数据结构是程序员的必修课，不可或缺，地位非常重要，即使你现在希望马上进入图形界面程序开发的世界，这一课我也提醒你记着早点补上。
终于可以迈入图形世界，我们要从SDK编程开始，不要担心，这不会花费你太长时间，但却是对Windows程序运行机制进行深入了解的好时机，在此的努力都不会白费（trust me），此时的参考书没有什么好考虑的，基础的有Charles Petzold的《Windows程序设计》，进阶的有《Windows核心编程》。请从《Windows程序设计》开始，Charles Petzold的书通俗易懂，学习起来非常轻松，而且对你的语言要求不高，只要懂C就可以了。
此时容易碰到的问题大多与项目设置有关，如果使用Visual C++，请按Alt+F7调出项目设置对话框仔细检查，并阅读相关文档，熟悉各项配置的意义。
此阶段请重点掌握Windows SDK程序的编写方法，Windows程序的运行机制和Windows消息机制，和常用的Windows API。我们还可以更进一步：尝试用前一阶段学到的C++知识对过程化的SDK程序进行初步的改造，将我们敲入计算机的程序变得可重用，按照自己对基于对象思想和面向对象思想的理解来重新编写例子程序。
OK，现在你已经初步入门了，掌握了C++的基本用法，对面向对象有了一点模糊而自以为是的认识，也能够写出Windows程序了，虽然还有点简单，还有点丑陋，不过，总归是图形界面啊。开始有点感觉了，是吗？ :P 别急着往前冲，停一停，将C++和Windows SDK的基础打牢，贪多嚼不烂吗。此时有很多经典书籍等待你去掌握，也有几乎无限的题材供你练习，请尽量多阅读接触下面的资源：
• 《C++ Primer》
• 《Windows核心编程》
• 《应用程序调试技术》
• 面向对象开发设计方面的书籍
• MSDN的Platform SDK部分，Periodicals部分（包含了大量有价值C++、SDK方面的技术文章）
• CodeProject里相关的源代码是很好的补充学习资料
现在继续往前走吧，利用SDK开发毕竟有时太过于费时费力，还是使用更高级的应用程序开发框架的好，主要的有MFC和VCL，关于这些框架谁好谁坏的争论我已经听烦了，一句话，能帮助我们完成任务就行，它们无非都是工具，你自己随便选择吧。不过选择好之后，你应该明白，对于你的工具，了解越深，越能发挥它的威力。如果你选择了MFC，我建议学习下面的书籍：
• 《深入浅出MFC》：关于此书毋庸多说，尽管有人不停的贬低，但它的地位是无可置疑的，而且也是对我最有帮助的书籍之一。
• 《MFC程序设计》
• 《Visual C++技术内幕》
然后就停止找书吧，网上开发站点的数不胜数的源代码就是最好的老师了……
返回页首
学习过程中碰到问题我该怎么办？
我始终认为学习软件开发过程中遇到的问题只有自己尽最大的努力去解决，才能收到最大的成效，对于那些动不动就把问题发到网上指望高手帮你解决的做法我非常不赞同，因为这样你并不能从中学到多少。我建议的做法是，首先尝试自己独力解决问题，花几个小时解决一个问题，是很正常的，不要几分钟解决不了就放弃了；实在无法解决的时候，请尝试尽量减小涉及范围，将问题归结一下，初步形成自己的结论；然后利用搜索引擎或者开发论坛中的搜索功能来搜索是否有对于自己问题的解答；实在没有的时候，再发帖子求助。请了解一点：你遇到的问题都是别人遇到过的，网上肯定有现成的解决方法（因为你还没有到开发研究前所未有的问题的水平:P），只看你找不找得到了，请尽力去利用现有的资源而不是麻烦别人。
CSDN的论坛、MSDN在线文档都是非常好的资源，基本上我们遇到的问题在这里都能找到解答。
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）