吉安建设网站,建筑设计总结及心得体会,上海网络科技公司官网,兰州做网站公司es5188摘要#xff1a; 写在前面 不管是开发、测试、运维#xff0c;每个技术人员心里多多少少都有一个成为技术大牛的梦#xff0c;毕竟“梦想总是要有的#xff0c;万一实现了呢”#xff01;正是对技术梦的追求#xff0c;促使我们不断地努力和提升自己。 然而“梦想是美好的…摘要 写在前面 不管是开发、测试、运维每个技术人员心里多多少少都有一个成为技术大牛的梦毕竟“梦想总是要有的万一实现了呢”正是对技术梦的追求促使我们不断地努力和提升自己。 然而“梦想是美好的现实却是残酷的”很多同学在实际工作后就会发现梦想是成为大牛但做的事情看起来跟大牛都不沾边例如程序员说“天天写业务代码还加班如何才能成为技术大牛”测试说“每天都有执行不完的测试用例”运维说“扛机器接网线敲shell命令这不是我想要的运维人生”。
写在前面
不管是开发、测试、运维每个技术人员心里多多少少都有一个成为技术大牛的梦毕竟“梦想总是要有的万一实现了呢”正是对技术梦的追求促使我们不断地努力和提升自己。
然而“梦想是美好的现实却是残酷的”很多同学在实际工作后就会发现梦想是成为大牛但做的事情看起来跟大牛都不沾边例如程序员说“天天写业务代码还加班如何才能成为技术大牛”测试说“每天都有执行不完的测试用例”运维说“扛机器接网线敲shell命令这不是我想要的运维人生”。
我也是一位程序员所以我希望通过以下基于程序开发的一些例子帮助大家解决这些困惑。大道理是相通的测试、运维都可以借鉴。
几个典型的误区
拜大牛为师
有人认为想成为技术大牛最简单直接、快速有效的方式是“拜团队技术大牛为师”让他们平时给你开小灶给你分配一些有难度的任务。
我个人是反对这种方法的主要的原因有几个
大牛很忙不太可能单独给你开小灶更不可能每天都给你开1个小时的小灶而且一个团队里面如果大牛平时经常给你开小灶难免会引起其他团队成员的疑惑我个人认为如果团队里的大牛如果真正有心的话多给团队培训是最好的。然而做过培训的都知道准备一场培训是很耗费时间的课件和材料至少2个小时还不能是碎片时间讲解1个小时大牛们一个月做一次培训已经是很高频了。因为第一个原因所以一般要找大牛都是带着问题去请教或者探讨。因为回答或者探讨问题无需太多的时间更多的是靠经验和积累这种情况下大牛们都是很乐意的毕竟影响力是大牛的一个重要指标嘛。然而也要特别注意如果经常问那些书本或者google能够很容易查到的知识大牛们也会很不耐烦的毕竟时间宝贵。经常有网友问我诸如“jvm的-Xmn参数如何配置”这类问题我都是直接回答“请直接去google”因为这样的问题实在是太多了如果自己不去系统学习每个都要问是非常浪费自己和别人的时间的。大牛不多不太可能每个团队都有技术大牛只能说团队里面会有比你水平高的人即使他每天给你开小灶最终你也只能提升到他的水平而如果是跨团队的技术大牛由于工作安排和分配的原因直接请教和辅导的机会是比较少的单凭参加几次大牛的培训是不太可能就成为技术大牛的。
综合上述的几个原因我认为对于大部分人来说要想成为技术大牛首先还是要明白“主要靠自己”这个道理不要期望有个像武功师傅一样的大牛手把手一步一步地教你。适当的时候可以通过请教大牛或者和大牛探讨来提升自己但大部分时间还是自己系统性、有针对性的提升。
业务代码一样很牛逼
有人认为写业务代码一样可以很牛逼理由是业务代码一样可以有各种技巧例如可以使用封装和抽象使得业务代码更具可扩展性可以通过和产品多交流以便更好的理解和实现业务日志记录好了问题定位效率可以提升10倍等等。
业务代码一样有技术含量这点是肯定的业务代码中的技术是每个程序员的基础但只是掌握了这些技巧并不能成为技术大牛就像游戏中升级打怪一样开始打小怪经验值很高越到后面经验值越少打小怪已经不能提升经验值了这个时候就需要打一些更高级的怪刷一些有挑战的副本了没看到哪个游戏只要一直打小怪就能升到顶级的。成为技术大牛的路也是类似的你要不断的提升自己的水平然后面临更大的挑战通过应对这些挑战从而使自己水平更上一级然后如此往复最终达到技术大牛甚至业界大牛的境界写业务代码只是这个打怪升级路上的一个挑战而已而且我认为是比较初级的一个挑战。
所以我认为业务代码都写不好的程序员肯定无法成为技术大牛但只把业务代码写好的程序员也还不能成为技术大牛。
上班太忙没时间自己学习
很多人认为自己没有成为技术大牛并不是自己不聪明也不是自己不努力而是中国的这个环境下技术人员加班都太多了导致自己没有额外的时间进行学习。
这个理由有一定的客观性毕竟和欧美相比我们的加班确实要多一些但这个因素只是一个需要克服的问题并不是不可逾越的鸿沟毕竟我们身边还是有那么多的大牛也是在中国这个环境成长起来的。
我认为有几个误区导致了这种看法的形成
1上班做的都是重复工作要想提升必须自己额外去学习
形成这个误区的主要原因还是在于认为“写业务代码是没有技术含量的”而我现在上班就是写业务代码所以我在工作中不能提升。
2学习需要大段的连续时间
很多人以为要学习就要像学校上课一样给你一整天时间来上课才算学习而我们平时加班又比较多周末累的只想睡懒觉或者只想去看看电影打打游戏来放松所以就没有时间学习了。
实际上的做法正好相反首先我们应该在工作中学习和提升因为学以致用或者有实例参考学习的效果是最好的其次工作后学习不需要大段时间而是要挤出时间利用时间碎片来学习。
正确的做法
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个系统
阿里中间件有一些系统感觉我们也可以用是否可以引入
只要你去想其实总能发现可以改进的地方的如果你觉得系统哪里都没有改进的地方那就说明你的水平还不够可以多学习相关技术多看看业界其它优秀公司怎么做。
我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
1Learning
这个是第一阶段看书、google、看视频、看别人的博客都可以但要注意一点是“系统化”特别是一些基础性的东西例如JVM原理、Java编程、网络编程HTTP协议等等这些基础技术不能只通过google或者博客学习我的做法一般是先完整的看完一本书全面的了解然后再通过google、视频、博客去有针对性的查找一些有疑问的地方或者一些技巧。
2Trying
这个步骤就是解答前面提到的很多同学的疑惑的关键点形象来说就是“自己动手丰衣足食”也就是自己去尝试搭建一些模拟环境自己写一些测试程序。例如
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 而且“试试”其实可以比较简单很多时候我们都可以自己动手做。
当然如果能够在实际工作中使用效果会更好毕竟实际的线上环境和业务复杂度不是我们写个模拟程序就能够模拟的但这样的机会可遇不可求大部分情况我们还真的只能靠自己模拟然后等到真正业务要用的时候能够信手拈来。
3Teaching
一般来说经过Learning和Trying能掌握70%左右但要真正掌握我觉得一定要做到能够跟别人讲清楚。因为在讲的时候我们既需要将一个知识点系统化也需要考虑各种细节这会促使我们进一步思考和学习。同时讲出来后看或者听的人可以有不同的理解或者有新的补充这相当于继续完善了整个知识技能体系。
这样的例子很多包括我自己写博客的时候经常遇到本来我觉得自己已经掌握很全面了但一写就发现很多点没考虑到组内培训的时候也经常看到有的同学写了PPT但是讲的时候大家一问或者一讨论就会发现很多点还没有讲清楚或者有的点其实是理解错了。写PPT、讲PPT、讨论PPT这个流程全部走一遍基本上对一个知识点掌握就比较全面了。
后记
成为技术大牛梦想虽然很美好但是要付出很多不管是Do more还是Do better还是Do exercise都需要花费时间和精力这个过程中可能很苦逼也可能很枯燥这里我想特别强调一下前面我讲的都是一些方法论的东西但真正起决定作用的其实还是我们对技术的热情和兴趣原文发布时间为2018-03-29 本文作者李运华 原文链接
干货好文请关注扫描以下二维码
