程序员平时的日常编码工作中,大多数人都只是编写业务代码,各种if else以及数据库操作等。针对于不同的产品去实现功能时,也只是重复性的搬砖工作。此时会有很多人认为天天写业务代码,感觉没有什么长进,也没有实际的需求可以让自己深入的研究技术代码。那么这种情况下如何成为技术大牛呢?
首先说明一点,不管是多简单的产品,实现过程中都会遇到大大小小的问题,例如崩溃、死锁、性能低,系统延迟、服务器不稳定、数据丢失等等。一个产品的成功,势必要解决这些技术性的问题,那么由谁解决呢?可能有人会说基本上都是团队中的大牛负责解决,其他人依然埋没在自己的业务代码中。那么团队中的技术大牛又是如何成长起来的呢?任何人不可能刚开始就处理这种棘手问题吧,那么他们又是如何成长的呢?针对这种情况,从以下几点说明一下在每天的业务代码搬运过程中,如何使自己成长为技术大牛(个人意见,仅供参考):
1、问题就是机会
不管任何系统都会遇到各种技术问题。这些问题,都是自己成长的机遇,而真正抓住机遇的人,都会有所收获。所以不管在日常的开放中遇到上面样的难题,都要有直面它的勇气,迎难而上,主动去解决。当你解决了一个难题后,就会有下一个,当你解决的多的时候,团队中遇到难题都会自然的找到你。你也就自然成为了团队中的技术大牛。
其实解决的问题多了,就会越来越有感觉,你也会发现很多问题只要认真研究,都没有那么难,只是很多人都不愿主动去解决,不愿主动去承担。所以,不管什么时候,做一个积极主动的人,把问题当做机会,让自己经历更多成长更多。
2、靠自己,不断努力提升自己
实际工作中,不管你从事的岗位所负责的工作多么的简单,同样都会遇到各种问题。当遇到这种问题时,首先要想到的是自己,即便是水平不高,能够自己解决的就尽量自己解决。实在需要问别人的时候,也不要去问那些网上或者书中能查到的东西。首先别人不一定有时间,即便是有时间,也不一定能够给你说的很明白,日常工作大多以解决问题为目的,这个问题已经解决了,但你仍然不懂得其中的道理,所以考自己的学习和研究去解决问题,对自己的影响才是最深远的。
另外也不要指望领导专门给你安排去解决各种技术难题,这种问题都是有大拿去解决的,要想成为大拿,还是要靠自己脚踏实地的走过来。
日常平庸的工作中,要自己主动去探索,去争取机会,去挤时间提高自己。不要等到哪一天技术难题突然降临到你身上,你却说不可能。
3、Do more
要想有机会,首先你得从人群中冒出来,要想冒出来,你就必须做到与众不同,要做到与众不同,你就要做得更多!
怎么做得更多呢?可以从以下几个方面着手:
1)熟悉更多业务,不管是不是你负责的;熟悉更多代码,不管是不是你写的
这样做有很多好处,举几个简单的例子:
-
需求分析的时候更加准确,能够在需求阶段就识别风险、影响、难点
-
问题处理的时候更加快速,因为相关的业务和代码都熟悉,能够快速的判断问题可能的原因并进行排查处理
-
方案设计的时候考虑更加周全,由于有对全局业务的理解,能够设计出更好的方案
2)熟悉端到端
比如说你负责web后台开发,但实际上用户发起一个http请求,要经过很多中间步骤才到你的服务器(例如浏览器缓存、DNS、nginx等),服务器一般又会经过很多处理才到你写的那部分代码(路由、权限等)这整个流程中的很多系统或者步骤,绝大部分人是不可能去参与写代码的,但掌握了这些知识对你的综合水平有很大作用,例如方案设计、线上故障处理这些更加有含金量的技术工作都需要综合技术水平。
“系统性”、“全局性”、“综合性”这些字眼看起来比较虚,但其实都是技术大牛的必备的素质,要达到这样的境界,必须去熟悉更多系统、业务、代码。
3)自学
一般在比较成熟的团队,由于框架或者组件已经进行了大量的封装,写业务代码所用到的技术确实也比较少,但我们要明白“唯一不变的只有变化”,框架有可能要改进,组件可能要替换,现有技术可能已经无法满足业务需求,或者你换了一家公司,新公司既没有组件也没有框架,要你从头开始来做。这些都是机会,也是挑战,而机会和挑战只会分配给有准备的人,所以这种情况下我们更加需要自学更多东西,因为真正等到要用的时候再来学已经没有时间了。
以java为例,大部分业务代码就是if-else加个数据库操作,但我们完全可以自己学些更多java的知识,例如垃圾回收,调优,网络编程等,这些可能暂时没用,但真要用的时候,不是google一下就可以了,这个时候谁已经掌握了相关知识和技能,机会就是谁的。
以垃圾回收为例,我自己平时就抽时间学习了这些知识,学了1年都没用上,但后来用上了几次,每次都解决了卡死的大问题,而有的同学,写了几年的java代码,对于stop-the-world是什么概念都不知道,更不用说去优化了。
特别是很多开源软件,更加需要自己平时去自学,例如Nginx、Redis、Mongodb、ElasticSearch等,在合适的时机引入这些技术,能够带来很大的价值。
4、Do better
要知道这个世界上没有完美的东西,你负责的系统和业务,总有不合理和可以改进的地方,这些“不合理”和“可改进”的地方,都是更高级别的怪物,打完后能够增加 更多的经验值。识别出这些地方,并且给出解决方案,然后向主管提出,一次不行两次,多提几次,只要有一次落地了,这就是你的机会。
例如:
-
重复代码太多,是否可以引入设计模式?
-
系统性能一般,可否进行优化?
-
目前是单机,如果做成双机是否更好?
-
版本开发质量不高,是否引入高效的单元测试和集成测试方案?
-
目前的系统太庞大,是否可以通过重构和解耦改为3个系统?
-
阿里中间件有一些系统感觉我们也可以用,是否可以引入 ?
-
。。。。。。。。。。。。。。。。。。。
只要你去想,其实总能发现可以改进的地方的;如果你觉得系统哪里都没有改进的地方,那就说明你的水平还不够,可以多学习相关技术,多看看业界其它公司怎么做,BAT都怎么做。
5、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,都需要花费时间和精力,这个过程中可能很苦逼,也可能很枯燥,这里我想特别强调一下:前面我讲的都是一些方法论的东西,但真正起决定作用的,其实还是我们对技术的热情和兴趣!
——《部分内容摘自网络》