你是否有这样的疑问——“天天写业务代码的程序员，如何成为技术高手，开始写技术代码？”今天，阿里资深无线开发专家李云华，系统梳理了自己的思考和理解，希望能帮助更多的同学少走一些弯路。写在前面，无论是开发、测试还是运维，每个技术人员的心中都或多或少有一个成为技术专家的梦想。毕竟“梦想总是要有的，万一实现了呢”！是对科技梦想的追求，鞭策着我们不断努力，提升自我。然而，“梦想很美好，现实却很残酷”。很多同学在真正工作之后会发现，自己的梦想是成为大牛，但所做的事情似乎与大牛无关。比如程序员说“天天写业务代码，加班加点，怎么才能成为技术高手”，测试说“每天有无穷无尽的测试用例要执行”，运维说“扛着机器”接网线打shell命令，这不是我想要的运维生活”。我也是一名程序员，所以希望通过下面的程序化开发的例子来帮助大家解决这些困惑。原理是一样的，测试和运维都可以借鉴。几个典型的误区有人认为，成为技术高手最简单、直接、快速、有效的方法就是“以团队的技术高手为师”，让他们给你上小课，给你布置一些有难度的任务.任务。我个人反对这种方式有几个原因：大牛很忙，不可能单独给你一个小灶，更不可能每天给你开一个小时的小灶；而在一个团队中，如果大牛平时和你闲聊，难免会引起其他团队成员的质疑。我个人认为，如果队里的大牛真的有心，最好多给队里培养。但是，做过培训的人都知道，准备培训是一件非常耗时的事情。课件和资料至少2小时（不是碎片化时间），讲解1小时。大牛一个月做一次训练已经很高了。频率。因为第一个原因，一般需要找个大牛，带着问题提问或者讨论。因为回答问题或者讨论问题都不需要太多时间，更多的是靠经验和积累。在这种情况下，大牛们很高兴。毕竟影响力是大牛的一个重要指标。不过要特别注意：如果你经常问的是书本上或者google上很容易找到的知识，大牛们会很不耐烦，毕竟时间宝贵。经常有网友问我“如何配置jvm的-Xmn参数”之类的问题，我总是回答“请直接去google”，因为这样的问题太多了，如果不是自己学系统，每问问题是浪费你自己和别人的时间。专家不多，不可能每个团队都有技术专家。只能说队伍里肯定会有比你等级高的。即使他每天给你上一小节课，你最终也只能提高到他的水平；但是，如果你是跨团队的技术专家，由于工作安排和任务，直接咨询和辅导的机会相对较少。仅仅参加几次专家培训就成为技术专家是不太可能的。基于以上原因，我认为对于大多数人来说，要想成为技术高手，首先要明白“主要靠自己”的道理。教你。在适当的时候，你可以通过向大牛请教或讨论来提升自己，但大多数时候你仍然需要系统地、有针对性地提升自己。业务代码同样牛逼。有些人认为编写业务代码可以很棒。原因是业务代码也可以有各种技能。比如可以通过封装和抽象让业务代码更具扩展性，可以和产品进行更多的交流，从而更好的理解和实现业务，记录日志记录后，问题定位的效率可以提升10倍.业务代码也有技术含量，这是肯定的，业务代码中的技术是每个程序员的基础，但是仅仅掌握这些技能并不能成为技术高手，就像游戏中升级打怪，开始打怪，经验值很高，越到尽头经验值越低。打小怪不能再增加经验值。这时候你需要去打一些等级更高的怪物，刷一些有挑战性的副本。没见过只要在游戏里一直打小怪，就能升到顶峰。成为技术大师的道路也大同小异。你要不断提升自己的水平，然后迎接更大的挑战。通过应对这些挑战，你可以提升自己的水平，然后周而复始，直到达到技术乃至行业大师的水平。在大牛的境界里，写业务代码只是打怪升级路上的挑战，我觉得是比较初级的挑战。所以我认为：一个不会写好业务代码的程序员肯定是成不了技术专家的，但是一个只会写好业务代码的程序员是不可能成为技术专家的。工作太忙没时间自学很多人认为不是自己不聪明不努力没有成为技术高手，而是因为在中国这个环境下，技术人员工作太多了加班，所以他们没有多余的时间学习。这个理由具有一定的客观性。毕竟和欧美相比，我们的加班确实多一些，但是这个因素只是需要克服的问题，并不是无法逾越的差距。毕竟我们身边还有那么多大牛。在中国的环境中长大。我认为有几个误解导致了这种观点的形成：1）你在工作中所做的都是重复性的工作。如果你想提高，你必须自己学习额外的东西。造成这种误解的主要原因是认为“写业务代码不是技术”，而我现在工作就是在写业务代码，工作上提升不了。2）学习需要长时间的连续时间。许多人认为学习就像在学校上课。你只需要上一整天的课就可以学习。但是，我们通常加班很多。我们累了，只想在周末睡个懒觉。想看电影打游戏放松一下，没时间学习。实际做法恰恰相反：首先，我们应该在工作中学习和提高，因为学习的效果是最好的，因为我们可以学以致用或有范例可供参考；时间，利用时间碎片来学习。做更多的正确方法是做比上司分配给你的任务更多的事情。我在HW的时候，负责一个版本的开发。这个版本的工作量是2000行左右，但是除了完成这个功能之外，我也清楚的掌握了所有的相关功能，也把所有的代码都看了一遍（大概10000行），做了这个版本之后，对与该版本相关的全套业务。一两次见面后，大家发现我对这方面最熟悉，接下来就有意思了：产品讨论需求联系我，测试问题联系我，老板对外支持联系我；后来，我不负责了。他们还问了我有关功能的问题。就算我当时不知道，我也会看代码或者找文档帮他们解答。***我成为我系统的“专家”。虽然此时我还是做业务，写业务代码，但对整个业务已经很熟悉了。以上只是一个简单的例子。其实我想说：要想有机会，首先要脱颖而出。要想脱颖而出，就必须与众不同。要与众不同，你要做的更多！如何做更多？可以从以下几个方面着手：1）熟悉更多的业务，不管你负责与否；熟悉更多的代码，不管是不是你写的，这样做都有很多好处。下面举几个简单的例子：分析需求的时候比较准确，可以更快的识别需求阶段的风险、影响、疑难问题，因为相关业务和代码很熟悉，可以快速判断问题可能产生的原因和在设计故障排除解决方案时考虑更全面。因为对全局业务的了解，可以设计出更好的方案2）熟悉端到端例如你负责web后台开发，但实际上用户发起一个http请求，需要许多中间步骤到达你的服务器（例如浏览器缓存、DNS、nginx等），服务器在到达你编写的代码部分（路由、权限等）之前通常会经过很多处理许多系统整个过程或者说步骤，一般人是不可能参与的。写代码，但是掌握这些知识对你的综合水平会有很大的作用。比如程序设计、在线排错等比较有价值的技术工作，需要综合的技术水平。“系统”、“全局”、“全面”这几个词看似空洞，实则是技术专家必备的素质。要达到这个水平，你必须熟悉更多的系统、业务和代码。.3）自学一般在比较成熟的团队。由于框架或者组件已经被大量封装，写业务代码的技术确实比较少，但是我们要明白“唯一不变的就是变化”，框架可能需要改进，组件可能需要换人，或者换公司，新公司既没有组件也没有框架，需要从头做起。这些都是机遇和挑战，而机遇和挑战只会分配给有准备的人，所以在这种情况下我们需要自己多学习，因为真正需要用到的时候是没有时间学习的。以java为例，大部分业务代码都是if-else加上一个数据库操作，但是我们可以自己学习更多的java知识，比如垃圾回收，调优，网络编程等，这些可能暂时用不上，但真正要用的时候，不是只需要google一下就可以了。谁在此时掌握了相关知识和技能，谁就有机会。以垃圾回收为例。我通常会花时间学习这些知识。一年没用，后来用了几次，每次都解决了卡顿的大问题。有的同学，写了几年java代码，连stop-the-world这个概念都不知道，更别说优化了。做得更好，要知道这个世界上没有完美的东西。你所负责的制度和业务总有不合理和改进的余地。这些“不合理”和“可改进”的区域是更高等级的怪物，战斗后可以增加更多的经验值。找出这些地方，给出解决方案，然后向主管提出，一次不行，两次，多提几次，只要一次落地，这就是你的机会。比如：重复代码太多，能否引入设计模式？系统性能一般，能否优化？目前是单机，做成双机是不是更好？版本开发质量不高。是否引入了高效的单元测试和集成测试方案？当前系统太大，能否通过重构解耦改为3个系统？阿里中间件有一些我们觉得也可以用的系统，可以介绍一下吗？只要想一想，总能找到需要改进的地方；如果你觉得系统没有提升的空间，说明你的水平不够。大家可以多了解相关技术，看看业内其他优秀的公司是怎么做的。.我是2013年分配到久游的，刚接手一个简单的后台系统。每天配合前台进行数据的增删改查。看起来很无聊，对吧？如果只做这些事情真的很无聊，但是我们接手后做了很多事情：解耦，将一个后台拆分为两个后台，提高扩展性和稳定性；双机，变单机为双机系统，提高可靠性能；优化，将一个需要5小时的界面优化到需要5分钟，还有很多其他的优化。后来，我们小组承担了更多的系统。后来这组5个人负责6个系统。Doexercise在做专业级交流的时候，我发现很多同学确实在尝试DomoreandDobetter，但是在实施的过程中，几乎每个人都遇到了同样的问题：不使用效果很差，你该怎么办？？比如：学习过jvm的垃圾回收，但是FGC导致的freeze问题网上比较少见。即使发生，恢复业务也是第一要务。开始吧，如何练习这些jvm知识和技能呢？也看了Netty，了解了Reactor的原理，但是不能参与Netty的开发。怎样才能真正掌握Reactor的异步模式？看了《高性能MySQL》，但是线上的数据库都是DBA管理的，测试环境的数据库好像是乱配置的。我如何验证这些技术？框架封装了DAL层，我们不用担心访问数据库的问题。我们如何理解分库分表的实现呢？像这样的问题还有很多。在这里分享一下我个人的经验，其实就是3个字：学、试、教！1）学习是第一阶段。可以看书，google，看视频，看别人的博客，但是要注意“系统化”，尤其是一些基础的东西，比如JVM原理，Java编程，网络编程，HTTP协议等等这些基础技术不能仅通过谷歌或博客学习。我的做法一般是看书全面了解，然后用google、视频、博客搜索一些有疑问的Where，或者一些tricks。2）Trying这一步是解答上面提到的很多同学疑惑的重点。形象的是“自己动手，丰衣足食”，也就是尝试自己搭建一些模拟环境，自己写一些测试程序。例如：jvm垃圾回收：可以自己写一个简单的测试程序，分配内存不释放，然后调整各种jvm启动参数，使用jstack，jstat等命令查看jvm的堆内存分布和垃圾回收情况在运行过程中。这样的程序写起来很简单，简单的几行，复杂的几十行。Reactor原理：尝试自己写一个Reactor模式的demo。不要认为这很难。最简单的Reactor模式代码（包括注释）不超过200行（请参考DougLee的PPT）。自己写完了再去看看netty是怎么做的，对比之后理解会更深刻。MySQL：既然可以参考在线配置，可以直接让DBA把在线配置发给我们（注意去掉敏感信息），直接学习；然后自己搭建一个MySQL环境，通过在线配置启动；想必很多同学都知道我用了很多年的MySQL，但是连一个简单的MySQL环境搭建都不会。框架对DAL层进行了封装：可以用JDBC尝试写一个简单的分库分表的实现，然后和框架的实现对比一下，看看有什么不同。使用浏览器工具查看HTTP缓存实现，查看不同类型的网站，不同类型的资源，如何控制缓存；也可以用Python写一个简单的HTTP服务器，模拟返回各种HTTPHeaders，观察浏览器响应。还有很多其他的方法，这里就不一一列举了。简单来说，你要尝试你所学的东西，这样你才能更深入地理解它。印第安人有一句谚语：我听到了，我忘记了。我看到了，我记住了。我做我懂，而“尝试”其实可以比较简单，很多时候我们自己就可以做到。当然，如果能在实际工作中使用，效果会更好。毕竟真实的线上环境和业务的复杂性是无法通过编写模拟程序来模拟的，但这样的机会并不多见。大部分情况下，我们还是真的只能自己模拟一下，等到真正的业务需要用到的时候，我就可以信手拈来了。3）教学一般来说，经过学习和尝试，你可以掌握70%左右，但要真正掌握，我认为你必须能够向别人解释清楚。因为在说话的时候，我们不仅需要将一个知识点系统化，还需要考虑各种细节，这会促使我们进一步思考和学习。同时，读过或听过讲座的人可能会有不同的理解，或者有新的补充，相当于继续完善整个知识和技能体系。这样的例子还有很多，包括我自己写博客的时候也经常遇到。本来以为自己掌握的很全面了，但是写的时候发现很多地方没有考虑到；团训的时候经常看到。我写了一个PPT，但是当我讲的时候，大家提问或者讨论的时候，会发现很多地方没有讲清楚，或者有些地方其实是被误解了。写PPT，讲PPT，讨论PPT，这个过程都走完了，基本上掌握了一个知识点就比较全面了。后记成为技术达人的梦想虽然很美好，但也需要付出很多努力。无论是做得更多、做得更好还是做运动，都需要时间和精力。这个过程可能很辛苦，也可能很无聊。我强调一下：我上面讲的都是方法论的东西，但真正起决定作用的是我们对技术的热情和兴趣！
