从学生时代到工业软件开发，这两年让我重新理解了"软件工程"这四个字。

开篇：我曾经对软件工程的误解

在学校里，我一直觉得软件工程就是把需求转化成代码。

老师布置一个题目，分析需求，设计结构，编写代码，测试运行，然后提交。

那时候我认为，一个优秀的软件工程师应该具备：

• 扎实的代码能力

• 熟练掌握各种技术栈

• 能快速实现需求

• 能解决复杂的技术问题

但真正进入工业现场之后，我才发现，代码只是软件工程最容易被看见的一部分。

真正困难的事情，是让软件在现实世界中长期、可靠地解决问题。

工业现场里的软件，不只是运行在电脑里的程序，它连接着设备、生产流程、人员操作以及实际业务。

一次错误，可能影响的不是一个按钮或者一个页面，而是一整条生产线。

一、写代码只是创造功能，而工程是解决问题

在学校里的程序，通常是这样的：

只要输入正确，程序输出正确答案，就算完成。

但是工业软件完全不同。

实际面对的是：

人的需求、业务流程、设备限制、生产节拍、维护成本、长期运行、软件实现

代码只是最后的一环。

例如，一个简单的"视觉检测功能"。

在学习阶段，我们可能关注：

• 如何读取图片

• 如何调用算法

• 如何得到检测结果

但是在工业现场，需要考虑：

• 产品为什么需要检测？

• 检测结果影响什么？

• 误判和漏判哪个更严重？

• 数据是否需要追溯？

• 操作人员是否容易理解？

• 设备出现异常后如何处理？

同样一个需求，在不同环境下，背后的问题完全不同。

二、真正困难的是理解需求，而不是实现需求

刚开始接触项目时，我也经常习惯于拿到需求后直接思考：

“这个功能应该怎么写？”

但后来发现，很多时候，客户描述的是现象，而不是需求。

例如：

“我要检测产品有没有缺陷。”

这句话看起来很明确，但实际上还有很多问题：

• 什么算缺陷？

• 缺陷需要分类吗？

• 检测结果需要保存多久？

• 是否需要生成报表？

• 谁会查看结果？

• 出错后是否需要人工确认？

如果没有理解这些问题，即使代码写得再漂亮，也可能无法解决真正的问题。

工程开发中，最重要的能力之一，是把模糊的需求转换成明确的问题。

三、软件工程师需要学会和不同的人沟通

学校里的开发环境相对单纯。

你的同学、老师通常理解技术语言。

但工业现场不是这样。

你的沟通对象可能是：

• 操作员

• 工艺工程师

• 机械工程师

• 电气工程师

• 项目负责人

他们关注的问题通常不是：

“你的代码结构是否优雅？”

而是：

“这个设备能不能正常生产？”

“出了问题之后怎么办？”

“操作起来是否简单？”

程序员眼里的一个按钮：

在用户眼里可能代表：

“开始生产”。

背后可能连接：

• 软件状态

• PLC通讯

• 运动控制

• 相机触发

• 数据处理

• 结果保存

所以工程师不仅要会写代码，也需要理解代码之外的系统。

四、软件不是孤立存在的

在互联网软件中，很多时候软件就是核心。

但工业软件通常只是整个系统中的一部分。

它连接着：人员、软件、电脑、PLC、运动控制、传感器、机械结构、实际产品。

任何一个环节的问题，最后都可能表现为：

“软件有问题”。

因此，工业软件开发者往往需要了解很多跨领域知识：

• 电气控制

• 机械结构

• 光学成像

• 通讯协议

• 生产流程

不一定需要成为每个领域的专家，但必须理解上下游。

因为软件最终服务的不是代码，而是真实世界里的系统。

五、工程师的价值不是写更多代码，而是减少复杂度

刚开始工作的时候，遇到问题时，我习惯思考：

“我要怎么写代码解决这个问题？”

但随着项目经验增加，我开始思考：

“能不能让这个问题根本不会发生？”

这其实是工程思维的一种变化。

例如：

以前可能会想：

“增加一个错误提示。”

后来会想：

“为什么用户会进入这个错误状态？”

以前可能会想：

“增加一个恢复按钮。”

后来会想：

“为什么系统不能自动恢复？”

优秀的工程设计，不只是解决已经发生的问题，而是提前消除可能出现的问题。

六、两年之后，我重新理解软件工程

从学校到工业现场这几年，我写过很多代码，也修改过很多代码。

以前我认为：

软件工程就是写出正确的软件。

现在我认为：

软件工程是在现实约束下，创造一个长期可靠、能够解决实际问题的系统。

代码能力决定一个工程师能够走多快。

但工程能力决定一个工程师能够走多远。

真正优秀的软件，并不是让所有人注意到它有多复杂，而是在没人关注的时候，依然稳定地完成自己的工作。

这也是我进入工业现场之后，对"软件工程"最大的理解变化。