纠结，是做技术还是做业务呢？

最新推荐文章于 2025-11-27 04:59:42 发布
最新推荐文章于 2025-11-27 04:59:42 发布 · 615 阅读 · 0
文章标签：

#工作

一名拥有五年工作经验的Java开发者感到职业发展陷入瓶颈，对于当前工作的兴趣日渐消退，并且对未来的职业道路感到困惑。

      工作5年，一直做java开发，现在的状况是上不上下不下，感觉什么都不会，但是什么都还能够做的来。最近心情一直都不好，不知道为什么，现在极其讨厌现在的这份工作。我现在都不知道每天自己忙些什么，感觉就是一个打杂的。想静下心来好好写写代码的时间都没有。现在想换一份工作，不知道怎么去选择？现在在公司做产品，做公司的运营平台，感觉现在是要业务没有业务，要技术也没有技术。郁闷啊！

iteye_7469
关注
14、信息技术的新角色：从技术极客到业务驱动
tomato的博客
10-06 20
本文探讨了信息技术从传统技术极客角色向业务驱动模式的深刻转变。随着云计算的发展，企业得以将数据中心运营外包，使IT团队更专注于支持核心业务流程。CIO的角色正演变为业务战略推动者，未来甚至可能成为CEO。文章强调敏捷性在应对快速变化市场中的关键作用，提出‘定义-设计-构建’的三步敏捷流程，并通过酒店集团案例展示敏捷转型的实际成效。同时，展望了人工智能、区块链和物联网等技术对未来IT角色的影响，呼吁企业培养懂业务的IT人才，加强跨部门协作，采用敏捷方法，以实现持续创新和竞争优势。
中年程序员应该专注业务还是技术？
程序员技术专栏
06-26 899
二十岁时支配作用的是意志，三十岁时是机智，四十岁时是判断。 ——富兰克林 人到中年，就不只是努不努力的问题了，更重要的是要选对方向！时间不等人。 和身边很多中年程序员也聊过，到底是走管理还是技术专家路线？专注业务还是深耕技术？今天就从这两方面和大家分享一下我们的看法。 01 选择精通业务吗？ 结论我后面讲，我先讲讲我一个中年朋友的故事。 他如愿进了大厂以后，负责一个相对稳健的业务，之前也做过类似的业务，但是后面他熟悉的业务慢慢停止了增长，进入到了维护期。 最后.
技术人员的最终出路
cunzhangxp的专栏
04-28 1283
虽然是希望这个论坛成为一个纯技术性论坛，但作为一名技术人员，我总是对未来的前景感到一阵阵悲哀。有感于对这个投票贴的名字，发表一点自身的感慨。　　做为技术人员，大家都觉得工资高，工作稳定，还能学到很多的东西。是大部份走出校门或性格内向，或希望过平静生活的人的必然选择。其实，你们有没有问过自己，这条路到底走对了吗？　　一个刚毕业的大学生，从事销售和从事技术两种不同的工作，可能工资的差距会达到数倍之远。
作为一个程序员你觉得是业务重要还是技术重要？（2）
2501_93078354的博客
09-17 270
一个程序员，如果整天只追新框架、赶技术潮流——今年 Java 转 Go，明天 Kubernetes 切 Operator，REST 换 gRPC，却从不思考自己写的系统究竟解决了什么实际问题，那终究只能停留在执行层，永远被锁定在技术价值链的底端。真正值钱的程序员，是那些能用技术实实在在解决业务问题的人。反过来，如果一个人天天把“增长”“闭环”“商业模式”挂在嘴边，却连一行代码都读不懂、系统架构理不清、数据流和算法都不了解，那他口中的“业务洞察”也不过是空中楼阁，一旦遇到真实复杂的场景，很容易就被打回原形。
马上要毕业了，我是做业务还是做技术？
笔记小屋
04-07 1409
前言    对于还没毕业和准备毕业的同学来说，业务和技术是很奇怪的名词，我是计算机专业的学生，我难道工作后做的东西不是技术嘛？怎么很多人说是做业务的，本文就给大家讲解一下什么是业务和什么是技术。 业务型开发    业务是什么？你开发一个电商网站，用来卖东西，网站建立好了，后面你觉得把客户对商品的评价展示在商品详情页，于是又开始改代码，把评论系统弄好了，这是利用计算机技术实现的一个电商网站系统，并且...
「掘金者说」对开发来讲，业务重要还是技术重要？
掘金者说
04-12 1235
您好，我是掘金者说，最近有点累主要是没有休息好，直接请年假一天在家睡了一天一夜补眠。然后，假期回老家挖笋顺便和姚总监再聊工作上的事情。上回写的是业务功能的对账，现在来讲下在做业务功能“门面”，系统平台的登录后的首页展示，几乎都是报表、统计、圆饼图、柱状图。采用微服务前后端分离，后端spring cloud，前端使用vue+element ui+echart，前后端都是一个人进行弄。原型图改了第一版...
如何判断自己是更适合技术岗位还是更适合销售类的岗位。个人浅见。
weixin_34242819的博客
07-12 378
工作了7年，也做到了部门经理，其中干过一段时间销售，又回头做起了项目管理。所以老被人问：我是应该做销售呢？还是应该选技术？我觉得啊，问这个问题的人，起码一点是非常不成熟的，缺乏对自己的深入了解，同时也有点眼高手低。我的意见是，如果都想做，那就找机会都去尝试，不试试怎么会知道呢？站在岸边是永远不知道水是什么味道的。觉得不对劲的话，大不了上岸，不玩了呗，也不损失什么。别扯什么时间...
对开发来讲，业务重要还是技术重要？
热门推荐
安晓辉生涯——聚焦程序员的职业规划与成长
01-11 1万+
很多开发者为天天写业务代码无暇提升技术而焦虑、苦恼，比如： 又如： 又如： 再如： 那么，作为开发者，到底该怎么面对“写业务代码”这件事呢？ 今天我们就从以下几个方面聊聊这个话题： 什么是业务 业务和技术的关系 业务和因解决业务而衍生的业务 对业务的态度因你在团队中的角色而不同 如何从写业务代码中跳出来，做你所谓的有技术含量的工作 我们先来看看，什么是业务。
软件工程24-技术债务：是继续修修补补凑合着用，还是推翻重来？
qq_53280238的博客
06-26 808
我们在学项目管理金三角时，有一张表示软件质量与时间、成本、范围关系的三角形图，也特别解释了为什么质量要放在三角形中间，因为质量往往是其他三个因素平衡后结果的体现。范围不减，成本不增加，还想节约时间走捷径，就会影响到质量。这个“质量”，不止是产品质量，还有架构质量和代码质量。这种对质量的透支，就是一种债务。而技术债务，就是软件项目中对架构质量和代码质量的透支。技术债务确实是个形象生动的比喻，让你意识到它是和成本挂钩的，而且技术债务也有金融债务的一些特点，比如有利息，再比如技术债务也有好的一面。
Java程序员vs.NET程序员：技术栈博弈背后，是选择还是宿命？
最新发布
威哥说编程
11-27 1013
Java和.NET的“较量”，本质是“成熟生态”与“高效框架”的碰撞，而非“谁优谁劣”的对立。Java程序员的优势，在于“生态广度”和“复杂场景应对能力”，适合需要长期维护、多组件整合的项目；.NET程序员的优势，在于“开发效率”和“高性能”，适合快速迭代、高并发的场景。而对于程序员来说，技术栈只是“武器”，真正的核心是“解决问题的思维”。无论是选择Java还是.NET，深耕技术、积累项目经验、保持学习心态，才是职业发展的关键。最后想说：技术圈没有“永恒的王者”，只有“持续的进化”。
为什么你还在纠结服务器部署？——支付宝小程序 Serverless 架构深度实战指南！
**My Coding Family**
06-05 1112
🏆本文收录于《滚雪球学支付宝小程序开发》专栏，希望能够助你一臂之力，帮你早日登顶实现财富自由🚀；同时，欢迎大家关注&&收藏&&订阅！持续更新中，up！up！up！！
职场菜鸟的抉择：业务、开发OR实施？
yan-it
06-17 972
事情从这里开始： 2013届的毕业生@astli2004 说，一天不写点代码，就觉得心里烦得慌，咋救?在现在这家主要做电信通讯行业软件，为三大运营商做运营支撑软件的公司里，在招聘时说好入职后做开发，实际却被分到其他部门，而老员工又说这里基本很少碰代码，天天研究那些电信业务，顶多就是做些接口开发。 作为一名理工科毕业生，@astli2004认为，一个人不管干什么，首先你得有一门技术在手，
不想做业务的技术控该选什么样的公司？
程序视界
11-01 405
有问有答是程序视界的一个免费问答栏目，感兴趣的朋友，可以按照下面的方式参与：发邮件给 foruok@163.com，标题注明“有问有答”。描述你的困惑或者问题。我每周会慎...
业务与技术
迷茫的专栏
06-07 950
       从业以来一直都有人在争论这两个词，更准确的是业务与程序设计，无非是争论那个更有前途，是应该做技术还是该做业务。其实在我看来，这两个方向根本就不对立，只要你做的是MIS，因为做MIS的程序设计就是要实现业务，不然我们做的是什么呢。只有更熟悉了业务，才能更好的设计程序。其实业务比程序设计要复杂，因为业务的逻辑性往往不如程序那么强，而且现存的业务逻辑也往往存在这样和那样的问题，做技术的另一
技术与业务
规则中找出不规则，挫折中找出突破点
08-15 4827
阅读此博客预计消耗你5~10分钟的时间，欢迎一起评论交流 1. 技术 我们理解的技术，就是系统用户在页面上看到的内容以及操作系统的一系列功能背后的实现方法，我们习惯的称之为技术，技术这个名词不只是存在于软件开发行业当中，更适用于其他行业当中。 总之，技术，就是带有专业性质的行为/思考成果。 2. 业务 业务，是一个比较相对的概念，在平常的工作当中，我们常常会接到许多来自产品团队的业务需求，业务，说的简单点就是系统可以做什么。 管理员/其他用户可以给今天未在系统处理代办的其他用户发送电子邮件，并通知处理系.
前端人生的最大危机不是 35 岁，是你工作3年的那道坎儿
m0_60567881的博客
04-07 262
这份资料是React的专栏，面试题分为基础知识、React组件、React Redux、React 路由这四部分，喜欢这种专栏资料的小伙伴可以评论区告诉小编噢！
对程序员来说，技术能力和业务逻辑哪个更重要？
gb4215287的博客
10-09 383
对程序员来说，技术能力和业务逻辑哪个更重要？
对于程序员来说，是懂业务更重要，还是懂技术更重要
weixin_45116867的博客
03-16 1065
公司想要盈利，需要对客户提供产品，提供服务，所谓的产品就是符合客户日常工作习惯，解决客户日常工作难题的一类产物，就以软件为例，客户不会因为你用了什么高端技术而多给你一部分钱去购买，反而会在意你的产品有没有他想要的功能。不和业务相关联的增删改查都是垃圾，如果不懂业务，是写不出符合客户预期功能的代码的，懂业务意味着理解公司的业务模式、行业特点、用户需求和市场趋势，这样才能更好地满足用户需求，提高产品的竞争力。3.如果你喜爱编程，擅长钻研，喜欢学习，励志成为技术大牛，那么就坚定不移的走技术路线。
浅谈业务和技术哪个重要？
jom31的博客
07-20 635
比如现在有一个业务要开发，你不知道用什么技术实现，所以你会寻找相关的技术来学习和使用，在这个过程中不仅实现了业务，还提升了技术能力，一举两得。再比如你学到一个新技术，突发灵感，用这个技术开发了一个新功能，客户都觉得好用，这个就是技术创新了新业务，从而提升了价值。所以我觉得在开发中，首先要把自有的业务和技术搞清楚，然后在闲暇之余研究一下业务，看能不能有更好的技术去实现，或者说研究一下技术，看能不能创新出新的业务。如果不理解业务，开发出来的东西再牛逼也是白搭，同样没有技术能力支撑，业务也不能更好的呈现。
WebSocket的实现是使用netty还是ServerEndpointExporter呢
02-19
<think>好的，我现在需要回答用户关于WebSocket实现是使用Netty还是ServerEndpointExporter的问题。首先，我需要明确用户的具体需求和背景。用户之前询问了一个关于MQTT和WebSocket结合的项目设计，现在他们可能正在技术选型阶段，尤其是在实现WebSocket服务时，纠结于选择Netty还是Spring的ServerEndpointExporter。 首先，我需要回顾这两种技术的用途和适用场景。Netty是一个高性能的网络应用框架，主要用于开发高并发的网络服务器和客户端。它支持多种协议，包括WebSocket，并且以异步非阻塞的方式处理连接，适合需要处理大量并发连接和高吞吐量的场景。 而ServerEndpointExporter是Spring框架中的一个组件，用于注册使用@ServerEndpoint注解的WebSocket端点。它简化了在Spring Boot应用中创建WebSocket服务器的过程，主要依赖于Java WebSocket API（JSR 356），适合集成在Spring生态系统中，快速开发，但可能在处理高并发时不如Netty高效。 接下来，我需要考虑用户可能的项目需求。用户提到了与硬件通信的MQTT和前端小程序的WebSocket，这可能意味着他们需要处理实时数据，可能会有较高的并发连接数，尤其是在硬件设备较多或前端用户量大的情况下。此外，项目的复杂性和团队对技术的熟悉程度也是影响因素。 如果用户的项目需要处理高并发，或者预计会有大量的实时消息传输，Netty可能是更好的选择，因为它的异步非阻塞模型能够更高效地处理大量连接。此外，Netty提供了更多的自定义选项，适合需要精细控制网络层行为的场景。 然而，如果项目团队已经熟悉Spring Boot，并且项目规模不是特别大，或者并发需求在Spring WebSocket的能力范围内，使用ServerEndpointExporter会更简单快捷，减少开发和学习成本。Spring的集成度更高，可以方便地与Spring Security、数据存储等其他组件协同工作。 另外，还需要考虑是否需要与现有的Spring生态系统集成。如果项目已经使用了Spring Cloud、Spring Security等，继续使用ServerEndpointExporter可能更有利于保持技术栈的一致性，简化配置和管理。 同时，性能也是一个关键因素。虽然Netty在性能上通常优于基于Servlet容器的WebSocket实现，但对于中小型项目来说，这种差异可能并不明显，只有在高并发场景下才会显著。用户需要根据预期的负载来做出选择。 此外，维护和社区支持也是需要考虑的。Netty有一个活跃的社区和广泛的用户基础，但需要更多的底层编码。而Spring的解决方案则有官方支持和更完整的文档，适合追求开发效率和维护便利性的团队。 最后，用户可能需要权衡开发效率与性能需求。如果时间紧迫，且项目规模不大，ServerEndpointExporter是更优的选择。如果项目需要处理极高的并发或复杂的网络协议，Netty则更为合适。 总结来说，回答用户时需要明确两者的优缺点，并结合用户的具体项目需求，如并发量、团队技术栈、开发周期等因素，给出建议。同时，可能需要提供一些示例或配置说明，帮助用户更好地理解如何选择。在</think>实现WebSocket服务时，选择**Netty**还是**ServerEndpointExporter**（基于Spring WebSocket）取决于项目的具体需求和场景。以下是两者的对比和适用场景分析： --- ### **1. `Netty` 实现 WebSocket** #### **特点** - **高性能**：基于异步非阻塞模型（NIO），适合高并发、低延迟场景（如万级以上的连接）。 - **灵活控制**：可直接操作底层网络层，支持自定义协议、心跳检测、流量控制等高级功能。 - **轻量级**：不依赖Servlet容器（如Tomcat），独立运行或嵌入到任何Java应用中。 #### **适用场景** - 需要处理**海量连接**（如物联网设备、实时游戏、直播等）。 - 需要**深度定制网络层逻辑**（如自定义协议、复杂心跳机制）。 - 项目已基于Netty构建（如同时使用Netty处理其他协议）。 #### **示例代码** ```java // 简化版 Netty WebSocket 服务端 public class WebSocketServer { public static void main(String[] args) { EventLoopGroup bossGroup = new NioEventLoopGroup(); EventLoopGroup workerGroup = new NioEventLoopGroup(); try { ServerBootstrap bootstrap = new ServerBootstrap(); bootstrap.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .childHandler(new ChannelInitializer<SocketChannel>() { @Override protected void initChannel(SocketChannel ch) { ch.pipeline() .addLast(new HttpServerCodec()) .addLast(new HttpObjectAggregator(65536)) .addLast(new WebSocketServerProtocolHandler("/ws")) .addLast(new SimpleChannelInboundHandler<TextWebSocketFrame>() { @Override protected void channelRead0(ChannelHandlerContext ctx, TextWebSocketFrame msg) { // 处理消息 ctx.writeAndFlush(new TextWebSocketFrame("Response: " + msg.text())); } }); } }); ChannelFuture future = bootstrap.bind(8080).sync(); future.channel().closeFuture().sync(); } finally { bossGroup.shutdownGracefully(); workerGroup.shutdownGracefully(); } } } ``` --- ### **2. `ServerEndpointExporter`（Spring WebSocket）** #### **特点** - **简单易用**：通过注解（`@ServerEndpoint`）快速定义WebSocket端点，与Spring Boot无缝集成。 - **依赖Servlet容器**：基于Servlet API实现，运行在Tomcat、Jetty等容器中。 - **功能有限**：适合中小规模并发（如千级连接），默认性能低于Netty，但可通过配置优化。 #### **适用场景** - 项目已使用**Spring Boot**，追求快速开发。 - 并发量适中（如企业内部系统、小型实时应用）。 - 需要与Spring生态整合（如Spring Security鉴权、消息广播）。 #### **示例代码** ```java // 1. 启用WebSocket支持 @Configuration @EnableWebSocket public class WebSocketConfig implements WebSocketConfigurer { @Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(myHandler(), "/ws").setAllowedOrigins("*"); } @Bean public WebSocketHandler myHandler() { return new MyWebSocketHandler(); } } // 2. 自定义处理器 public class MyWebSocketHandler extends TextWebSocketHandler { @Override public void handleTextMessage(WebSocketSession session, TextMessage message) { session.sendMessage(new TextMessage("Response: " + message.getPayload())); } } ``` --- ### **3. 对比与选型建议** | **维度** | **Netty** | **Spring WebSocket** | |---|------------------------------------|----------------------------------------| | **性能** | 高（异步非阻塞，适合高并发） | 中（依赖Servlet容器，线程模型受限） | | **开发效率** | 低（需手动处理协议细节） | 高（注解驱动，集成Spring生态） | | **灵活性** | 高（可深度定制网络层） | 低（受限于Servlet API） | | **适用场景** | 物联网、金融实时交易、游戏 | 企业内部系统、中小型实时应用 | | **学习成本** | 较高（需理解Netty核心API） | 低（Spring开发者快速上手） | #### **选型建议** 1. **高并发、高性能场景**（如万级连接以上）：选**Netty**。 2. **快速开发、中小规模场景**：选**Spring WebSocket**（`ServerEndpointExporter`）。 3. **混合架构**：若项目中既有高并发需求又有Spring生态整合需求，可组合使用（如Netty处理WebSocket，Spring Boot处理业务逻辑）。 --- ### **4. 性能优化技巧** #### **Netty 优化** - 使用`Epoll`（Linux）或`KQueue`（Mac）替代NIO，减少线程切换开销。 - 配置合理的`EventLoopGroup`线程数（通常为CPU核心数 * 2）。 - 启用零拷贝（`ByteBuf`复用）减少内存分配。 #### **Spring WebSocket 优化** - 配置Tomcat线程池（`server.tomcat.max-threads`）。 - 使用`STOMP over WebSocket`进行消息分片和流量控制。 - 结合Redis实现分布式Session广播（如`@EnableRedisWebSocketMessageBroker`）。 --- ### **总结** - **Netty**：适合**高性能、高定制化**场景，但需投入更多开发成本。 - **Spring WebSocket**：适合**快速开发、中小规模**项目，与Spring生态无缝整合。 根据项目规模、团队技术栈和性能需求合理选择即可。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值