做为技术道路上的过来人，我也分享一下我的体会。简单来讲，成为技术大牛虽然有难度，但其实也没那么难。要成为任何一个领域的专家，你需要做的是学会该领域的已有知识，所以你只要学习就行了。真正有难度的事情是创新，是利用已有知识和技能创造出人类还不知道的有价值的东西。

如何学习专业技能？我自己总结了一句话：“技能学习这件事，有技巧无捷径”。有技巧是说，并不是说你花了很多时间，技能就一定会提高的，这里面有方法论的区别；无捷径是说，即使知道了技巧，不下功夫也是不行的，正所谓，纸上得来终觉浅，绝知此事要躬行。

拿我自己来举例子。我在上大学之前从来没有接触过PC，甚至都不知道有个人电脑这种东西。操作电脑、编程这件事对我而言完全是零基础，自学成才。由于对计算机有强烈的兴趣，从大一开始，我花了很多时间学习编程（当然也花了很多时间玩电脑游戏），诸如个人电脑操作指南、打字法、Windows用户手册、微机原理、Windows/Unix操作系统、各种C/C++编程书籍（Turbo C、Borland C/C++、Visual C++），我看了一大堆书，也写了一些程序练手。直到大四，我还是觉得很迷茫。一方面感觉自己学了很多东西，另一方面又觉得好像什么都不会。具体点说，如果让我写个编程作业，问题不大；但是如果让我写一个有完整功能的应用程序，干不了。换句话说，我的水平可以应付学校里的作业，但是还没能力做真正的产品开发。

这让我很焦虑，不知道毕业怎么找工作。当时我的想法，是找一家公司实习，工资多少无所谓，一定要能锻炼技术。我选择的公司是一个创业公司（现在不存在了），同学推荐的，领导和技术团队都很牛。我的面试很糟糕，人生的第一场面试，几乎所有问题都搞砸了。领导看在推荐人的面子上把我留下，工作内容是组装电脑和安装各种软件，跟电脑城里卖电脑的差不多。由于在大学里装过无数次电脑，我干的不错。印象最深刻的一次是有一回别人刚攒好的电脑系统（SunOS 4）启动到登录界面时出现花屏，鼠标滑到哪儿花到哪儿。领导让我判断是什么问题（他技术很好，其实在考验我），我说可能是因为显存不够，换一块有两兆显存的显卡试试。换显卡后果然好了。

大约是从那以后，领导开始让我参与软件开发。我写的第一个商业程序是一个应用网关，把一种医疗仪器集成到我们自己开发的医疗信息系统。由于后来需求的不断扩大和我本人的完美主义倾向，这个软件我重写了三遍。最开始很普通的一个模块，最后可以做到可以方便地接入各种新设备（不同厂商、不同种类），也因此变成了核心模块，产生了独特的商业价值。有的项目中公司拿出来单独卖，也专门为它申请了专利保护。

这两件事我学到的是，做任何事情都要用心，要非常关注细节。看起来不起眼的、繁琐的工作做透了会有意想不到的价值。从技术角度，我也学到了很多东西。比如，如何用RS232和设备通信；如何写一个TCP服务器；如何写一个独立的Windows应用程序；如何把一个普通程序做成Windows NT Service；如何写一个跨平台的程序（Windows和Linux都能跑）；如何设计一个框架，能够快速集成多种协议（RS232串口、TCP/IP、有状态协议、无状态协议等）；如何逆向分析各种设备协议（我们是小公司，拿不到医疗设备公司的协议文档）；如何把设备集成框架设计得简单易用，我不在的时候（当时我还没毕业）别人也能快速集成新设备。我觉得任何一个值得做的项目都会学到很多新知识，成为技术专家的关键一点是你要把每一个有价值的知识点研究透，这样多个项目积累下来，你就有了很多很扎实的知识点，这些知识点积累起来，结合书本知识，就能系统化。什么叫研究透？想像一下世界上该领域的顶级专家来跟你交流，你是否能做到他问的任何问题都能对答如流。

已经过了快二十年，我对这个程序的很多技术点还能记住，是因为当时真的下了很多功夫（不然不会重写三遍）。我面过很多人，不太理解的一点是发现有些人对自己做过的东西说不清楚，有的细节甚至才过了几个月就忘了。我面人的基本要求是知其然还要知其所以然，自己做过的东西说不清楚说明不怎么动脑子，知其然不知其所以然说明对技术没有追求，不关心背后的原理。

基本上我写过的所有软件，设计要点我到现在都能记住。要做到这一点，一方面是做任何事情都要下功夫，关注细节；另一方面是要把设计和实现分开，实现可以忘记但是设计不能忘。

大家都是普通人，我的记忆力也很一般。参加同学聚会的时候，大家经常回忆往事。我经常发现当年一起做过的事情，别人说的津津有味，我却完全想不起来。设计和实现分离是我刻意训练过的一个技巧，目的之一就是为了长久记忆。设计是有规律和普遍意义的，可以用在以后的工作中，值得花更多的时间去思考和提炼，而花更多的时间恰恰有助于记忆。实现细节太多，记住不容易，很多时候也跟具体的项目有关，对以后的项目不一定有帮助，没必要刻意去记。中学的时候做题，我喜欢总结规律，从一道题中归纳出一类题的解法，找到快速解题的公式。我甚至还要求自己对某些题型要在一定的时间内解出来（我中学的时候总结了一套解题公式，可以快速对付各类题型）--这些都导致我会花很多时间研究解题技巧。而花了这么多时间得出的解题技巧，记不住也难。所以我说，如果做过的东西说不清楚，说明不动脑子，下的功夫不够。

这个网关程序我在兼职状态下做了三年多（从大四到读研），真正的密集开发可能只有不到一年的时间，还不是全职的，后面忙着本科毕设和研究生学业，变成顾问角色，很少去公司。我在那时就已经成为了Windows技术专家。做d2hackmap游戏外挂是在研究生后期，那个时候我的C++、Windows技术水平已经很高了，如果你去看d2hackmap的源代码，可以发现里面用了各种Windows、C/C++、汇编技巧。

在这个网关开发的过程中和研究生期间，我学习了哪些技术？具体来说，有当时所有主要的Windows开发书籍，所有主流的C/C++编程书籍，还有历期Microsoft System Journals（后改名叫MSDN Magzine）上感兴趣的专栏文章，都看了一遍。

问题是，同样的我，为什么从大一到大四花了那么多时间学习编程，进展很慢，然而实习了不到一年就有很大进步呢？我觉得有几个原因。一是原来的学习虽然有一个模糊的方向，但是没有明确目标。二是没有特定的工作环境。三是缺乏过来人的指点，不可避免走了弯路。

有明确的交付目标和时间点，才会有压力，才会针对具体问题去寻找答案，这样就把漫无目的的学习范围大大缩小了。环境也很重要，在家里工作和在公司工作效率差很多，这跟在宿舍自习和在教室自习差很多一样。过来人的指点可以避免走弯路，让你在第一时间做出正确选择，节省大量时间。但是要记住，别人对你没有义务，所以别指望高手会手把手教你。我的学习更多的是观察优秀的人如何做事以及他们对事情的观点。

通过项目学技能的好处是任务很具体目标很清晰，缺点是容易见树木不见森林，知识不系统。通过看书学技能的好处是知识体系比较完整，有全局观，缺点是书本知识比较抽象和枯燥，不容易理解。所以这两者一定要结合起来。

总结起来一句话，技能学习有技巧无捷径。有技巧是说学习技术需要实践和看书相结合，有高手指点就更好，关键是一定要实践，光看书或者做练习题是不行的；无捷径是说一定要自己下苦功夫，不要幻想有高手带你飞。我在上海生活十几年，上海话都听不懂。因为智商不够吗？肯定不是。因为我不知道学习语言的技巧吗？也不是。是因为我没有学习上海话的压力，也缺乏主动性，没有下功夫而已。

就技能学习而言，花同样多的时间，有专业教练手把手教肯定是效果最好的，这也是为什么在任何竞技领域，业余选手肯定干不过职业选手的原因。但是工作中的同事不是你的私人教练，所以工作中的学习要靠自己，要注意观察高手的工作方法、听他们分享的观点，迷茫的时候找他们指点。

关于技术大牛，其实也分两个方向：领域专家和系统架构师（我的选择是系统架构师）。前段时间正好在公司内部做了一个架构师讲座，借此分享一下。

下面引用的两张图来自这个网站： --是专门研究系统架构设计的一个项目，免费的。

技术专家和系统架构师的区别如下图。技术专家和系统架构师是两个不同的方向，无所谓谁好谁坏。技术专家在某一个领域非常精通，比如说音频编解码算法。系统架构师是一专多能，在某些点上追求深度，其他领域追求广度。在技术专家和系统架构师这两个方向之间还有多领域专家和领域架构师。

从新人到系统架构师的职业道路如下图。

做为架构师，虽然追求广度，但是必须对某个领域非常精通，这是你的根，要扎的非常深。我面过很多架构师，是在做上层架构设计，说的也头头是道，但是对一线技术精通的就不多。

架构师的第二个层次是要追求技术广度，有很多技术你可能没有做过，但是要知道怎么回事，需要的时候能迅速钻进去。

第三个层次是要了解业务、应用场景还有各种组织流程。了解业务和应用场景是因为技术需要靠创造商业价值来变现，了解组织流程是因为商业化不是单打独斗，需要协作。架构师是把商业需求转换成产品的一个关键角色，因此他需要了解这些技术以外的东西。

第四个层次是要了解社会心理学。因为产品最终是为了满足人的需要才有价值，而产品研发本身也需要多人协作。社会心理学主要是研究人际关系。自我评价的话，我现在大约在第三、第四阶段的某个程度。

关于智商。有人担心自己智商不够做不了技术大牛。我的看法是智商这个东西看做什么。如果是创新型工作，比如科研，需要突破人类已有的知识疆界，这是需要很高的智商（不过科研里也有很多搬砖的活儿）。绝大部分的工作，包括软件开发，并不需要很高的智商，重要的是勤奋、学习技巧和工作的态度。

我发现这位答主对天赋的看法跟我几乎一样：

他总结的公式：天赋=时间x方法。这跟我说的有技巧无捷径是一回事。

reason（凡事皆有因）。这句话的真正意思是，做为工程师，你必须有打破沙锅问到底的精神，对每一个问题都追查到底。开发中会碰到大量的bug，有的偶现bug很难查，有没有这种精神，直接决定了产品的品质和你在技术上能走多远。我在前一段时间，为了一个客户反馈的iOS上的偶现崩溃，查了两天两夜，其他工程师觉得可能是客户自己的问题放弃了。我以前在博客里也分享过一个案例，为了验证这个bug fix，我做了14万次实验，细节见这里：。技术就是这样一点一滴积累出来的。

我分享一下14万次的验证实验这个案例。我们当时新发布了一款设备，客户反馈说有时关机下不了电，这个后果比较严重，会直接耗尽电池导致电池损坏。这个问题其实在产品发布前发现过，出现的概率大约是百分之一，当时也做了修复。在客户那儿复现了说明没彻底解决。我当时刚进公司没多久，从来没做过硬件相关的开发，甚至都不知道有逻辑分析仪这种东西。但是我有很好的思路，建议做自动化测试重现问题。测试的结果发现出现问题的概率是两千分之一，换句话说，平均每两千台设备会损坏一块电池，或者每台设备下电两千次电池会坏掉。通过用示波器和逻辑分析仪捕捉下电过程的信号逻辑，做了大量分析，我们找到了问题，是因为CPU在下电时寄存器状态没保持住，一定概率上会影响主板上的下电逻辑。修复以后，接下来的问题是，这种小概率事件，解决方案怎么验证是正确的。我的想法是，因为我们知道出现问题的概率大约是两千分之一，如果验证次数比这个概率高一个数量级，我就有信心说基本解决了这个问题，如果验证次数高两个数量级，我的信心是非常足的。所以我的目标是要做20万次实验。最后由于市场压力比较大，时间来不及，做了14万次觉得足够了。

关于商业软件开发。商业软件开发和编程作业、算法竞赛等最大的区别在于这句话：软件的首要技术使命是管理复杂度。这是《代码大全》里的一句话，是我觉得这本书中最重要的一句。很多软件工程师包括很多技术大牛都没有意识到它的重要性。仔细想想，很多重要的编程思想、方法论其实都跟这句话有关。比如，为什么要建立代码规范，要有代码仓库管理/Check-in流程；各种软件研发流程：瀑布模型、V模型、敏捷开发；各种设计思想：分层、模块化、面向对象、基于连接和组合、KISS原则 Stupid)、高内聚低耦合。所有这些其实都是为了管理复杂度。心中有管理复杂度的意识，软件自然会越写越好。我个人的学习方法，比较喜欢从先实践中总结归纳，再通过看书把知识系统化。《设计模式》这本书挺薄的。我看过几遍，从来没有仔细看完过，经常翻了几个模式之后觉得太枯燥放下了，所以我其实也没有完整的掌握过它提到的所有设计模式。这不妨碍我做设计，我不会刻意去想要用什么样的设计模式，但是我非常关注复杂度管理，会反复思考怎么设计使得复杂度可控。

最后关于如何做事如何学习，我推荐一本书：史蒂芬.柯维的名作《高效能人士的七个习惯》。我很早以前就知道这本书，很多外企都有相应的培训课程，系统架构师的培训讲师也推荐过，我自己偶尔也翻翻，但一直以来都当成功学、心灵鸡汤看待。我真正对待这本书，是因为几年前认识一个朋友，他说这本书改变了他的人生。这给我很大的震撼，因为我从来没听过有人说一本书改变了人生。如果有一个清华本科毕业、留美博士、回国创业成功的绝顶聪明人，跟你说一本书改变了他的人生，你是否也应该重视呢？

这本书给我的体会是，道理非常好，但是说理的方式有点教条（也许是翻译的问题），很多道理需要结合人生阅历来仔细体会。现在读不太明白也没关系，过几年再看，会有新的体会。

写这个回答是因为我前几天写了这个回答（）以后，有人对我的成长经历比较好奇，也有些人觉得我是一个破坏分子，因此在这里澄清一下，我是一个正经的程序员！

接下来打一波小广告，如果你是技术大牛，或者你觉得自己有成为技术大牛的潜力，而且你还喜欢挑战性的工作，欢迎加入我们--一起创业。欢迎技术牛人加入我们，长期有效！