如何从菜鸟程序员成长为(伪)高手

目录

[显示]

1.摘要

最近有一些毕业不久的同事问我：“你工作的时候有没有什么窍门？怎么才能快速成为高手？”

想起当初刚入职，新人培训的时候，也跟其他同事讨论过这个问题：如何才能成为业界大牛？当时自己只是觉得兴趣是最好的老师，思路方法什么的没有多想。

加入微博平台架构部的时间也不短了，趁着快过春节总结了一下自己入职微博以来的工作情况，从互联网开发的半个门外汉，到如今能设计一些架构、排查一 些问题、分享一些经验，收获颇多，感想颇多,也逐渐意识到思路和方法的重要性，在此跟大家分享一下。主要分为学、做、想三方面。

2.学会学习

学习无疑是程序员最为重要的素质之一，尤其是互联网这种日新月异的行业，把学习当做工作的一大半也不为过。

2.1.自主学习

最近发现身边的人并不是不想学习，只是每天都在纠结自己到底学什么好：简单的没挑战，复杂的看不懂；旧技术怕过时，新技术没方向……

讲讲自己毕业后的经历，毕业之后去了个不大不小的公司，工作主要是做一些XX管理系统之类的东西，没什么挑战，也用不上什么技术，基本上前端用个 extjs后面套个sql server就解决了。工作稳定了几年，业余时间除了wow没别的事情做，觉得这么闲下去不是办法，于是之后一年的时间里，用上班摸鱼和下班休息的时间学 了这些东西：

• 闲着无聊想做个小游戏，发现游戏相关的书大多是英文的，看不懂，一咬牙翻译了《Real-time rending 3rd》的前几章，刚开始前言都看不懂，只能一个词一个词的翻字典，一句话要琢磨几个钟头到底作者说的到底是什么意思。翻译了几百页英文书之后，发现自己 看英文书没什么障碍了，于是开始每天用休息和摸鱼的时间看书。
• 看完游戏引擎的书之后，把irrlicht引擎的代码看了一遍，然后自己山寨了一个3d渲染的场景管理器，还有个朴素的渲染引擎。
• 给自己的游戏引擎写了个基于脚本语言的解释器，为此看了不少编译原理和虚拟机的书，了解了程序究竟是什么东西，这是我觉得收益很大的一件事情。
• 看编译原理的书的时候发现操作系统的知识有些欠缺，又去看了linux内核相关的书。之后买了个开发板天天修改内核玩，毕业以后又一次了解了内核 的cpu调度、内存管理和文件系统，了解了应用是怎么跑在操作系统上，操作系统又是怎么运行在硬件上的，这也是收益很大的一件事情。
• 看完操作系统又顺着看网络相关的书，之后把lighthttpd的代码看了一遍，用c写了个linux下的http服务器，把几种网络编程模型挨个实现了一遍。
• 实现http服务器的过程中觉得自己编码能力还是有欠缺，把代码大全翻了一遍，顺着又去看了设计模式的书，并且用自己的理解把每个模式用文字重新描述了一遍。
• 中间还看了很多语言和框架相关的书，就不一一列举了。可以参考这里。

我把学习的方向分为三类：

1. 为了工作，满足当前工作所必备的知识
2. 为了提升，与当前工作相关的知识（深度）
3. 拓展视野，与当前工作无关的知识（广度）

学习（1）之后只是个熟练工，2和3才是提升自己的途径，伴随着知识储备的提升，接触新事物时更容易找到相似的知识加以类比，加快理解，也更容易掌握本质。如果每天都在纠结“到底学什么”，那么只能说明还是学的太少了。（真正没什么可学的大牛们应该不会读到这里吧……）

所以，如果觉着没什么东西可以学的时候，那么可以考虑一下学一下更有深度的知识（比如虚拟机或编译器），或者完全不同的知识（新的语言或当前比较火 的方向），甚至完全不相干的知识（单纯练习英文阅读，学习ppt排版之类）吧。随着知识储备增加，自己的不足和未来的学习的方向也会更加明确起来。

2.2.向历史学习

以微博为例，在微博发展的过程中经历了不少波折，并逐渐衍生出了目前的系统架构。很多新人最喜欢问的问题便是“现在线上是怎么做的？”

这个问题不错，但是还不够好。在程序员的世界里罕有能解决所有问题的“银弹”，当前的做法用不了多久也会被替换掉，如果想了解一件事情，那么就多关 注一下“它是怎么变成今天这样的”吧。学会用发展的眼光看问题，了解一些经历过的经验教训，收获会比单纯学会一件什么事情多的多。

那么，如何向历史学习？

• 公司内部的资料库、wiki等大都会有旧时的资料，刚入职时大多不会太忙，这些资料库简直是挖不完的宝藏
• 部门内部分享，比如我当初入职时经常去听“微博XXXX架构演化历程”之类的内部分享
• 多问一下自己”它为什么不那么设计“
• 老员工忆苦思甜吹牛逼的时候多奉承几句_(:з」 ∠)_

2.3.向他人学习

这里有两个极端，

• 有的人喜欢自己闷头捣鼓，什么也不问，这必然是不利于自己提高的；
• 也有人碰到问题就问，这也有问题，浪费他人时间不说，更关键的是说明这人向他人学习的思路错了，要学习他人的并不是具体某个知识（要学知识看书就能解决了），而是学习别人的思维方式。

但是思维方式这种东西很难通过交流的方式学到，后来我发现有个很简单的学习方式：口头禅。举几个例子，大家体会一下：

“这个其实是两个问题”
“有没有更好的方案”
“能不能举个例子”
“能不能给个一句话总结”

除了口头禅，很多牛人都会有非常鲜明的思维方式和处事原则，如果有幸与业界的大牛共事，那么恭喜你，只要多交流、多观察、多思考，那么提升速度会提升好几个数量级。

3.多做有意义的事情

有的人每天时间浪费在跟问题本身无关的事情上，比如我要设计架构的时候还要考虑架构图怎么画，写完代码还要反复部署测试好几轮才pass，查bug的时候把时间浪费在扫日志上。人的精力总是有限的，把时间浪费在这些事情上面，让自己提高的时间就变得少了。

3.1.练习，更多的练习

这里有个误区：“做有意义的事情”不等于“只做自己没做过的事情”。

对于程序员来说，写代码是基本功中的基本功，编码的规范、设计的权衡、甚至顺手的IDE快捷键都要靠平日的试错和积累，很难通过几本书或者几天培训领悟到。

曾经目睹一些人写代码一年之后开始做一些小项目的设计，然后就迫不及待的把重心全都转移到设计甚至架构上，这种没有基础能力支撑做出的设计和架构最 多只能算是高级意淫，大多没等落地就荒废了，意义不大。究其原因，大多是设计出来的东西“不好做”或者“不好用”，就像是只看过一遍课本就去参加高数考 试，现实吗？（学霸们我错了……）

举个例子，几年前在看设计模式的过程中，用qt做了个看漫画的应用，把能用的模式都试了一遍，当然有很多用的不合适的地方，正是这些不合适的地方让 我对面向对象编程和设计模式的思考深入了很多，如何权衡灵活性和复杂性也有了新的认识。之后在设计很多系统的时候少走了很多弯路，既保证了时间点又保证了 质量。如果当时指望着“用的时候再说”，大概已经被项目坑的不能自理了。

3.2.善用工具

工具能解决的事情就用工具去解决，好的工具能节约大把的时间用在更有意义的事情上。

工具的范畴很广，比如linux的各种命令、比如团队内部的各种系统、比如顺手的应用、甚至包括上下班骑的自行车。只要能节约时间、提高效率，那就值得一试。

在这里我列举几个大幅度提升了我的效率的东西：

• 双屏显示器
• 顺手的键盘
• google（不是baidu！不是bing！）
• mac
• mac上的应用：idea、alfread、omnifocus、甚至synergy和istats menus之类跟开发本身关系不大的应用。

我更倾向于把“使用工具”作为一种生活态度：是否希望让自己的生活专注于有意义的事情。如果你认同这个观点，那么想一想投入和回报比例，还是很可观的。

（当然，为了不花钱而自己破解应用的大神也是极叼的……）

3.3.提高时间的利用率

时间是所有期待提升自己的人最宝贵的资源，效率再高，没时间做也没意义。

网上有个流传挺广的图：打扰程序员的成本。事实上我每天的工作时间非常碎片化，来到公司之后可能不断的接电话、被问问题、被拉去开会、回复邮件等等；也经常会有时间不够用或者没事做的困惑，这里分享一下心得：

• GTD可以整合很多碎片时间。除了把事做完之外，把上下文相关的事情集中在一起完成也很有帮助。比如把几件想去其他办公室做的事情整合成一趟完成。
• 减少无意义的时间浪费，比如家住在公司边上可以每天节省几个小时的时间用来学习或者做别的事情。（但如果节省下来的时间用来刷微博，那就没有必要了。）
• 另外一个很有趣的现象：一个软件的注册费就10几刀，贵些的几百刀，把日常用到的所有工具的费用全加起来都顶不上一个肾6贵，但是很多人还是坚持着没有破解不用的观念，为了几百块钱浪费了大把时间。
• 加班可以创造很多时间，并且能有效减少被打扰的几率，但是也会给身体和精神带来很大负担。因此加班做的事情必须能对个人进步产生足够多的收益。如果加班只是用来处理无意义的工作的话，那应该是日常工作出了什么问题。
• 事情可以分成紧急重要、紧急不重要、重要不紧急、不重要不紧急四类，在todo列表里随时要有重要不紧急的事情。

4.学会思考

4.1.深究

当有什么问题解决不了的时候，很多人会有畏难或者拖延的情绪，典型口头禅就是“就这么凑合着用吧”或者“先这样吧，以后有时间再研究”，说这些话的人大多并不是真的那么忙，甚至有人一边刷着微博一边跟我说没时间研究……(你tm在逗我？)

要克服畏难情绪其实很简单，找一个具体的似懂非懂的问题，想尽办法把问题研究清楚，体会几次解决问题时的愉悦感，建立自信。

大部分问题其实没有什么高深的科学原理，甚至只要翻几页书就解决了，但是遇到问题不深究，久而久之会形成自我暗示：这些问题是我懂的，那些是我不懂的，自己反而把自己进步的路给堵上了。

说到如何深究，也有几条心得：

• 遇事多想为什么，并且要反复问为什么。很多貌似理解了的问题过一阵再重新想想，往往会发现之前还有没考虑到的地方
• 问题要有明确答案，哲学之类的就别纠结了
• 查找资料时选权威的书籍或者网站，避免被误导
• 找人讨论，或者直接拉小伙伴入伙，既可以互相交流，又可以互相监督
• 分享你的成果
• 不要所有事情全都深究，会给自己太多压力

4.2.多说，多写，多交流

平常工作中有一个感受，有交流和写作习惯的人思路会更清晰一些，能接触到的观点也会多一些。这方面其实属于我的弱项，大概总结几个观点。

• 隔一段时间最好能书面形式总结一下最近的工作，比如说写个心得感悟，或者持续更新自己的简历
• 写作的时候有两个难点：对要说明的事情做总结和抽象，形成观点统一、调理清晰的主线；从对方的视角考虑，把事情说明白，避免自言自语。
• 找人讨论之前自己先要有个基本完整的思路，否则大部分的时间都要耗在解释原理之类的上网查反而更快的事情上。
• 讨论之后要有一句话就能说明白的结论和描述清晰的时间点。
• 有些人喜欢纠结于“这个不是我的问题，为什么要我处理”之类的事情。在我看来这是很好的机会。既能增长见识，又能展示水平，还能留个认真负责的好名声，何乐而不为呢。

5.最后

最后分享一下关于我理解的程序员的自我修养，在我看来，可以总结为：负责任，重名声。

负责任，说的更具体些：写的代码自己有没有测过、做的框架自己有没有用过、设计的架构自己有没有认真权衡过。

重名声，说的直接些：没有测过的代码、没有用过的框架、没有权衡过的方案有没有脸交付给别人。

与各位共勉。