别闹了，真的不是你的技术菜！！！

最近经常听到有小伙伴总是在抱怨自己的技术菜，公司没有机会让自己去成长技术，于是小编就此场景来写一篇文章，希望对大家有帮助。

错误的理解CRUD工程师

CRUD工程师这个名称是很多小伙伴都听过的，并且很多工程师都把自己比作是代码的搬运工，也就是说他的工作内容就是代码的拷贝。

当然这个也是有依据的，一般一个程序员在工作的过程中确实会大量的使用Ctrl C和Ctrl V来搬运代码，这个也是一个不争的事实。

随着我们的技术组件化，软件工程师确实不需要太高的门槛就能够写代码，尤其是Java程序员，最近几年也太卷了。

一般一个工程师的日常工作时间会被大量的会议给占用，也就是说并没有大量的时间让工程师去写一手的漂亮的代码，于是为了能快速的完成任务，也就投机取巧的选择拷贝一些现成的代码。

当然这种工作方式也是对的，于是技术研发部门为了满足业务开发人员的技术需求，就做了各种各样的技术脚手架工程，比如一键生成一个后端或者前端微服务项目，当然这个微服务项目会包含项目中需要使用的技术，并且都被标准化了。

于是呼，工程师就错误的认为他们并不需要了解技术，也就是技术对于他们来说就是简单的添加几个pom依赖包和几个配置项，这样对于他们来说成本是最低的。

当然从技术的视角去看，那就是技术为业务赋能，技术降低业务开发人员使用技术的学习成本。

当这种类型的工程师工作几年之后，就会发现自己原来只是一个所谓的CRUD工程师。

当然这里给大家列举这个案列，就是想告诉大家，其实我们完全可以不用做一个纯碎的CRUD工程师。

（1）面对重复的业务需求，我们一定要做到快准狠，也就是一定要高效的去做完，这样你才会有更多的时间去思考更深的需求的技术解决方案，并总结出哪些需求是高质量的，并在自己的工作计划中，制定对应的优先级，当然这个优先级和项目的优先级可能会存在冲突。

（2）将简单的需求复杂化，这点可能不太好理解，简单的解释一下，那就是要将高清楚需求背后真正的原理。比如我给大家列举一个简单的例子，那就是你的业务需要添加缓存，那么你有没有去思考本地缓存和分布式缓存的区别呢？我是不是简单的使用一个HashMap就可以实现一个本地缓存呢？也就是说，我们不仅要完成这个简单的需求，还要去延展性的思考一下，在这个简单的需求的基础之上的复杂的需求的技术解决方案。

（3）多将需求可视化，这点真的非常的重要，可能很多人都在问，一个这么简单的需求，我需要画图吗？答案是肯定的，无论你做什么事情，你都要和别人沟通，那么沟通的基础就是有能够可视化的内容，这样不仅方便自己去理解这个需求的实现方式，还能够消除很多沟通障碍带来的歧义。

（4）多关注业务架构，这点真的很重要，并且不要将业务架构简单的理解为画画业务逻辑图，一般在业务开发团队当中，业务架构是非常难做的。假如你做每一个需求，你都会去关注需求背后的业务架构的玩法，那么你肯定不会是一个CRUD工程师。

（5）多去关注技术的细节，这点非常的重要，比如你的项目使用哪些技术，具体的用法和最佳实践，甚至是底层的框架原理都要搞清楚，当你把这些技术细节全部搞清楚之后，你自然会去延展性的去学习相关的新技术。比如你的公司正在使用Spring Boot，那么当你把Spring Boot玩透之后，那么你就会去搞清楚Spring Cloud和Spring Cloud Alibab的玩法，并且这些都是水到渠成的事情，并不需要你花太多的时间。

（6）除了关注业务逻辑之外，还要多关注代码质量，关于代码质量这个话题就太大了，这个就涉及到诸如高性能、高并发和高可用性等话题，也就是说你写完代码，并完成需求之后，除了应付交差之外，你还要看到更多的代码质量问题，尽管现在没有时间去完成，但是将来一旦有时间就要想着去解决。

（7）多去争取参加复杂度高的业务项目，当然这个的前提条件是你要做好你眼前的小需求，你才会有更多的机会去争取更多的资源去做新的复杂度高的项目。这里我可以告诉大家，复杂度高的项目，肯定是需要业务架构，并且对工程师的硬技能要求会更高，这个就绝对不是什么CRUD工程师就可以解决的。

（8）不要把自己训练为百度搜索工程师，这个就是说当你在做业务项目的时候，碰到技术问题，一定要自己多去思考技术的本质，以及如何去规避这些问题，久而久之你就会形成一种独立的快速解决问题的思维能力。

总之，那个就是你不要将自己的工作内容局限于自己负责的项目和需求上，你一定要做到放长线钓大鱼，也就是说要做到技术和业务预判，并且确保预判的准确性。

真的不是你的技术菜！！！

这里我其实很想说一句话，那就是“真的不是你的技术菜”，只是你没有花时间在技术上。

大家可以尝试去思考一下，假如你每天都会打开github网站，去关注一些新技术项目，并且下载一些项目的源码，并在自己比较闲的时候去查阅一下源码细节，那么你会忘记这些技术吗？这个也是很多开发人员都在说自己总是记不住技术原理的原因。

当你把技术的沉淀当做是一种习惯的时候，那么你肯定会记住很多技术原理的。

一个优秀的工程师必须要具备的基本素质那就是要“勤快”，所谓勤能补拙就是这个道理。

大家可以去思考一下，很多人说自己的技术很菜，本质上就是自己不够勤奋，并且也不愿意花时间去学技术。

你看看小编，就算事再忙，我也会花时间去写写公众号文章，一方面是自己想去做做自媒体，另一方面小编也就当是写日记一样，去记录自己技术成长的路径。

好吧，我只是想告诉大家，别闹了，真的不是你的技术菜！！！，每个人都是有机会成长为技术大咖的，就看你愿不愿意去花时间做沉淀。

另外我的新书RocketMQ消息中间件实战派上下册，在京东已经上架啦，目前都是5折，非常的实惠。

https://item.jd.com/14337086.html?编辑https://item.jd.com/14337086.html

“RocketMQ消息中间件实战派上下册”是我既“Spring Cloud Alibaba微服务架构实战派上下册”之后，又一本历时超过1年半的巨无霸技术实战类型的书籍。

为了提高读者阅读本书的体验性，本书总共设计了十个特色，下面我一一的给技术小伙伴阐述一下。?

【特色一】由浅到深

本书将RocketMQ的技术原理和最佳实践体系化，按照由浅到深的顺序呈现给读者，使读者可以按照章节顺序按部就班地学习。当学习完全书内容之后，读者不仅能熟悉RocketMQ的核心原理，还能充分理解RocketMQ的“根”。

【特色二】技术新

本书不仅包括RocketMQ4.x（4.9.2版本）的核心原理分析和最佳实践，还包括RocketMQ5.x（5.1. 0版本）的新特性分析和最佳实践。

【特色三】精心设计的主线：零基础入门，循序渐进，直至彻底掌握RocketMQ

本书精心研究了程序类、架构类知识的认知规律，全书共分为6篇：①基础；②进阶；③高级；④高并发、高可用和高性能；⑤应用；⑥新特性，是一条相对科学的主线，让读者快速从“菜鸟”向“RocketMQ分布式架构实战高手”迈进。

【特色四】绘制了大量的图，便于读者理解RocketMQ的原理、架构、流程?

一图胜于文，书中在涉及原理、架构、流程的地方配有插图，以便读者更加直观地理解。

【特色五】从架构师和技术专家的视角分析RocketMQ?

本书创造性地分析了RocketMQ具备高并发、高可用和高性能的功能及原理，并从架构的视角展开分析，这些也是程序员进阶为技术专家或架构师必备的技能。

以下为从架构师和技术专家的视角分析RocketMQ典型案例，读者阅读完本书之后，也能够达到这样的水准。

【特色六】不仅有原理分析，还有大量的实战案例?

本书介绍了大量的实战案例，能让读者“动起来”，在实践中体会功能，而不只是一种概念上的理解。

在讲解每一个知识模块时，我在思考：在这个知识模块中，哪些是读者必须实现的“标准动作”（实例）；哪些“标准动作”是可以先完成的，以求读者能快速有一个感知；哪些“标准动作”具有一定难度， 需要放到后面完成。读者在实践完书中的案例之后，就能更容易理解那些抽象的概念和原理了。

本书的目标之一是，让读者在动手中学习，而不是“看书时好像全明白了，一动手却发现什么都不会”。通过体系化的理论和实战案例去培养读者的主动学习能力，这样本书的价值就会被最大化。?

本书相信“知行合一”的理念，而不是“只知，而不行”，避免开发人员出现眼高手低的现象。尤其是在技术面试过程中，面试官更加看重的是既懂原理，又能够主动是实践技术的技术人。

【特色七】深入剖析原理?

?本书以系统思维的方式，从业务功能视角剖析?RocketMQ?底层的技术原理，使读者具备快速阅读?RocketMQ?框架源码的能力。读者只有具备了这种能力，才能举一反三，实现更复杂的功能，应对更复杂的应用场景。

?【特色八】从运维的视角分析?RocketMQ?的最佳实践

【特色九】参与开源?

?本书向读者展示了如何修改?RocketMQ?源码，并快速验证案例分析。这样，读者可以从中学到参与开源的技能，并为后续自己能够参与开源做准备。

【特色十】双色印刷，读者体验会更好?

为了提高读者阅读本书的体验，在有上下两册的前提下（巨无霸，超过800页），出版社不吝啬印刷成本，依然采用双色印刷。

【推荐】本书的最佳学习路径?

?为了提高读者学习RocketMQ的效率，我这边结合我自身从RocketMQ小白到RocketMQ专家的经历，为读者汇总了一条最佳学习路径。

【寄语】作者寄语?

RocketMQ是我深度参与研究的一款开源消息中间件，无论是从源码，还是架构场景，我都提炼了很多最佳实践。

在开源领域，技术小伙伴可以使用的开源消息中间件非常的多，比如Kafka、Pulsar等，我之所以选择研究RocketMQ，除了工作内容和角色需要之外，更多的还是自己感兴趣，因此我建议技术小伙伴一定要先培养自己的兴趣，兴趣才是提升技术硬实力的第1要素。

当然我并不止研究了RocketMQ，还研究了Pulsar和Kafka等（包括开源消息中间件生态中的主流框架），只是本书作为一本关于RocketMQ实战派的书籍，我必须要以RocketMQ为主。

假如技术小伙伴想成为Java领域的架构师或者技术专家，我强烈建议你去研究RocketMQ，它会给你带来很多意想不到的技术和架构方法论的收获，这个也是我写本书的主要目的之一。

建议技术小伙伴按照本书设计的学习路线，逐章的去阅读和实战，这样学习效果会更好。

如果技术小伙伴有技术交流的，可以通过博文视点官方的读者群找到我的联系方式，并与我沟通，我会实时的解答读者的疑问。

本文公众号“架构随笔录”

本人视频号“架构随笔录”

【博文视点】2021年度优秀作者

2021年我和博文视点合作了一本技术类型的书籍“Spring Cloud Alibaba微服务架构实战派上下册”，它是我涉足知识输出领域以来的第一本书，同时它也是我自己积累的技术池中部分技术的产出。

为了写好那本书，我几乎花费了所有的休息时间，并主动的承担了书的售后技术辅导和咨询的职责（几乎是有问必答，坚持了整整两年）。

所谓有付出总会有回报，Alibaba这本书的销量还不错，我也因此获得了博文视点颁发的2021年度优秀作者。

我很清楚，这个是博文视点为了鼓励我继续去用心写书，因此我又花了接近1年半的时间去写了RocketMQ消息中间件实战派上下册这本书。

所谓一分耕耘一份收获，我将我对RocketMQ的理解体系化的输出给喜欢技术的技术人，希望真的对大家有帮助。

?【博文视点】2023技术成长领路人

2022年，我开始涉足技术直播和技术讲师领域，并和博文视点合作几次技术直播，直播效果还不错，再加上我孜孜不倦的布道“Spring Cloud Alibaba微服务架构实战派上下册”这本书相关的技术，并且这些技术都是有助于“技术人”快速成长的，因此也获得了博文视点颁发的“2023技术成长领路人”这个技术奖项，这个奖项也是为了鼓励我继续通过技术直播的方式给技术人去布道技术，因此只要我有时间，我就会孜孜不倦的去讲和聊技术。

【四维口袋】2022 KVP最具价值技术专家?

2022年，我开始涉足企业培训和相关技术直播，并和“四维口袋”合作了几次技术直播，并荣获了2022 KVP最具价值技术专家的技术奖项。