程序员懂业务有多重要?

程序员业务能力的重要性与转变
本文讲述了程序员懂业务的重要性。作者从华为到亚马逊再到Oracle,经历不同项目后,认识到业务比重逐渐增大。曾经更重视技术,如今观点改变,意识到专注某领域积累经验有优势,程序员应业务和技术两条腿走路,今年想提升沟通和业务理解等软实力。

程序员懂业务有多重要?印象中我从来都说,“很重要”这句没有营养的废话。在许多项目中,业务才是真正驱使价值兑现(冠冕堂皇的说法,基本上意思就是“赚钱”)的法宝,而技术实际上有诸多选择,选择某一项并无太大区别。可是,老实说,下意识地,在技术和业务难以两全其美的时候,我还是倾向于选择那些从技术角度更有趣,但是业务上显得没“那么”重要的项目。我不讳认这一点,但是随着这些年的经验积累,或者说经历的项目的洗礼,业务的分量已经越来越大了。

在华为的时候,我做过一些杂七杂八的项目,其中最大的一个项目是一个大型的电信门户网站,由于我参与的是基线版本的研发,定制业务少,变态需求少,扩展性、性能、可维护性这些技术层面的因素考虑更多,因而总体来看,还可以说是一个技术比重明显大过业务的项目。

来到亚马逊,换过几个 team,第一个呆的时间比较长的 team 是 Demand Forecasting(销量预测),由于团队比较成熟,组织结构无论是人员上还是代码上,解耦都做得还可以,因而我更关心的是数据的 ETL 过程、schema、版本、可视化等等这些通用而并不耦合业务逻辑的东西。我们当然有业务方面的需求,但是这个 team 的核心还是在数据上面,大量的机器学习内容,不太可能内建太多的业务逻辑,主要影响销量预测还是数据本身。但是这个团队中,我接触了不少领域知识,这是一个比较大的变化,而这部分和预测算法,以及机器学习相关的领域知识,不同于某些典型的纯业务范畴的领域知识(比如说许多医疗领域、金融领域等等),可以说是技术和业务之间的灰色地带——既有技术的部分,也有业务的部分。

接着是 Contribution Profit 这个组,计算成本和盈利。从架构和系统上和大数据更深入地打交道,却基本上没有了机器学习的内容。主要原因在于,成本和盈利情况的计算,并不,或者说基本上不需要机器学习的技术,主要还是一些复杂的统计量化的方法,包括一大堆逻辑纷繁的公式。所以从业务和技术的角度上看,每天既要从系统上和元数据角度去解决那些大数据计算存储方面的问题,又要深挖业务逻辑,尝试去理解一些数值的缘由。加上我们的工具不足够出色,许多本来应该由数据分析师(Data Analyst)来做的工作,被迫转嫁到了程序员工程师的头上。这个角度看,业务逻辑的比重已经非常大了。当时我们组的同事也可以大致上分成两部分,一部分擅长业务,一部分擅长技术。

现在来到 Oracle,在 Storekeeper 组每天的工作包含了云设备(包括 instance 等等)管理,我最初的理解是,应该说工程师主要的贡献应该是提供不同种类的工具,让 Data Center 的技术人员去使用它们来管理。但是,和上面一条的情况类似,工具不足够好用,加之我们算是一个相对比较年轻的团队,还有很多相对混乱的地方,有大量的业务问题需要工程师介入以后才能解决。比方说某些数据的修改,由于工具的缺乏,这些现场的技术人员只能给工程师开 ticket,然后由工程师去更新数据。毫无疑问,这里存在大量的业务逻辑需要厘清,每当新需求分析的时候,通常比技术层面难度更高的是以沟通和梳理业务为主的部分,去和许许多多不同的用户聊,去现场了解情况,去和不同的 team 谈,从而逐步理清思路,了解问题,给出可行的解决方案。我觉得这些事情在一个足够成熟的团队中,是很难遇到的,即是机遇,亦是挑战,很难一刀切谈好坏。

老实说,曾经业务的东西从打心眼里是远不如技术受到我的重视的,再加上我换了那么多领域,我一直觉得只有技术的东西才是持久的,业务的东西却一直在变。但是这样的观点也在慢慢改变。一个是我留意到,有一些同事能够专注于某一领域(比如说 billing 系统,做了几年,换了几个团队,甚至公司,却一直研究账单系统;再比如和我现在打交道的一位 TPM,在亚马逊、微软干过,现在来到 Oracle,都在云计算的最底层处理涉及硬件和设备的需求,考虑到本来云计算就没多少年,在这一块领域,她可以说是非常罕见的老江湖了),这一旦在进一步职业选择的时候,如果选择到了相同的领域,无疑是在经验上有很大优势的。这也促使我在 这一次求职 的时候所说,希望在几年后的三十五岁的时候,明确一个大致上希望精进的方向。也许未来的新业务难以预测(比如哪怕就在五年前有谁能知道区块链居然能火成这样?),但是有一个大致熟知的领域为根基去伸展枝叶,会比一直没有清晰的门路强。当然,我不觉得之前的各个业务领域的积累是浪费,毕竟,眼界不只取决于深度,还取决于广度。

程序员工程师,毕竟主要做的是工程,不是研究。和生活更紧密,和实际问题更贴近,因而有大量的非技术问题和知识需要把握。入职以后,今年给自己的一个小目标,就是想提高包括沟通和业务理解在内的软实力,一定程度上也是我的短板。业务本身兴许未来能用到,更多的可能是用不到,但是对于业务和技术两条腿走路的多数程序员来说,瘸了哪一条都显得受限许多。

By 四火,From : https://www.raychase.net/4866

 -End- 

640?wx_fmt=jpeg

长按2秒,识别二维码,关注我

 

欢迎加入我的星球


相关文章推荐:

<think>嗯,用户的问题很有意思,ta注意到了黑马程序员说Servlet项目过时,但同时又知道Spring底层其实还是基于Servlet的,这看起来有点矛盾。用户应该是个有经验的Java开发者,至少对Web开发有基本了解,不然不会注意到这种框架底层实现的问题。 从用户引用的内容来看,ta可能正在学习Java Web开发,遇到了使用传统Servlet/JDBC/JSP技术的课程项目,但发现业界已经转向Spring框架。ta的困惑点在于:既然Spring底层还是Servlet,为什么说Servlet项目过时了? 需要区分清楚“技术过时”和“设计模式过时”的区别。Servlet作为规范当然没有过时,但直接裸写Servlet的开发方式确实已经不符合现代工程实践了。这就像虽然所有程序最终都转化成机器码执行,但我们不会因此就说汇编语言没过时。 用户引用的资料[1]提到老师教的购物系统课设使用“特别老的”Servlet+JDBC方式,这个“老”主要体现在三个方面:一是缺乏分层设计,业务逻辑和数据库操作混在一起;二是没有利用现代框架的声明式编程;三是前端还在用JSP这种服务端渲染技术。这些都是工程实践层面的落后。 特别要注意引用[3]强调的Servlet规范本质——它只是定义了处理网络请求的基本生命周期方法(init/service/destroy)。Spring的DispatcherServlet虽然也叫Servlet,但它通过精妙的设计把这个基础能力扩展成了完整的MVC框架,比如用HandlerMapping解耦请求路由,用@Controller注解代替硬编码的service()方法。 用户可能没意识到的是,现代框架的价值不在于取代底层,而在于提供更高抽象。就像开车不需要了解内燃机原理,用Spring的开发者也无需关心Servlet线程模型。但高手还是需要底层,所以引用[2]详细说明的Servlet生命周期知识依然重要。 最后要提醒的是,在微服务场景下(引用[4]),Servlet的应用方式也进化了。比如Spring Boot把Servlet容器嵌入应用,而Servlet本身更作为传输层实现,业务逻辑完全由框架接管。这种架构下确实不需要开发者直接操作Servlet API了。</think>### 为什么黑马程序员称Servlet项目“过时”,而Spring Web层仍基于Servlet? #### 1. **“过时”的本质是开发模式,而非技术本身** - **原始Servlet开发的痛点** 如引用[1]所述,传统Servlet项目常存在以下问题: - **重复性代码**:每个Servlet需手动实现`service()`方法处理请求(引用[3]),导致大量模板代码(如请求参数解析、响应格式设置)。 - **低效的数据库操作**:直接使用`JDBC`而未封装(如引用[1]),需手动管理连接池、事务,易出错且维护难。 - **视图耦合**:JSP前端与后端逻辑强耦合(如引用[1]),难以实现前后端分离。 ```java // 传统Servlet示例:需手动处理请求参数和响应 protected void doGet(HttpServletRequest req, HttpServletResponse resp) { String param = req.getParameter("id"); // 手动解析参数 // 业务逻辑与JDBC操作混杂... resp.setContentType("text/html"); PrintWriter out = resp.getWriter(); // 手动设置响应 out.print("<html><body>Result</body></html>"); } ``` *这种开发模式效率低、扩展性差,被业界视为“过时”实践[^1]。* - **Spring的优化本质** Spring并未淘汰Servlet,而是通过**抽象层**解决上述问题: - `DispatcherServlet`作为唯一入口(引用[4]),统一处理请求分发。 - 注解(如`@GetMapping`)自动绑定参数,无需手动解析。 - 依赖注入解耦业务逻辑与数据库操作(如Spring Data JPA封装JDBC)。 #### 2. **Spring如何基于Servlet实现现代化开发** | **传统Servlet痛点** | **Spring的解决方案** | **技术实现** | |---------------------------|-----------------------------------|---------------------------------------| | 手动处理请求/响应 | 声明式参数绑定 | `@RequestParam`, `@RequestBody`注解 | | 业务逻辑与Servlet耦合 | 控制器分层(Controller层) | `@Controller`分离业务与HTTP处理[^4] | | JDBC操作繁琐 | 数据库抽象层(如JPA) | Spring Data JPA自动管理事务和连接 | | JSP前后端耦合 | 前后端分离(RESTful API +前端框架)| `@RestController`返回JSON数据[^4] | - **关键设计**:`DispatcherServlet`通过**策略接口**(如`HandlerMapping`、`ViewResolver`)扩展Servlet功能,开发者只需关注业务逻辑[^4]。 #### 3. **为何Servlet技术未过时,但项目模式已过时** - **Servlet仍是基石**: Spring Boot内嵌Tomcat/Jetty(Servlet容器),所有请求仍通过Servlet API处理(引用[2][3])。 - **过时的是开发范式**: 直接使用Servlet API开发大型项目,如同用汇编语言写应用——底层可行,但效率低下。现代开发需借助框架提升生产力。 #### 4. **现代架构中的Servlet定位** - **微服务场景**: 即使使用Spring Cloud,服务仍运行在Servlet容器中。但开发者通过`WebFlux`(非阻塞模型)进一步优化性能,Servlet作为**可选项**存在。 - **核心价值保留**: Servlet的生命周期(`init()`→`service()`→`destroy()`)仍是Web应用的基础(引用[2][3]),只是框架隐藏了细节。 ### 总结 黑马程序员批评的“过时Servlet项目”,特指**未使用现代工程实践**(分层架构、声明式编程)的传统开发模式。Spring通过封装Servlet API,解决了原始开发的痛点,但底层仍依赖Servlet规范。**技术栈的演进本质是抽象层次的提升,而非底层技术的替代**。掌握Servlet原理(如生命周期[^2][^3])仍是深入理解Spring的关键。 --- ### 相关问题 1. **Servlet的生命周期方法(如`init()`, `service()`)在Spring MVC中如何被调用?** 2. **Spring Boot如何实现对Servlet容器的自动配置?** 3. **除了Spring,还有哪些框架基于Servlet构建?它们的设计差异是什么?**
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值