对软件工程的理解

在学习软件工程之前，我对软件开发的理解更多停留在“把程序写出来”。但通过课程学习，我逐渐认识到，软件工程并不等同于编程，而是研究如何以工程化方式开发、维护和管理软件系统。早期的软件规模较小，开发主要依靠个人能力，具有明显的“作坊式”特点；随着软件进入银行、航空等复杂应用领域，规模、需求和参与人员不断增加，这种方式逐渐导致进度延期、成本超支、质量不足和维护困难等“软件危机”。因此，软件工程的产生，本质上是软件开发从个人创作走向大规模工程生产的结果。

我认为，理解软件工程最关键的一点，是认识到软件既是产品，软件开发也是工程。作为产品，软件需要真正满足用户需求，并考虑质量、成本和可维护性；作为工程，开发过程则必然受到时间、预算、人员和技术条件的限制。因此，一个程序“能够运行”并不意味着一个软件项目就是成功的。真正的软件工程要求开发者按照一定过程分阶段实施，通过计划、协作、测试和质量保证，让软件能够稳定地交付和长期维护。这也是软件开发从“单枪匹马”转向团队协作的重要原因。

我们的课程将软件工程概括为方法、过程和工具三个重要方面，我认为这三者实际上对应了软件开发中的三个基本问题：应该怎样做、按照什么步骤做，以及用什么提高效率。方法提供分析、设计和实现软件的技术思路；过程规定需求、设计、编码、测试、维护等活动之间的组织关系；工具则通过 IDE、Git、测试框架、Docker 等手段减少重复劳动、支持团队协作。三者只有结合起来，才能把依赖个人经验的软件开发转化为相对稳定、可重复的工程活动。
软件工程的另一个核心问题是管理复杂性。大型软件之所以困难，并不只是因为代码很多，而是因为不同模块、需求、人员和版本之间存在复杂关系。因此，抽象与建模、模块化、信息隐藏、软件重用、关注点分离和分而治之等原则，本质上都在尝试把一个难以整体理解的问题拆解成可以控制的小问题。例如，高内聚、低耦合的模块设计可以减少修改的影响范围，信息隐藏则可以使开发者只关注接口而不必理解全部内部实现。

进入大模型时代后，我认为软件工程的重要性并没有因为 AI 能够生成代码而下降，反而更加突出。AI 可以辅助完成需求分析、设计、编码、测试和维护，但它也可能产生错误逻辑、虚构 API、安全漏洞以及难以维护的代码。当代码生成速度远高于人的理解速度时，“如何写代码”可能不再是主要瓶颈，“如何验证、组织和约束代码”则变得更加重要。因此，无论是传统开发还是 AI Agent、Vibe Coding，最终都仍然需要测试、版本控制、权限管理、质量门禁和可追踪机制。

因此，我现在更愿意把软件工程理解为：在不断增长的软件复杂性面前，通过方法、过程、工具和团队协作，把人的创造力转化为可靠的软件产品。

具体的技术会不断变化，从结构化方法、面向对象、敏捷开发到 DevOps 和 AI 辅助开发，但模块化、抽象、质量保证以及对复杂性的控制仍然长期存在。软件工程真正研究的，并不只是如何“写出更多代码”，而是如何让复杂的软件系统长期保持可理解、可修改、可验证和可信赖。