本文主要是介绍盘点大部分程序员（架构师）都会走的弯路（有则改之无则加勉），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
写在前面
很多程序员，其实并不是出身于BAT等大厂，而是在一些中小厂为公司为自己发光发热。
一边努力学习着技术，一边应对着工作中不停的CRUD、应对着产品经理不断变化的需求。有时候静下来也会迷茫：自己怎么才能突破当前的舒适圈？自己这几年来所做所学所用是不是正确的方向？
今天咱们就一起梳理一下，那些大部分程序员都会走的弯路（不服来辩~）。
一、技术第一，业务、情商、沟通去一边吧
很多技术小伙伴，尤其是刚毕业、工作年限不久的，在工作过程中，对技术有着非常执着的追求。一度认为“除了技术以外，其他都不重要”。
于是，不再去熟悉公司的业务，不再去在乎同事之间的关系，不去揣测领导的意图。看起来非常的潇洒：我有技术在身，此处不留爷自有留爷处！
实际上确实是这样，对于初级、中级甚至高级程序员来说，技术实力就代表着你个人的能力。但是工作时间一久，尤其是5年以上，会发现技术根本是无穷无尽的，每天都在平稳的进行自我技术的提升，但是成效却并不是线性的增长了。
这也就是说，其实遇到了一个职业生涯的“瓶颈期”。
到了你职业发展的瓶颈期，往往制约你的不是技术能力，而是个人的“软实力”。
全面发展，去锻炼自己技术以外的软实力，才是打开职业生涯突破口的一个关键。
在努力学习技术的过程中，刻意的关注业务、多提高自己个人的“软实力”。
一个产品和业务员，如果去学习一些技术，这无疑是非常困难的，但是作为一个程序员，去了解业务，简直不要太简单。如果一个程序员不光去立足技术，还对业务有一定的深入，思考问题的时候既可以从技术视角，也可以从业务视角出发，这样一来，可以去深度挖掘业务，突破自己的职业瓶颈，成为公司的中层高层。如果只关注于自己那一亩三分地的技术，是很难在一个公司得到晋升的，尤其是互联网公司。
提高自己的软实力，可以考虑将自己走在聚光灯之下，不要将自己只当一个幕后英雄。我们鼓励并欣赏幕后英雄，但是掌声是献给演员。所以怎么在职场表达自己，这是一个很重要的问题。很多程序员，都在深挖技术，沟通起来像一根木头，仿佛除了闷头写代码再没有什么能够打动他们的了。但是如果你能做一个又善于沟通、又善于分析、情商还不低，那就一定会在一群程序员中脱颖而出。“酒香不怕巷子深”的理念在职场是很难行得通的。
但是！工作1-3年的程序员们，还是要以技术为主，只有自身实力硬，才需要考虑“破局”之策！
二、盲目追求大公司的技术解决方案
BAT等大厂，对于很多中小厂的程序员来说就是遥不可及的“神之领域”，似乎从里面流传下来的东西，都散发着让人陶醉的气息。
也不怪朋友们，毕竟在企业中，面对枯燥的CRUD，自己免不了想多学点技术，丰富一下自身。而大厂的开源框架、解决方案更是学习资料中经常会出现的。
当自己学到了一项技术之后，就不免的感叹：哇~原来还可以这样搞。让人不免有一种“朝闻道夕死可矣”的感觉。于是，开始“东施效颦”，大厂这样搞，那我们也这样搞！
于是，开会的时候，跟领导提：“淘宝这样搞，我们也可以借鉴”、“美团这样搞省了多少成本提高多少效率，拿来把你”。做技术、做架构就是这个简单吗？
其实不是，大公司做技术选型，很多情况都是有其先决条件。比如说使用k8s、使用serviceMesh这种非常火的技术。但是很多小企业并不适合引入，因为这对技术人员、运维人员都有着很高的要求。
对于大厂来说，他们的技术团队的技术能力是非常顶尖的，他们有使用那些技术的能力和资本，所以应用的这些技术，在我们公司并不可行。也就是“经济基础决定上层建筑”，团队的能力和规模没有达到这种水平，盲目的追求只能是花费大量的时间和投入来踩坑。
再者，我们还需要考虑当前的业务体量，是否真的有大厂的那么高的并发，是否需要保证那么高的可用性？追求高并发、高可用、高扩展的架构，固然是好的，但是我们更应该结合实际，来选择更加“经济适用”的方案。引入的技术越多，使用的解决方案越新颖，看起来非常的酷炫，但是对公司来说，花出去的都是真金白银。大部分的企业还是需要挣钱的，没有“土豪”企业随随便便就一掷千金。
所以，在公司进行技术选型时，盲目追求大厂的现成的方案，无疑是一个偷懒的行为。需要首先判断该技术选型是不是适应自己公司的业务，当前公司的业务量和并发量是否真的能达到大厂的级别。
大厂的解决方案可以作为技术选型的借鉴参考，可以稍作简化进行适配当前公司业务场景；可以考虑性价比非常高的方案，使用大厂的云平台，将大厂的一些现成的技术能力利用起来；也可以将大厂的技术和解决方案作为自己和团队的知识储备，扩展自身的视野，对自己有所提高。
三、追赶时髦技术，对旧技术嗤之以鼻
很多对技术比较敏感的小伙伴，会经常翻阅一些博客、文档等，很多新技术刚一出来，就跟着官方文档、大佬的脚步学完了。
比如说，最近刚出的JDK21，其中有一个热门的新特性协程。这些小伙伴眼前一亮，哇塞流批流批，我要用！于是用在了项目中，其他同事小伙伴一看，哇这是什么？于是满足了非常强的虚荣心。但是实际上线之后，一个个的坑接踵而至。
其实，对于公司来说，应用最新的技术，是需要从新技术的优势和成本来综合考虑的。看新技术是否能给公司带来效率，降低成本；从长远来看，业务增长的规模，是否有必要使用新技术；以及新技术带来的学习成本和投入成本，以及效益产出。
对于个人来说，应用了新的技术，这也是自己能力的体现和实践经验的一次尝试，也算是将新技术落地了。但是呢，比如说最近刚学习的设计模式，于是在业务代码中大量使用设计模式，遇到if-else就改成策略模式，遇到new对象就改成工厂模式，继承和接口的大量使用，自己玩的爽了，但是后来者维护你代码的时候，要多痛苦就有多痛苦。
技术永远是为业务服务的，做开发永远是一个团队的工作而不是个人的。一个新技术的落地，不光要结合当前的业务，还要考虑团队小伙伴的综合水平。这也是我们开篇第一条提的，一味的做技术，并不会达到一个很高的高度。
注意！风口上的技术不要盲目去追！
四、“面向PPT编程——纸上谈兵”
有相当一部分的技术小伙伴，喜欢看一些技术分析贴。比如说，分布式锁的应用，读写分离的好处等等。但是“纸上得来终觉浅”，空有理论知识，但是缺少动手实践，终究是一场空。也就是“知其然而不知其所以然”。
大量的理论知识，需要配合实际开发过程中的实际动手经验才能理解其中的深意。
我曾经面试过一个非常优秀的应届生，从java基础到微服务，再到分布式系统架构，说的头头是道，仿佛已经在业内已经是大师般的存在，于是高薪聘请进了公司。但是进公司之后，项目捣鼓了半天没跑起来，甚至很多基础的东西都搞不明白。
这并不是为了抨击理论而抬高实践。事实上，有大量理论基础的程序员，在真正进入实战之后，会更加迅速的进入状态，进步的更快。我想表达的是，当理论遇上了实践，那就是如鱼得水，在你头脑中的知识更加巩固，牢不可破。
但是一些从技术向管理转型的程序员，恐怕就没那么多精力去扣细节、扣实践了。对于一心想成为架构师的小伙伴们，实践才是真理！
能说会道固然能增加面试的成功率，面试的时候吹得再高大上，入职之后无法落地，那终究是笑话一场。
五、会的多vs会的精？
现在的招聘岗位，动辄需要：精通SpringBoot、SpringCloud、MySql、MongoDB、Redis、RabbitMQ、Docker、K8s……
看起来非常唬人，也确实如此，纵观JavaWeb开发的10年，从ssh到ssm再到springboot、springcloud，技术的广度无疑是爆炸式增长的。这也意味着程序员只会“越来越卷”。
没办法，入了这行就要有这个觉悟，就要“认卷”。否则的话，就只能安安稳稳的当一个CRUD工程师，成为一名真正的“码农”。
于是乎，很多小伙伴看到一个新的技术，就迫不及待的从网上查一查它的用法，写个Demo，大呼：哦~原来如此，我懂了。
一个技术要想研究的很深，真正达到“精通”的地步是非常困难的。比如说，使用一门技术，在1万QPS和10万QPS下，所思考问题的深度是完全不同的。
所以要清楚的找明白自己的定位，在当下的业务场景下，需要自己将技术研究的多深，多广。
当然，对于技术，当然是“多多益善”~ 但是一个人的精力是有限的，与其什么技术都会一点，会写个Demo，不如去好好规划自己的技术栈。
六、学完就忘
其实这也是很多小伙伴们苦恼的地方，不光是程序员，其他岗位的朋友也经常这样。
技术这个东西，其实并不需要死记硬背，甚至还有一些“天赋”在里面。
学习是需要记笔记的，猛龙过江之后，留下的仍然是一片平静的湖面。很多小伙伴坚持学习、坚持记笔记甚至写博客、提交开源代码，这是非常难能可贵的一个好习惯。
记笔记也是有方法的，最好是形成自己的“知识库”。我不需要每一个知识点都完全掌握，可以将一个个知识点串起来，搭建自己的知识体系，形成自己的知识图谱（知识目录），当遇到问题之后，自己知道有哪些方案去进行解决，然后解决的过程中将自己的知识图谱中的落地的细节进行填充。空闲学习的时候也可以不断地填充自己的知识图谱，慢慢积累。
虽然达不到过目不忘，但是留下痕迹，再根据痕迹去追，简直不费吹灰之力。
这篇关于盘点大部分程序员（架构师）都会走的弯路（有则改之无则加勉）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
