苍何_社区达人页

一、前言 在 IT 圈子有一个有趣的现象，一面是供给市场的饱和，一面又是需求市场的一岗难求。仿佛对于 5 年以内的程序员，市场总是供大于求，找工作不大容易，今年的互联网更是成了小金融圈子，拼学历拼背景，而对于 5 年以上或 10 年以上的业务专家的需求，需求企业又是在猎头和招聘平台间不断抢人，不是技术不足就是经验不够。 不知道大家是否有想过，为什么会出现这样的情况？ 经常看到大家关于技术能力和业务逻辑哪个更重要的问题争论不休，如果你对此话题感兴趣，不妨继续往下看看。 二、技术能力的重要性 2.1、技术能力的定义我们在谈技术和业务谁更重要之前，先理清一点是不管怎么说，技术能力是我们作为程序员这个职业的根基，基础扎实是积累经验和进一步成长的基石。技术能力确保我们有能力构建、优化和维护软件，使其具有高性能、高可用性和可扩展性。 ● 编程技能包括编程语言、算法、数据结构以及编写高质量、可维护代码的能力。编程技能是技术能力的核心，涵盖了各种编程语言和开发范畴。具备了编程技能才能有的放矢，能看得懂代码，理解编程原理是程序员的核心技能。 ● 开发工具和框架涵盖了使用开发工具、集成开发环境（IDE）、版本控制系统、测试框架以及各种开发框架和库的能力。这有助于提高开发效率和质量。通过高效的工具进行高效编码，并将编写好的应用程序进行部署发布也是核心掌握的技能。 ● 系统架构包括对操作系统、网络原理、数据库设计和系统架构的理解。这方面的知识使得我们能够构建稳健、可扩展的应用程序和系统。这是技术能力的进阶部分，需要对系统做全盘的技术了解以及需要掌握设计模式。 ● 问题解决和学习能力技术能力的第四大体现就是问题解决和学习能力，能不能通过上面说的三大能力，即编程技能，开发工具和框架、系统架构去实际解决业务的问题也是技术能力的体现之一，另外新技术迭代很快，学习能力也是技术能力的体现之一，有些人学习能力强，一项新的技术花费的学习时间甚至比别人更短，掌握也更高效，这就是学习能力的体现。2.2、技术强的优势李白的 “兴酣落笔摇五岳，诗成笑傲凌沧州” 正表明技术强走遍天南地北都不怕，于我们程序员来说，也有一定的适用性。技术强不仅受人尊重而且往往能独当一面，成为某个系统的 owner，独立负责某系统，往往也能得到领导公司的喜欢，在公司内部的晋升很多都是技术实力表现非凡并做出突出贡献者。 技术强还有个最大的优势就是能让我们顺利的通过面试，有竞争力，拿到高薪的工作。比如同等学历背景下，如果 A 的技术实力远超 B，考虑岗位需求，大部分会选择 A，即使 A 要价高于 B，对企业来说，与其多招几个要价低但技术一般的人，倒不如招一个技术强的实力派，往往能达到「一个诸葛亮，胜过三个臭皮匠」的效果。 另外一点可以靠技术能力吃技术的红利，什么意思呢？我们知道现在是知识付费时代，想通过免费能获取到优质的知识是比较难的，很多技术大佬都开了公众号以及知识星球，并做成了类似于《掘金小册》这样的付费产品，通过卖技术形成产品的前提是要有好的技术，这也造就了很多的「财富自由」。 2.3、如何从写业务代码中跳出来，有效提升个人技术能力？平常业务开发的绝大多数时候，我们做的都是 CRUD 的工作，久而久之，发现吃老本行技术也能足够支撑，不愿意去投入学习，导致技术能力永远停留在开始的水平，等换工作或者运气不好被裁准备简历面试的时候，才发现，自己好像除了 CRUD 也没其他好讲的了。这种情况该如何破局呢？我认为可以从以下几个方面从写业务代码中跳出来，有效提升个人技术能力。 2.3.1、持续学习新技术计算机技术日新月异，保持持续学习才能不被时代抛弃。印象比较深刻的是，以前比较火的 java SSH 框架风靡一时，很多企业都在使用，后面由于漏洞以及模块化 SQL 的兴起，又开始流行 SSM 框架，随着发展 SpringBoot、SpringCloud 又成为了主流，JDK21 都发布了，而你连 java8 的 stream 还没玩明白，这就是落后于时代，落后于技术，是很危险的。 很多人说，平时工作忙，加班多，CRUD 就已经耗费了绝大部分精力，想说「时间挤挤总是有的」，但还是想举个一位阿里朋友的例子，平常工作基本都需要加班，晚上回家还得带娃，但依旧挤出时间来学习，写了书、每周至少 2 篇高质量文章的输出。所以，没时间不是接口，从内心愿意去学习并规划好时间，持续学习。 2.3.2、开展个人项目并参与开源社区开发自己的个人项目或者参与到开源项目的共建上。开发一个自己的个人项目可以把学到的新的或者你认为比较有创新的技术框架、设计模式运用到你自己项目中，可以的话发布到开源社区，让全世界的开发者来检验你的项目，是提升技术能力的一个重要手段。 我们平时工作中的业务代码可能没法使用到新学的技术或者因为企业追求稳定的原因并不能应用，那我们自己开源的项目完全可以，而且开源项目也可反映我们的技术能力和水平，在找工作面试也有一定帮助。 除了自己整开源项目，也可参与到熟知的开源项目中来。有个学弟在大学期间就参与到著名的开源项目的建设中，贡献了一些不错的 Feature 后，成为了 MVP ，校招找工作具有极大的优势，最终也轻松收获多个大厂 Offer。 2.3.3、参加技术研讨会周末把用来打游戏的时间多去参加一些技术沙龙、研讨会，能够掌握最新技术的发展动向，并有机会结识大佬。每年许多大厂和社区论坛都会举办很多的线下会议，比如今年阿里举办的「云原生会议」，如果离你所在的城市不远，可以去听一听，对技术的提高和敏锐是有很大帮助的。 2.3.4、尝试输出你学习到的知识不是你的，只有真正会用的知识才属于你。学以致用另一种比较好的方式是，把你对技术的理解，形成自己的文章或架构图，并整理尝试输出到互联网，接受批评和指正。就拿 java 领域来说，我们可以看到很多的技术博文，很多你可能看了觉得也就那样，自己也能写甚至能写的比他好，但相信我，你一旦尝试去输出，就会发现优秀的文章绝不是一朝一夕形成的，一定有个过程，从量变到质变的过程。 多输出，加强对技术的理解，对技术的提高会有意想不到的帮助。 三、业务逻辑的重要性 我花了大量的篇幅讲述技术的重要性并对如何从写业务代码中跳出来，有效提升个人技术能力做了一些个人建议，并不是想说技术一定比业务更重要， 在权衡哪个更重要前，我们需要理清两者之间各自的定义及优势。3.1、业务逻辑的定义业务泛指一切组织或公司所从事的各种商业活动和运营工作，通常是和行业领域有强相关性。通常我们将业务分为经营性业务和非经营性业务，经营性业务通常是指和公司运营盈利所挂钩的业务，如抖音这个产品里面的抖音电商就属于经营性业务，公司需要靠这个来盈利；非经营性业务指和公司运营盈利无关的业务，如企业内部系统，仅仅需要满足内部的使用，即使不盈利也要展开的业务。 另外我们也可以把业务按照行业的属性来划分，如房地产业务、经融业务、互联网业务。不管如何对业务进行划分，我们能知道业务是种类繁多的，而且大部分业务都有自己特殊性，从一个业务转到另一个业务，是需要一定的学习成本的，这也是通常人们所说的「隔行如隔山」。 3.2、业务逻辑强的优势业务逻辑强，也即在一个行业领域有丰富的经验。优势很明显，在一个行业领域的经验越足，在该行业领域的不可替代性越强，越容易成为业务专家。我们知道对于有些业务没有沉淀个几年，是不能说了解该业务。最具代表性的是阿里的 「5 年陈」文化，我们在阿里的时候，入职阿里一年的叫“一年香”，入职 5 年的叫“5 年陈”，当入职满了5年的时候，会收到一枚刻有工号和花名的戒指，同时 5 年才是马云所认可的阿里人。所谓被认可，其实除了文化价值观认可外，最重要的还是认可你对阿里公司及业务在 5 年时间里有了认知，从了解到熟悉的 5 年，是阿里人的荣耀。 为什么我们经常在很多招聘的 JD 上看到岗位描述时候会带上「有 xxx 经验者优先」，特别是招聘的职级越高，这种现象越明显。 可以看到招聘上对于 1-3 年的开发并未要求有业务经验，而对于 10 年以上招聘要求中就列明了「有相关经验者优先」。业务能力强在某一领域更有权威性，经常我们出去开会，看到演讲的嘉宾张口闭口都是，我在这个行业干了 10 年 ，意思是恕我直言，在座的各位，你们没人比我更了解这个行业，开始听我吹逼吧...... 不过想想也是，一个人在一个行业深耕了 10 年，确实对该行业熟知。那对技术人来说，熟悉业务有什么优势呢？ ● 更好的问题理解和解决能力熟悉业务流程，对开发和系统设计有很大的帮助，我们的很多系统为什么觉得不好用，最大的原因还是没有深入到业务场景中去。比如，让一个在地产领域工作的开发去研发医疗程序，在系统设计的时候，会自然而然的用房地产程序设计的思想应用到医疗行业，会发现根本不适用，虽然功能看似暂时可用，但长期一定会出现架构和稳定等各种问题，业务理解的深浅，直接影响系统可用和稳定。 ● 更高的创新能力创新一定是能在一个领域有非常深的认知后才去做创新，比如设计一个高可用的创新型电池系统，如果你连电池最基本的 SOC、SOC 以及充放电特性都不清楚，上来就直接搞一个可无限充电可折叠的电池系统，那就贻笑大方了。 ● 更好的沟通和合作我们经常听到客户反馈，和我们的有些开发沟通起来比较费劲，抛去个别同事性格因素外，还有一点比较重要的是，客户关心的还是聚焦在具体的业务上，而开发更关注与技术，在探讨同一个问题的时候，就会出现「公说公有理婆说婆有理」的尴尬画面。掌握业务，能更好的和客户沟通。 ● 更多的职业发展机会我们经常看到很多程序员转行做了产品经理、项目经理、市场、客户服务，甚至有些出来自己经营公司，这都需要归功于对业务的深入理解，能为我们更多的职业发展机会，面对 35 岁危机的时候，也能在职场中占据一席之地。 3.3、如何避免过度关注技术，而忽视业务理解？技术能力很重要，但过度关注技术而忽视对业务的积累，会降低我们的职场竞争力。我们经常会陷入另外一个误区，认为只要我技术足够强，就能走遍天南海北，就能一直能找到好工作。在工作前几年这条规则适用，但越往后，特别是到了 35+的年龄，加班加不动，技术学不动的时候，我们缺少业务沉淀，是很危险的事情。 特别是对于刚毕业的同学来说，去了一家公司发现技术落后，于是想换工作，想找个高并发的项目，换来换去发现，为什么现实中和我想象中差距这么大？不是现在都人手微服务分布式了吗？我这样怎么提升？ ● 没有业务的技术不是好技术任何一门技术一定是服务于业务的，如果没有业务场景的技术，那这个技术是个空的技术，技术的诞生本来就是用来解决实际问题的，要用好的技术来服务于业务，在我们过度关注技术精进时，静下心来，把手头的业务逻辑梳理清楚，想清楚哪些可用技术优化的点，而非单纯的考虑技术先进性而不考虑适应性。就比如，不是每个系统上来就得分布式微服务的，一个简单的内部系统，QPS 不到 40，你说整个微服务上去有什么用？ ● 平常工作多画业务流程图我们接手一个项目业务时，最先做的不是上来就去撸代码，而是要根据 BRD、PRD 去梳理业务流程，争取用我们自己的逻辑画出业务流程图，并和 PD 业务方做 check，之后对着代码逻辑再次梳理一遍业务流程图，加深对业务的理解。 ● 多参与业务讨论和方案设计经常很多开发参加 BRD 或 PRD 评审时，总觉得这是业务方和产品对齐的事情，和开发没关系，不会到时候问产品就行了。大家有没有想过，为什么我们需要开发这个功能，这个产品或功能能实际为用户带来什么价值，我们的工作一定是要有价值的才不会觉得卷和累，所以多参与业务的讨论和方案设计，站在开发的角度去理解业务和产品。 ● 去关注行业知识和行业峰会每年我领导都会去参加行业的峰会，在峰会上，像个学生似的学习最新的行业知识，所以现在他是行业技术专家，在公司没人比他更了解业务。在行业峰会上，这些最前沿的业务知识，行业动态能够最先知道，每一个行业都有一些论坛和社群，比如公众号，我们可以多关注一些行业的。 四、业务和技术如何权衡？ 既然业务和技术都如此重要，那到底该如何权衡呢。 4.1、初期以技术提升为主在我们刚开始工作 1-3 年，我觉得还是以技术提升为主。因为学校学的知识和企业实际项目会有一定不同，将学习知识落地项目的过程是需要技术的提升的，除了平时的项目开发，需要打牢技术基础。 所谓：“基础不牢，地动山摇。” 初期需要打牢基础，越往后越发现，很多新的框架技术的底层一定来源于专业基础，比如计算机原理及网络，操作系统、数据结构和算法。包括经典的中间件，如果能掌握他们的设计思想，如 Redis、Hbase、EleasticSearch、RocketMQ 等，也会对技术能力提升有个质的飞跃。我建议新技术以视频切入后，往深的理解，需反复阅读经典图书，比如《Redis 深度历险》、《深入理解 Kafka 核心设计与实践原理》、《ElasticSearch 实战》、《深入理解 Java 虚拟机》等等。4.2、中期注重技术和业务积累在工作 3-5 年阶段，除了技术的积累，还需要做业务的沉淀。这个时候找工作往往是不关注行业的，但在 CRUD 的同时，需要积累业务知识，换工作也尽量往相同或相似领域倾斜，比如在电商领域就不要一下子 360°大转弯换到房地产领域去了。 这个时候还不需要做细分领域的切入，做大致行业的协同即可。技术上需要开始形成产品化，将积累的技术知识通过传授分享形成自己的技术产品，多参与开源建设，多在技术社区活跃，多链接一些技术大牛。4.3、后期注重业务深耕和沉淀在工作 5 年之后，我们积累了一定的技术能力和项目经验，这个时候需要更关注业务。我们在换工作的时候，可选择性就不很多了，最好是切合该领域的选择跳槽。在某一个细分领域去沉淀，打造该领域下的 IP，做业务专家。这个时候不管是做了架构师，还是做了技术管理，亦或是还在一线奋斗，最重要的是要从代码中抽离出来，形成自己的业务闭环。需要把积累的业务知识通过互联网分享出来，多参加行业论坛和会议，并能作为嘉宾发言，多分享行业认知，积累行业人脉和资源。 只有当业务知识积累到一定程度，才有可能突破职业瓶颈，过了四十岁写不动代码了，我们至少不用仅在送外卖和摆地摊之间做选择，大不了我们可以做项目管理、做市场、做产品经理，给自己未来多一份选择，从现在开始做起、 五、总结 总而言之，在工作起步阶段，我们应更关注技术的提升，越往后，越需要多关注业务，形成技术和业务的双护城河，在职场中，做到有的放矢。 创作不易，如果本文对你有帮助，欢迎点赞、收藏加关注，你的支持和鼓励，是我创作的最大动力。

做了五年开发，现在正在做技术部门的负责人，带领几个小伙伴，刚接触管理，才发现管理没想象的那么简单，管理也并非是不用code或者并非是不懂技术，一个好的管理一定是对技术广度或者某一领域的深度比只code的程序员是要更懂一些的，我就目前做管理和code的一些感受分享给大家，希望能给大家一定的帮助： 1、管理事情会比较杂，各种会议、各种对接，都需要参与 2、code只需要关注需求，将需求用code落地即可，有时甚至都不需要过多关注产品，因为会有产品经理帮我们规划好了，只需要去执行 3、管理需要更多领域业务知识，在布置任务时要有自己的规划 4、管理有时会比code更迷茫，在这家公司能做到这个级别，如果换了一家，怎么能做到这个级别呢？而且每个公司对管理要求也不一样 5、code技术比较纯粹，没有太多的人情世故，管理大部分时间需要跨部门协助，组织间的沟通需要管理沟通表达和情商都要高一些 6、管理比code能掌握公司或者行业更多的信息，接触到更多优秀的领导，对拓宽自己人脉和业务知识有很大帮助 7、一个管理岗位的机会的获得也不是那么简单的，需要机遇，如果有这个机会，我觉得可以让自己尝试一下，没做过就没办法评价，也没法知道自己适不适合。