一、掌握基础知识：十六年寒窗的持续积累

计算机组成、操作系统原理、汇编语言、数据结构、编译原理、数据库原理、软件工程、结构性设计语言(PASCAL、C)、面向对象设计语言(C＋＋、C＃)、计算机网络等，你最好还懂一些算法分析、分布式系统、计算机图形学、形式逻辑、人工智能原理、软件设计模式、软件构架/框架等研究生的课程。

二、在实践中提高：成为一名高水平的Coder

通常，你在工作中都会用到某一种单位/公司固定的操作系统和编程语言开发环境，比如Windows、UNIX、LINUX等操作系统，又比如用VC、VB、 PB、Delph、JAVA、Motif/XWindow、QT、OpenGL、OpenInventor等编程语言和开发环境，我们在后面把它们合称为开发环境。
其实你既对又不对，对的是单从使用的角度而言，你确实用不上开发手册的大多数内容，比如庞大的VC开发类库和复杂的开发环境，你在实际工作中能用到的不到总数的1/10或1/5。不对的地方在于，你用到的部分不是孤立存在的，它们是整个体系中的一部分，只有对整个体系有了一个较完整的了解，才能得心应手、随心所欲地用好你用到的部分，你才算初步具备在这种开发环境下进行Coding的职业水准(还远不够程序员的职业水准呢)，而这只是刚开始。

1、开发指南/教程、参考手册

如何才能真正掌握一种开发环境的全面的知识呢，最原始的办法就是读（1）开发指南/教程、（2）参考手册。

一般来讲，学习开发指南/教程时，你如果是一个认真的人，都会完成5/10~7/10左右内容的学习和练习，如果你想成为职业选手，就应该完成9/10以上内容的学习和练习。

参考手册不同，大多数所谓的“程序员”们只是用到了才翻翻，这差的太远了，你应该象读开发指南/教程一样，每个环节都要读，比如VC，参考手册中的每个类，类的每个函数，都要读上几遍，它们往往是一小伙一小伙地纠缠在一起使用的，开始时读得你毫无头绪、心烦意乱。不要紧，还有一手呢，如果你开发环境安装的全面，它们往往都有开发商做的demo例子可看，你就进入另一个境界了。

开始时你关注demo中的具体技术，后来你发现这些demo的程序写的都还算不错，结构简单但合理。如果你真的用心，就一定能发现一些个别的demo是极品，它所展现的程序逻辑结构你是设计不出来的，你现在有点更关心它的程序设计构架，甚于对你原始目的（某种相关的技术/技巧）的关注。

这时的你，开始了从一名Coder向一名Programmer的转变，你会忍不住要看看开发商提供的源程序，比如.h和.cpp，通常你会找到include路径下所有的.h程序，你才知道，哇！好多好多东东在参考手册中都没提到，你要学的太多了，没时间顾及其它的业余爱好了。

现在知道为什么程序员是年轻人的职业了吧，你要有足够多的时间才行，即使你的智商有160。如果你走到这一步，在你工作的团队中，已经是经常有人向你请教技术问题，经常有人请求你帮忙debug，你已是公认的“高手”了。

别得意，因为你仍然是个Coder。为什么这么说呢，你想想，你已深入了解了这个开发环境中的各种技能，知道一名Coder如何用好这些东西，可是你能设计的出提供给Coder们用的东西吗？唔……，你想了想，可能还不太行。对了，就是这样，你还是一名小我境界的程序员呢，本质是个Coder，当然已是一名高水平的Coder了，然而你需要进一步登堂入室才能成为一名真正的程序员。

2、两个挑战

让我们继续吧，通常你都是从精通一种编程环境开始的，假设你已经较为精通在Windows下用VC开发软件了，这时在技术和技巧方面你将面临一小一大两个挑战。

第一个小挑战是如果公司/单位改换了开发环境，比如用LINUX下的QT交互语言工具进行开发，你不过是把前面掌握VC的过程再来一遍，由于在主观上经历了VC工具的学习过程，在客观上各种开发环境都有太多相似的方面，这回你掌握的应该较快。

要小心，在这时第一次诱惑之门打开了，因为你感觉良好，看！这回这么快，我就这么好地掌握了新的开发环境，你开始关注其它暂时还用不到的同类环境，比如VB、Delph、JAVA，如饥似渴地掌握各种开发工具，证明自己的学习能力和价值。

但你忘了一点，你仍然是个Coder，只不过是一个在好多开发环境下都能编程的Coder，就像你生活在中国，因而精通了汉语，工作需要你又掌握了英语，然后你就来了劲，把俄语、日语、阿拉伯语、拉丁语，等等等等，都学习个遍，我只能说，有点BT。你忘了自己是个职业人，同一类的东西工作中用得到才需学习。太多太多的Coder们喜欢在一起比较和炫耀自己会掌握了几种开发工具，不信你看看招聘时的求职书就知道了，sigh！他们中绝大多数人永远都只能停留在这个层次上，心浮气躁，一生都再也当不成真正的程序员了。

总结一下，其实你在这时需要的是对自己掌握新开发环境的能力的自信，而不是一遍遍地重复来证明自己。

第二个大挑战就是你明白了只掌握VC是不够的，你发现自己有点浅薄，有很多东东你会用但你不太懂，很多方面支持VC编程的知识你都没掌握，比如操作系统的源码、网络协议知识、Windows 的注册表、进程和线程的基础知识、硬件驱动方面的知识、ActiveX、 Windows 庞大的 API，又是一个等等等等，这些基础知识的学习和掌握可是要花费大量时间的，你再一次深切地感到时间太不够用了，因为这时的你大概有许多俗务缠身了，所以有点沮丧，还不用提IT业每天不知有多少新东西在发布，永远都跟不上，越拉越远了。哎！

别气馁，振作一点，你还是忘记了自己是个职业人，既然好多东东在工作中你永远都没机会用，那么干嘛要学呢？用什么才学什么，最多预测到马上要用什么，先一步学什么好了，要知道没有人是真正的、无所不精的全科大夫，除非你是神，但如果你还在耐着性子看这篇文章，你肯定是个人嘛。

OK，一般工作后三五年，你经历了上述过程，经受了诱惑和考验，终于明白了一个道理：你要的是强劲的学习知识的能力，是对某种软件知识/技能的有深度的精通，一种摸到它的根的深度，而不是已掌握的技能的种类和数量。这时无论谁用他掌握了多少种你不会的技能来吓唬你都没用，你对他的层次只有蔑视。

通过几年的学习和工作，要记住最重要的一点，永远最重要：对自己学习IT知识能力的自信，一个程序员一生都要不停地进行高强度的学习，用心问问自己，有没有这个自信？别用虚荣心来骗自己哦，如果没有的话，那就不必花费你宝贵的时间向下看了，作者在此感谢你有耐心看到这里，现在建议你关闭这篇文章，趁着年轻，当机立断转行吧！

三、注重逻辑：成为一名职业程序员

我们在前一节提到过，“你发现一些个别的demo是极品，它所展现的程序逻辑结构是你设计不出来的，你现在有点更关心它的程序设计构架，甚于对你原始目的（某种相关的技术/技巧）的关注”，其实你是在关注这个demo程序作者的思维逻辑，所有程序的本质就是逻辑。

技术你已经较好地掌握了，但只有完成逻辑能力的提高，你才能成为一名职业程序员。打一个比方吧，你会十八般武艺，刀枪棍棒都很精通，但就是力气不够，所以永远都上不了战场。这个力气对程序员而言就是逻辑能力（其本质是一个人的数学修养，注意，不是数学知识）。

逻辑能力也是逐步提高的，开始时你一定是用直观的逻辑能力来编程的，怎么想就怎么编，不对就再改，在改进中提高自己的逻辑能力，从直观逻辑能力提高到抽象逻辑能力，这是很正常的。提前说一句吧，到达逻辑能力的至高境界，其表现是用数学语言来描述问题和问题的解决办法，高度抽象！好，说回来吧，你要提高逻辑能力，最快的办法就是读别人写的结构优秀的程序。优秀的代码是百读不厌的，暂时放放对其中某种技术和技巧的关注吧，你要推导和学习的是这些好程序的逻辑结构，它们是被精心设计出来的。你可以先捂住这个demo程序，自己设计一个功能相同的程序结构，然后比较一下demo的程序结构，如果差距较大，那你就不应简单地改进一下，而是要把demo作者设计的过程在心里复原一遍，做到这一点也许有点困难，但这种事干的多了，你就会越干越快，越来越得心应手，你的逻辑能力飞速提升，你能看得上的逻辑结构优秀的程序开始不多了，下一步就是练习。

从工作中开始吧，如果你有空闲，你需要做至少两类练习。

（1）一类是算法练习

所有的经典算法都是经典的逻辑。题目有的是，像个好学生一样吧，每年的国内国际编程竞赛都有逻辑要求非常高的题，你可以只选一两道难题来做做。当你可以把复杂的单递归程序（只有A调A）变成非递归程序时，已经不错了，如果你能看得懂双递归程序（A调A、A调B、B调A、B调B都有），我为你鼓掌！你不必往下看了，我有点不好意思班门弄斧。

（2）另一类是把以前和当前你工作中你不满意的程序推倒重新设计一遍。

这非常重要，省时省力，因为你熟悉需求，技术上也没问题，目的就是改进程序的逻辑结构，很划算。唯一要克服的就是：你对推翻以前工作中那点小小成就的心理障碍，如果你真想优秀，这点心理障碍算个屁，一遍遍反复地推倒已有的成果只能使自己快速进步，放手干吧，没什么好可惜的，“在这个过程中，你失去的只有锁链(禁锢你思想的锁链）”。

在这个过程中，如果你能注意以下一些小的方面，你前进的步伐也许会快一些。

从编译原理的角度来理解你工作中使用的高级语言。

如果你做到这一点，至少有两个好处：

第一个好处是避免一大堆低水平重复出现的编译错误。一名优秀的 Coder平均在一个工作日中应该完成200行以上的源码，其编译错误应该控制在5个以下，要知道这200行源码不是一次完成的，所以大多数情况下你都要追求一次编译通过，而一名职业水准的程序员，应该进一步做到即使用purify这类的工具来检查源码，也不会存在严重的内存泄露。

第二个好处是可以提高源码的可读性和效率。规范地编写你的代码使你自己的逻辑清晰，因为你明白多加几个括号和空行、多换行对齐、多注释，编译器是会自动识别的，不影响程序执行的效率，反过来，控制好递归调用和循环内的if语句才是提高程序效率的关键，要全力避免递归，但要深刻理解递归，能通过自己建立堆栈来把递归程序转换成非递归程序，要求还是较高的！

避免思维陷阱，只要是人，就一定有自己的思维惯性，这一定又会表现在你的程序逻辑中，有时你就是从这个惯性中跳不出来（谁都有这个时候），但要心里有数才行。所以，你需要帮助。如果你有几个水平相若或更高的职业伙伴，太好了，当遇到花30分钟还打不下的bug时，就别浪费时间了，找他们吧。最要紧的是能思路清晰明确地表述你的问题，通常你自己在这个过程中或者伙伴中就有人把问题解决了，又快又好。另外，有几个可以良性竞争的职业伙伴是人生的一件幸事，1+1>2，大家各有所长，你最好做到及时公开你的成果，技不压身嘛，IT发展的这么快，你再优秀，那点东东也没有什么值得隐藏的，所以你可以技术或水平不够高，但千万不可以让真正具有职业水准的选手鄙视你的职业品质和行为。

有自己debug的特点。

下面的说法作者不敢太肯定，只是经验之谈。即使在VC这种高度完善的开放环境下，你仍然应该要求自己仅凭打印语句就能 debug。这也有两点好处。

（1）第一个好处是遇到bug，你会认真想问题所在，而不是用debug工具一步步简单地追踪卡在哪儿了，你定位bug范围的方式是从大到小、从粗到精，这是一种自顶向下的思维方式，而用工具追踪，容易形成自底向上的思维方式，这不算好，你应该先看到森林，再看到树木。

我反复提及：程序就是逻辑过程，大多数程序从main函数开始，是由数据结构和功能子程序组成的一个树形结构的逻辑过程（要认清即使是面向对象的程序语言也是一样的），它的执行过程是深度优先的，但你定位bug应该是广度优先的，好好想想这一点。

（2）第二个好处是强迫你思考并记住而不是用工具看到调用过程，你大脑的抽象逻辑思维能力和胳膊上肌肉的力量一样，都是练出来的，如果你的bug是程序结构上的逻辑错误引起的，这一点就非常重要了，顺便说一句，最难打的bug就是程序逻辑结构错误导致的bug。你要是真正明明白白地认识到这儿了，那我就没什么东西可以告诉你了。

总之，程序员的职业水准：生产效率和程序质量，主要是取决于源码中bug的数量和debug的速度，而不是取决于编写源码的速度。给你一个我自己定义的考查一个职业程序员的指标：

一个合格水准的职业程序员，编程的时间如果算一份的话，其累计debug的时间不能超过一份，真正职业高手累计debug的时间应该控制在0.5份以下

你关上门悄悄问问自己，你花费在编程和debug上的时间比例是多少？如果你把程序员作为自己一生的职业，那么就永远都要牢记一点：追求做一个0 bug的优秀程序员！这是任何一个想成为职业程序员的人的理想，请相信：坚忍不拔地追求实现这个理想将让你出类拔萃！

做好程序的单元测试，这是另一项考查你是否是一名具有合格职业水准的程序员的一个必要指标。

其实在你拿到需求的时候就要准备单元测试用例了，并且这些用例将直接影响你的详细设计（有关软件设计本来是该放在第四节讲的）。

我们还是打比方吧，当你拿到一个需求时，除了分析它静态的功能外，还应明确它动态的操作/执行过程，把这个动态过程明确地用流程图画出来，比如分为A～Z的26步，其中A又可以进一步分解为A1～A5的5步，直到不能再分解为止。又比如说A3步不可分解了，那么你应该把A3步的正常操作和所有五花八门的异常操作都列出来，确保正常的操作肯定正确，异常的操作起码程序不退出才行。

这样你就要写好多好多的测试用例，说句老实话，我也从来不写！但我一般会列一个提纲，比如A3步有正常的操作a、b、c、d、e共5项，异常的操作有f、g、h、i、j、k、l、 m、n共9项，你在进行单元测试时都应该跑一遍，这样的程序都还不敢说质量如何好，但起码可以说较稳定吧！

如果要想在进行单元测试时干得快、效率高，那么在进行详细设计时，你就应该把A3步中对所有正常操作和异常操作的判断都设计好，在编程实现A3步时，使得程序的结构合理高效，对不对？所以，如果你在工作中是割裂地看待软件工程中从需求、分析、设计、编程、测试等各个环节，恐怕水平很有限喔！但如果你在分析需求时就能看到测试的问题，并改进设计和实现，为此做好相应的准备工作，嘿嘿，整个软件开发过程你的效率会高很多，通常你在一个开发团队中就会高度自信的，你已越过当一名偏颇、露骨的高手的境界，成为一个平静的高手，这可是The best in the best！，用周星星的话说：是高手之高高手，因为别人看不出你高在哪儿，没见你有什么高招或特拚命干，但反正你就是干得又快又好、又省力。

关于进行单元测试还有很多复杂的方法，在此本文只提到了最基本的一点，目的是让你在工作上考虑周全、安排有序，其它的自己琢磨吧，没有人能替你吃饱饭！

如果你是用C＋＋编程，我再简单谈谈有关内层释放的一个小技巧，就是对所有你编写的类，在构造和析构函数中加打印语句，统计每个类在运行程序时构造和析构的地方，如果是配对的，那么起码没有对象类一级的内层在程序运行结束时没有释放，然后你就可以把打印语句删掉了，招数虽土，但管用！

还有其它一些好习惯，在这里我随笔写一些，你要是有不同看法也请一笑过之吧。

编程时应该对齐缩进，一个缩进用一个tab键，一般是4个空格，严格遵守开发团队的编程规范也是非常重要的。一个子程序不应超过 30行（不算空行），其内多重循环不应超过3层，否则都应该分裂成两个子程序，个别算法程序可以长一些，但也不宜超过200行。通常一个类的所有成员函数总和不宜超过1500行，多了就应该考虑分解成两个类（这个工作最好在设计时就完成）。

每完成一小段程序，比如15～30行，就立即编译运行，不要假装高手，先敲它一大堆程序，再编译运行，妄想一次成功，体验一种假爽的、虚荣的快感，或炫耀给别人看，这么做只能证明自己是一个不折不扣的傻瓜，装酷而已。因为只要有一次不成功，你就会花费大量的时间来调程序，别人的进度在这时就远远地超过你了，平常心是道，还是修炼真功夫吧！孙子兵法里关于这一点有明确的阐述，我就不引用了，但建议你真的不要这么干，除非你确实就是这样总是一次就成功的天才，那你还看这篇文章干什么呢？我又不是写给你们这些天才们看的。

再就是有学会买好书、读好书，关于计算机和软件方面的书太多了，时间有限，比如有一个叫侯捷的家伙，几乎写的每本书都不错，张国峰的C＋＋编程也不错，这只是我的个人意见啊，好书多着呢，列出来比这篇文章长好多倍，我就不多说了。

还有一招，要是你运气好，能搞到一些著名软件系统的源码，好好读读吧，在此我只能告诉你，Linux操作系统的一些源码不错，是开放的，你可以合法地搞到，其它的不要说是我建议你侵犯知识版权啊！

四、天生神力：成为系统分析员

你要是运气好，直接进入了一个严格规范生产的软件企业就业，刚开始就应该是按别人做好的软件设计来实现编程，你可以有机会直接学习软件设计。当你积累的足够多了，能够对其中的一些设计提出好的改进建议，而且干得又快又好，就会渐渐地展露头角，我相信你终有一天成为一名软件设计人员（注意，不是软件产品设计人员），步入系统分析员的行列，但这还需其它的一些条件和自我修炼。

如果你在一个不规范的软件企业工作，那也不错，你很可能直接就有机会进行软件设计，然后开发、测试，甚至还不得不自己定义需求，把软件开发过程的各个环节走一个遍，当然这样对你的要求更高，而且你也不容易得到及时有益的指点，在正态分布的情况下，你应该是成长的很慢。但不管就业的单位如何，如果你决心要成为顶尖软件职业选手，通常什么客观困难都阻挡不了你，然而你个人的因素可能会阻止你的前进。

作者自己没有到微软面试过，但身处软件行业，关于微软的许多东东当然还是有耳闻的，据说微软招聘一名程序员要过五个已经成为微软程序员的面试关，而且是一票否决制，又据说大多数面试题并非编程，而是一些有关逻辑和智力的题，作者私下也做过许多流传的微软面试题，并对此做法深以为然。程序的本质就是逻辑，所以几十年前就有人提出编程是一门艺术，而艺术是要靠天份的，这一点少有人反对。一个人的逻辑能力可以不断提高，但其能到达的终极逻辑能力的层次必定为其天生智力所限制，这一点就让人不易接受了。

在工作中，你基本上遇到的是两类方式的设计，一个是结构化设计，另一个是面向对象设计。就个人经验而言，面向对象的设计更好。

金大侠在《倚天屠龙记》里讲到张无忌初学太极，学会的标志是把刚学的招数全忘了，记住的是太极的道理和精神，和李小龙有些相似喔，软件设计也一样，忘记所有的设计模式，随心所欲进行设计才是至高境界，所以你能到达多高的软件设计的境界最终将取决于你的哲学素质，这一点实在是不好写啊，你自己领悟吧！作者只有祝福了！

五、职业人的终极目标：全面修炼，成为Leader

这一节更不好写，涉及到太多其它非技术方面的因素，特别是个人人生观和世界观的修炼。如果本帖的点击率超过作者私下期望的一个数值，那我就争取尽力厚着脸皮再补上吧。我只说一句，虽然大家都知道软件开发是一个团队性的工作，但追求参与一个大型软件系统的成功开发，是一名软件人员的本能，就像拿破仑说的不想当元帅的士兵不是好士兵，所以不追求实现大系统的软件人员，也不是一个好的职业软件人员，但你只有成为Leader，领导一个优秀的软件开发团队，才有机会实现这个终极职业目标，对不对？