每天写业务代码，如何成为技术大牛

前序

 　　在工做之余浏览公司的技术网站，看到了如下这篇文章，细细读来真心以为不错，写得有价值很实在。因而想联系下做者，问一下是否能够转载。打开钉钉一搜，做者是资深技术专家，差很少就是技术总监级别啊，这也从侧面旁征了，如下的内容是有其亲身经历，切实体会的，而不是鸡汤口号之流。相较与做者的级别，本身确实惭愧汗颜，因此没好直接聊天询问而是在文章底下留言。在获得了做者的赞成后将文章的内容贴到这里，做为分享也做为本身的鞭策和提醒。在这里谢谢个人大牛同事了^_^。

。。。。。。。。。。。。。。。。。。。。如下内容纯属做者原版，只字未动。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

写在前面

无论是开发、测试、运维，每一个技术人员心理多多少少都有一个成为技术大牛的梦，毕竟“梦想老是要有的，万一实现了呢”！正是对技术梦的追求，促使咱们不断地努力和提高本身。

然而“梦想是美好的，现实倒是残酷的”，不少同窗在实际工做后就会发现，梦想是成为大牛，但作的事情看起来跟大牛都不沾边，例如，程序员说“每天写业务代码还加班，如何才能成为技术大牛”，测试说“天天都有执行不完的测试用例”，运维说“扛机器接网线敲shell命令，这不是我想要的运维人生”。。。。。。知乎上相似的问题“每天写业务代码的程序员，怎么成为技术大牛，开始写技术代码？”关注人数有6K+，答案有120+，当时我也回答了而且点赞数最多，后来作职业等级晋升面评和沟通的时候，又有了新的发现和想法，因而有了系统的整理一篇文章的想法，但愿让更多同窗在技术大牛的路上可以少走一些弯路。

因为我是程序员，因此如下的一些例子都是基于程序开发的，但大道理是相通的，测试、运维均可以借鉴。 

几个典型的误区

拜大牛为师

知乎上有人认为想成为技术大牛最简单直接、快速有效的方式是“拜团队技术大牛为师”，让他们平时给你开小灶，给你分配一些有难度的任务。 

我我的是反对这种方法的，主要的缘由有几个：

• 大牛很忙，不太可能单独给你开小灶，更不可能天天都给你开1个小时的小灶；并且一个团队里面，若是大牛平时常常给你开小灶，不免会引发其余团队成员的疑惑，我我的认为若是团队里的大牛若是真正有心的话，多给团队培训是最好的。然而作过培训的都知道，准备一场培训是很耗费时间的，课件和材料至少2个小时（还不能是碎片时间），讲解1个小时，大牛们一个月作一次培训已是很高频了。
• 由于第一个缘由，因此通常要找大牛，都是带着问题去请教或者探讨。由于回答或者探讨问题无需太多的时间，更多的是靠经验和积累，这种状况下大牛们都是很乐意的，毕竟影响力是大牛的一个重要指标嘛。然而也要特别注意：若是常常问那些书本或者google可以很容易查到的知识，大牛们也会很不耐烦的，毕竟时间宝贵。常常有网友问我诸如“jvm的-Xmn参数如何配置”这类问题，我都是直接回答“请直接去google”，由于这样的问题实在是太多了，若是本身不去系统学习，每一个都要问是很是浪费本身和别人的时间的。
• 大牛很少，不太可能每一个团队都有技术大牛，只能说团队里面会有比你水平高的人，即便他天天给你开小灶，最终你也只能提高到他的水平；而若是是跨团队的技术大牛，因为工做安排和分配的缘由，直接请教和辅导的机会是比较少的，单凭参加几回大牛的培训，是不太可能就成为技术大牛的。 

综合上述的几个缘由，我认为对于大部分人来讲，要想成为技术大牛，首先仍是要明白“主要靠本身”这个道理，不要指望有个像武功师傅同样的大牛手把手一步一步的教你。适当的时候能够经过请教大牛或者和大牛探讨来提高本身，但大部分时间仍是本身系统性、有针对性的提高。

业务代码同样很牛逼

知乎上有的回答认为写业务代码同样能够很牛逼，理由是业务代码同样能够有各类技巧，例如可使用封装和抽象使得业务代码更具可扩展性，能够经过和产品多交流以便更好的理解和实现业务，日志记录好了问题定位效率能够提高10倍。。。。。。等等。 

业务代码同样有技术含量，这点是确定的，业务代码中的技术是每一个程序员的基础，但只是掌握了这些技巧，并不能成为技术大牛，就像游戏中升级打怪同样，开始打小怪，经验值很高，越到后面经验值越少，打小怪已经不能提高经验值了，这个时候就须要打一些更高级的怪，刷一些有挑战的副本了，没看到哪一个游戏只要一直打小怪就能升到顶级的。成为技术大牛的路也是相似的，你要不断的提高本身的水平，而后面临更大的挑战，经过应对这些挑战从而使本身水平更上一级，而后如此往复，最终达到技术大牛甚至业界大牛的境界，写业务代码只是这个打怪升级路上的一个挑战而已，并且我认为是比较初级的一个挑战。 

因此我认为：业务代码都写很差的程序员确定没法成为技术大牛，但只把业务代码写好的程序员也还不能成为技术大牛。

上班太忙没时间本身学习

不少人认为本身没有成为技术大牛并非本身不聪明，也不是本身不努力，而是中国的这个环境下，技术人员加班都太多了，致使本身没有额外的时间进行学习。 

这个理由有必定的客观性，毕竟和欧美相比，咱们的加班确实要多一些，但这个因素只是一个须要克服的问题，并非不可逾越的鸿沟，毕竟咱们身边仍是有那么多的大牛也是在中国这个环境成长起来的。 

我认为有几个误区致使了这种见解的造成：

1）上班作的都是重复工做，要想提高必须本身额外去学习

造成这个误区的主要缘由仍是在于认为“写业务代码是没有技术含量的”，而我如今上班就是写业务代码，因此我在工做中不能提高。

2）学习须要大段的连续时间
不少人觉得要学习就要像学校上课同样，给你一成天时间来上课才算学习，而咱们平时加班又比较多，周末累的只想睡懒觉，或者只想去看看电影打打游戏来放松，因此就没有时间学习了。 

实际上的作法正好相反：首先咱们应该在工做中学习和提高，由于学以至用或者有实例参考，学习的效果是最好的；其次工做后学习不须要大段时间，而是要挤出时间，利用时间碎片来学习。我会在接下来的篇幅讲“如何在工做中学习提高”，至于如何利用时间碎片来学习，能够参考个人另一篇文章《大牛养成指南（1）：吃的草够多，你也能成为大牛》

正确的作法

Do more

作的更多，作的比你主管安排给你的任务更多。 

我在HW的时候，负责一个版本的开发，这个版本的工做量大约是2000行左右，可是我除了作完这个功能，还将关联的功能所有掌握清楚了，代码（大约10000行）也所有看了一遍，作完这个版本后，我对这个版本相关的整套业务所有很熟悉了。通过一两次会议后，你们发现我对这块掌握最熟了，接下来就有趣了：产品讨论需求找我、测试有问题也找我、老大对外支撑也找我；后来，不是我负责的功能他们也找我，即便我当时不知道，我也会看代码或者找文档帮他们回答。。。。。。最后我就成了我这个系统的“专家”了。虽然这个时候我仍是作业务的，仍是写业务代码，可是我已经对整个业务都很熟悉了。 

以上只是一个简单的例子，其实就是想说：要想有机会，首先你得从人群中冒出来，要想冒出来，你就必须作到不同凡响，要作到不同凡响，你就要作得更多！ 

怎么作得更多呢？能够从如下几个方面着手：
1）熟悉更多业务，无论是否是你负责的；熟悉更多代码，无论是否是你写的

这样作有不少好处，举几个简单的例子：

• 需求分析的时候更加准确，可以在需求阶段就识别风险、影响、难点
• 问题处理的时候更加快速，由于相关的业务和代码都熟悉，可以快速的判断问题可能的缘由并进行排查处理
• 方案设计的时候考虑更加周全，因为有对全局业务的理解，可以设计出更好的方案

 2）熟悉端到端

好比说你负责web后台开发，但实际上用户发起一个http请求，要通过不少中间步骤才到你的服务器（例如浏览器缓存、DNS、nginx等），服务器通常又会通过不少处理才到你写的那部分代码（路由、权限等）这整个流程中的不少系统或者步骤，绝大部分人是不可能去参与写代码的，但掌握了这些知识对你的综合水平有很大做用，例如方案设计、线上故障处理这些更加有含金量的技术工做都须要综合技术水平。 

“系统性”、“全局性”、“综合性”这些字眼看起来比较虚，但其实都是技术大牛的必备的素质，要达到这样的境界，必须去熟悉更多系统、业务、代码。 

3）自学

通常在比较成熟的团队，因为框架或者组件已经进行了大量的封装，写业务代码所用到的技术确实也比较少，但咱们要明白“惟一不变的只有变化”，框架有可能要改进，组件可能要替换，或者你换了一家公司，新公司既没有组件也没有框架，要你从头开始来作。这些都是机会，也是挑战，而机会和挑战只会分配给有准备的人，因此这种状况下咱们更加须要自学更多东西，由于真正等到要用的时候再来学已经没有时间了。 

以java为例，大部分业务代码就是if-else加个数据库操做，但咱们彻底能够本身学些更多java的知识，例如垃圾回收，调优，网络编程等，这些可能暂时没用，但真要用的时候，不是google一下就能够了，这个时候谁已经掌握了相关知识和技能，机会就是谁的。

以垃圾回收为例，我本身平时就抽时间学习了这些知识，学了1年都没用上，但后来用上了几回，每次都解决了卡死的大问题，而有的同窗，写了几年的java代码，对于stop-the-world是什么概念都不知道，更不用说去优化了。

Do better

要知道这个世界上没有完美的东西，你负责的系统和业务，总有不合理和能够改进的地方，这些“不合理”和“可改进”的地方，都是更高级别的怪物，打完后可以增长更多的经验值。识别出这些地方，而且给出解决方案，而后向主管提出，一次不行两次，多提几回，只要有一次落地了，这就是你的机会。

 例如：

重复代码太多，是否能够引入设计模式？

系统性能通常，能否进行优化？

目前是单机，若是作成双机是否更好？

版本开发质量不高，是否引入高效的单元测试和集成测试方案？

目前的系统太庞大，是否能够经过重构和解耦改成3个系统？

阿里中间件有一些系统感受咱们也能够用，是否能够引入 ？

。。。。。。。。。。。。。。。。。。。

只要你去想，其实总能发现能够改进的地方的；若是你以为系统哪里都没有改进的地方，那就说明你的水平还不够，能够多学习相关技术，多看看业界其它公司怎么作，BAT都怎么作。 

我2013年调配到九游，刚开始接手了一个简单的后台系统，天天就是配合前台作数据增删改查，看起来彻底没意思，是吧？若是只作这些确实没意思，但咱们接手后作了不少事情：

• 解耦，将一个后台拆分为2个后台，提高可扩展性和稳定性；
• 双机，将单机改成双机系统，提升可靠性；
• 优化，将原来一个耗时5小时的接口优化为耗时5分钟

还有其它不少优化，后来咱们这个组承担了更多的系统，后来这个小组5我的，负责了6个系统。

Do exercise

在作职业等级沟通的时候，发现有不少同窗确实也在尝试Do more、Do better，但在执行的过程当中，几乎每一个人都遇到同一个问题：光看不用效果不好，怎么办？ 

例如：

• 学习了jvm的垃圾回收，可是线上比较少出现FGC致使的卡顿问题，就算出现了，恢复业务也是第一位的，不太可能线上出现问题而后让每一个同窗都去练一下手，那怎么去实践这些jvm的知识和技能呢？
• Netty我也看了，也了解了Reactor的原理，可是我不可能参与Netty开发，怎么去让本身真正掌握Reactor异步模式呢？
• 看了《高性能MySQL》，可是线上的数据库都是DBA管理的，测试环境的数据库感受又是随便配置的，我怎么去验证这些技术呢？
• 框架封装了DAL层，数据库的访问咱们都不须要操心，咱们怎么去了解分库分表实现？

。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

诸如此类问题还有不少，我这里分享一下我的的经验，其实就是3个词：learning、trying、teaching！

1）Learning

这个是第一阶段，看书、google、看视频、看别人的博客均可以，但要注意一点是“系统化”，特别是一些基础性的东西，例如JVM原理、Java编程、网络编程，HTTP协议。。。。。。等等，这些基础技术不能只经过google或者博客学习，个人作法通常是先完整的看完一本书全面的了解，而后再经过google、视频、博客去有针对性的查找一些有疑问的地方，或者一些技巧。

2）Trying

这个步骤就是解答前面提到的不少同窗的疑惑的关键点，形象来讲就是“本身动手丰衣足食”，也就是本身去尝试搭建一些模拟环境，本身写一些测试程序。例如：

• Jvm垃圾回收：能够本身写一个简单的测试程序，分配内存不释放，而后调整各类jvm启动参数，再运行的过程当中使用jstack、jstat等命令查看jvm的堆内存分布和垃圾回收状况。这样的程序写起来很简单，简单一点的就几行，复杂一点的也就几十行。
• Reactor原理：本身真正去尝试写一个Reactor模式的Demo，不要觉得这个很难，最简单的Reactor模式代码量（包括注释）不超过200行（能够参考Doug Lee的PPT）。本身写完后，再去看看netty怎么作，一对比理解就更加深入了。
• MySQL：既然有线上的配置能够参考，那能够直接让DBA将线上配置发给咱们（注意去掉敏感信息），直接学习；而后本身搭建一个MySQL环境，用线上的配置启动；要知道不少同窗用了不少年MySQL，可是连个简单的MySQL环境都搭不起来。
• 框架封装了DAL层：能够本身用JDBC尝试去写一个分库分表的简单实现，而后与框架的实现进行对比，看看差别在哪里。
• 用浏览器的工具查看HTTP缓存实现，看看不一样种类的网站，不一样类型的资源，具体是如何控制缓存的；也能够本身用Python写一个简单的HTTP服务器，模拟返回各类HTTP Headers来观察浏览器的反应。

。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

还有不少方法，这里就不一一列举，简单来讲，就是要将学到的东西真正试试，才能理解更加深入，印第安人有一句谚语：I hear and I forget. I see and I remember. I do and I understand ，并且“试试”其实能够比较简单，不少时候咱们均可以本身动手作。 

固然，若是可以在实际工做中使用，效果会更好，毕竟实际的线上环境和业务复杂度不是咱们写个模拟程序就可以模拟的，但这样的机会可遇不可求，大部分状况咱们还真的只能靠本身模拟，而后等到真正业务要用的时候，可以信手拈来。

3）Teaching

通常来讲，通过Learning和Trying，能掌握70%左右，但要真正掌握，我以为必定要作到可以跟别人讲清楚。由于在讲的时候，咱们既须要将一个知识点系统化，也须要考虑各类细节，这会促使咱们进一步思考和学习。同时，讲出来后看或者听的人能够有不一样的理解，或者有新的补充，这至关于继续完善了整个知识技能体系。 

这样的例子不少，包括我本身写博客的时候常常遇到，原本我以为本身已经掌握很全面了，但一写就发现不少点没考虑到；组内培训的时候也常常看到，有的同窗写了PPT，可是讲的时候，你们一问，或者一讨论，就会发现不少点尚未讲清楚，或者有的点实际上是理解错了。写PPT、讲PPT、讨论PPT，这个流程所有走一遍，基本上对一个知识点掌握就比较全面了。 

后记

成为技术大牛梦想虽然很美好，可是要付出不少，无论是Do more仍是Do better仍是Do exercise，都须要花费时间和精力，这个过程当中可能很苦逼，也可能很枯燥，这里我想特别强调一下：前面我讲的都是一些方法论的东西，但真正起决定做用的，其实仍是咱们对技术的热情和兴趣！