漫谈程序员(109)每天写业务代码，如何成为技术大牛？

  不论是开发、测试、运维，每一个技术人员心理多多少少都有1个成为技术大牛的梦，毕竟“梦想总是要有的，万1实现了呢”！正是对技术梦的寻求，促使我们不断地努力和提升自己。

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

几个典型的误区

1、拜大牛为师

  知乎上有人认为想成为技术大牛最简单直接、快速有效的方式是“拜团队技术大牛为师”，让他们平时给你开小灶，给你分配1些有难度的任务。
  我个人是反对这类方法的，主要的缘由有几个：
  大牛很忙，不太可能单独给你开小灶，更不可能每天都给你开1个小时的小灶；而且1个团队里面，如果大牛平时常常给你开小灶，难免会引发其他团队成员的疑惑，我个人认为如果团队里的大牛真正有心的话，多给团队培训是最好的。但是做过培训的都知道，准备1场培训是很耗费时间的，课件和材料最少2个小时（还不能是碎片时间），讲授1个小时，大牛们1个月做1次培训已是很高频了。
  由于第1个缘由，所以1般要找大牛，都是带着问题去请教或探讨。由于回答或探讨问题无需太多的时间，更多的是靠经验和积累，这类情况下大牛们都是很乐意的，毕竟影响力是大牛的1个重要指标嘛。但是也要特别注意：如果常常问那些书本或google能够很容易查到的知识，大牛们也会很不耐烦的， 毕竟时间宝贵。常常有网友问我诸如“jvm的-Xmn参数如何配置”这类问题，我都是直接回答“请直接去google”，由于这样的问题实在是太多了，如果自己不去系统学习，每一个都要问是非常浪费自己和他人的时间的。
  大牛不多，不太可能每一个团队都有技术大牛，只能说团队里面会有比你水平高的人，即便他每天给你开小灶，终究你也只能提升到他的水平；而如果是跨团队的技术大牛，由于工作安排和分配的缘由，直接请教和辅导的机会是比较少的，单凭参加几次大牛的培训，是不太可能就成为技术大牛的。
  综合上述的几个缘由，我认为对大部份人来讲，要想成为技术大牛，首先还是要明白“主要靠自己”这个道理，不要期望有个像武功师傅1样的大牛手把手1步1步地教你。适当的时候可以通过请教大牛或和大牛探讨来提升自己，但大部份时间还是自己系统性、有针对性地提升。

2、业务代码1样很牛逼

  知乎上有的回答认为写业务代码1样可以很牛逼，理由是业务代码1样可以有各种技能，例如可使用封装和抽象使得业务代码更具可扩大性，可以通过和产品多交换以便更好地理解和实现业务，日志记录好了问题定位效力可以提升10倍…..等等。
  业务代码1样有技术含量，这点是肯定的，业务代码中的技术是每一个程序员的基础，但只是掌握了这些技能，其实不能成为技术大牛，就像游戏中升级打怪1样，开始打小怪，经验值很高，越到后面经验值越少，打小怪已不能提升经验值了，这个时候就需要打1些更高级的怪，刷1些有挑战的副本了，没看到哪一个游戏 只要1直打小怪就可以升到顶级的。成为技术大牛的路也是类似的，你要不断地提升自己的水平，然后面临更大的挑战，通过应对这些挑战从而使自己水平更上1级， 然后如此往复，终究到达技术大牛乃至业界大牛的境地，写业务代码只是这个打怪升级路上的1个挑战而已，而且我认为是比较低级的1个挑战。
  所以我认为：业务代码都写不好的程序员肯定没法成为技术大牛，但只把业务代码写好的程序员也还不能成为技术大牛。

3、上班太忙没时间自己学习

  很多人认为自己没有成为技术大牛其实不是自己不聪明，也不是自己不努力，而是中国的这个环境下，技术人员加班都太多了，致使自己没有额外的时间进行学习。
  这个理由有1定的客观性，毕竟和欧美相比，我们的加班确切要多1些，但这个因素只是1个需要克服的问题，其实不是不可逾越的鸿沟，毕竟我们身旁还是有那末多的大牛也是在中国这个环境成长起来的。
  我认为有几个误区致使了这类看法的构成：

• 1）上班做的都是重复工作，要想提升必须自己额外去学习构成这个误区的主要缘由还是在于认为“写业务代码是没有技术含量的”，而我现在上班就是写业务代码，所以我在工作中不能提升。
• 2）学习需要大段的连续时间很多人以为要学习就要像学校上课1样，给你1整天时间来上课才算学习，而我们平时加班又比较多，周末累的只想睡懒觉，或只想去看看电影打打游戏来放松，所以就没有时间学习了。

  实际上的做法正好相反：首先我们应当在工作中学习和提升，由于学以致用或有实例参考，学习的效果是最好的；其次工作后学习不需要大段时间，而是要挤出时间，利用时间碎片来学习。

正确的做法

1、Do more

  做的更多，做的比你主管安排给你的任务更多。
  我在HW的时候，负责1个版本的开发，这个版本的工作量大约是2000行左右，但是我除做完这个功能，还将关联的功能全部掌握清楚了，代码（大约 10000行）也全部看了1遍，做完这个版本后，我对这个版本相干的整套业务全部很熟习了。经过1两次会议后，大家发现我对这块掌握最熟了，接下来就有趣了：产品讨论需求找我、测试有问题也找我、老大对外支持也找我；后来，不是我负责的功能他们也找我，即便我当时不知道，我也会看代码或找文档帮他们回答…..最后我就成了我这个系统的“专家”了。虽然这个时候我还是做业务的，还是写业务代码，但是我已对全部业务都很熟习了。
  以上只是1个简单的例子，其实就是想说：要想有机会，首先你得从人群中冒出来，要想冒出来，你就必须做到与众不同，要做到与众不同，你就要做得更多！
  怎样做得更多呢？可以从以下几个方面着手：

• 1）熟习更多业务，不论是不是你负责的；熟习更多代码，不论是不是你写的。

  这样做有很多好处，举几个简单的例子：

• 需求分析的时候更加准确，能够在需求阶段就辨认风险、影响、难点；
• 问题处理的时候更加快速，由于相干的业务和代码都熟习，能够快速地判断问题可能的缘由并进行排查处理；
• 方案设计的时候斟酌更加周全，由于有对全局业务的理解，能够设计出更好的方案。

2）熟习端到端

  比如说你负责web后台开发，但实际上用户发起1个http要求，要经过很多中间步骤才到你的服务器（例如阅读器缓存、DNS、nginx等），服务器1般又会经过很多处理才到你写的那部份代码（路由、权限等）这全部流程中的很多系统或步骤，绝大部份人是不可能去参与写代码的，但掌握了这些知识对你的综合水平有很大作用，例如方案设计、线上故障处理这些更加有含金量的技术工作都需要综合技术水平。
“系统性”、“全局性”、“综合性”这些字眼看起来比较虚，但其实都是技术大牛的必备的素质，要到达这样的境地，必须去熟习更多系统、业务、代码。

3）自学

  1般在比较成熟的团队，由于框架或组件已进行了大量的封装，写业务代码所用到的技术确切也比较少，但我们要明白“唯1不变的只有变化”，框架有可能要改进，组件可能要替换，或你换了1家公司，新公司既没有组件也没有框架，要你从头开始来做。这些都是机会，也是挑战，而机会和挑战只会分配给有准备的人，所以这类情况下我们更加需要自学更多东西，由于真正等到要用的时候再来学已没有时间了。
  以java为例，大部份业务代码就是if-else加个数据库操作，但我们完全可以自己学些更多java的知识，例如垃圾回收，调优，网络编程等，这些可能暂时没用，但真要用的时候，不是google1下就能够了，这个时候谁已掌握了相干知识和技能，机会就是谁的。
以垃圾回收为例，我自己平时就抽时间学习了这些知识，学了1年都没用上，但后来用上了几次，每次都解决了卡死的大问题，而有的同学，写了几年的java代码，对stop-the-world是甚么概念都不知道，更不用说去优化了。

2、Do better

  要知道这个世界上没有完善的东西，你负责的系统和业务，总有不公道和可以改进的地方，这些“不公道”和“可改进”的地方，都是更高级别的怪物，打完后能够增加更多的经验值。辨认出这些地方，并且给出解决方案，然后向主管提出，1次不行两次，多提几次，只要有1次落地了，这就是你的机会。
  例如：

• 重复代码太多，是不是可以引入设计模式？
• 系统性能1般，可否进行优化？
• 目前是单机，如果做成双机是不是更好？
• 版本开发质量不高，是不是引入高效的单元测试和集成测试方案？
• 目前的系统太庞大，是不是可以通太重构和解耦改成3个系统？
• 阿里中间件有1些系统感觉我们也能够用，是不是可以引入？

  ……………………..
  只要你去想，其实总能发现可以改进的地方的。如果你觉得系统哪里都没有改进的地方，那就说明你的水平还不够，可以多学习相干技术，多看看业界其它公司怎样做，BAT都怎样做。
  我2013年调配到9游，刚开始接手了1个简单的后台系统，每天就是配合前台做数据增删改查，看起来完全没意思，是吧？如果只做这些确切没意思，但我们接手后做了很多事情：

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

  还有其它很多优化，后来我们这个组承当了更多的系统，后来这个小组5个人，负责了6个系统。

3、Do exercise

  在做职业等级沟通的时候，发现有很多同学确切也在尝试Do more、Do better，但在履行的进程中，几近每一个人都遇到同1个问题：光看不用效果很差，怎样办？
  例如：
  学习了jvm的垃圾回收，但是线上比较少出现FGC致使的卡顿问题，就算出现了，恢复业务也是第1位的，不太可能线上出现问题然后让每一个同学都去练1下手，那怎样去实践这些jvm的知识和技能呢？
  Netty我也看了，也了解了Reactor的原理，但是我不可能参与Netty开发，怎样去让自己真正掌握Reactor异步模式呢？
  看了《高性能MySQL》，但是线上的数据库都是DBA管理的，测试环境的数据库感觉又是随意配置的，我怎样去验证这些技术呢？
框架封装了DAL层，数据库的访问我们都不需要操心，我们怎样去了解分库分表实现？
……………………….
  诸如此类问题还有很多，我这里分享1下个人的经验，其实就是3个词：learning、trying、teaching！

1）Learning

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

2）Trying

  这个步骤就是解答前面提到的很多同学的疑惑的关键点，形象来讲就是“自己动手丰衣足食”，也就是自己去尝试搭建1些摹拟环境，自己写1些测试程序。例如：
  Jvm垃圾回收：可以自己写1个简单的测试程序，分配内存不释放，然后调剂各种jvm启动参数，再运行的进程中使用jstack、jstat等命令查看jvm的堆内存散布和垃圾回收情况。这样的程序写起来很简单，简单1点的就几行，复杂1点的也就几10行。
  Reactor原理：自己真正去尝试写1个Reactor模式的Demo，不要以为这个很难，最简单的Reactor模式代码量（包括注释）不超过200行（可以参考Doug Lee的PPT）。自己写完后，再去看看netty怎样做，1对照理解就更加深入了。
  MySQL：既然有线上的配置可以参考，那可以直接让DBA将线上配置发给我们（注意去掉敏感信息），直接学习；然后自己搭建1个MySQL环境，用线上的配置启动；要知道很多同学用了很多年MySQL，但是连个简单的MySQL环境都搭不起来。
  框架封装了DAL层：可以自己用JDBC尝试去写1个分库分表的简单实现，然后与框架的实现进行对照，看看差异在哪里。
用阅读器的工具查看HTTP缓存实现，看看不同种类的网站，不同类型的资源，具体是如何控制缓存的；也能够自己用Python写1个简单的HTTP服务器，摹拟返回各种HTTP Headers来视察阅读器的反应。
………………………………
  还有很多方法，这里就不逐一罗列，简单来讲，就是要将学到的东西真正试试，才能理解更加深入，印第安人有1句谚语：I hear and I forget. I see and I remember. I do and I understand，而且“试试”其实可以比较简单，很多时候我们都可以自己动手做。
  固然，如果能够在实际工作中使用，效果会更好，毕竟实际的线上环境和业务复杂度不是我们写个摹拟程序就可以够摹拟的，但这样的机会可遇不可求，大部份情况我们还真的只能靠自己摹拟，然后等到真正业务要用的时候，能够信手拈来。

3）Teaching

  1般来讲，经过Learning和Trying，能掌握70%左右，但要真正掌握，我觉得1定要做到能够跟他人讲清楚。由于在讲的时候，我们既需要将1个知识点系统化，也需要斟酌各种细节，这会促使我们进1步思考和学习。同时，讲出来后看或听的人可以有不同的理解，或有新的补充，这相当于继续完善了全部知识技能体系。
  这样的例子很多，包括我自己写博客的时候常常遇到，本来我觉得自己已掌握很全面了，但1写就发现很多点没斟酌到；组内培训的时候也常常看到，有的同学写了PPT，但是讲的时候，大家1问，或1讨论，就会发现很多点还没有讲清楚，或有的点实际上是理解错了。写PPT、讲PPT、讨论PPT，这个流程全部走1遍，基本上对1个知识点掌握就比较全面了。

后记

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