当前位置：首页 > news >正文

现代软件工程课程个人博客作业

news 2025/10/11 9:18:41

现代软件工程课程个人博客作业

围绕《构建之法》这本书提出五个问题，针对高度工业化的软件工程背景书籍，我围绕过去以及当前翻阅这本书时的很多信息做了思考，结合AI工具的共同分析最终用产出了我认为比较值得思考的几个问题：

问题一

在校内的开发课程或个人项目中，如何有效地设置“假的上线问题”——比如权限配置错误、限流机制失效等——让学生能够真实体验软件发布后的维护与问题修复过程？

书中第15章提到类似：软件发布不仅仅意味着功能完成，而是系统能够稳定运行、能够被监控、能够响应外界变化的状态。发布之后的维护，是检验一个团队是否真正具备工程化能力的重要阶段。此类问题：即使我们在课程中已经学习了发布、反馈与维护的概念，但在实际教学环境中，我们往往无法经历那些只有真实上线环境中才会出现的问题。

所在的课程中，确实安排了“上线与维护”的环节，比如让我们团队协作进行编码对功能更新设置UI或者多平台兼容测试等，我们几乎不会遇到诸如：

权限系统配置错误（角色误判、未授权访问）
限流机制触发异常（高并发情况下的拒绝服务）
版本兼容问题（更新后接口变动导致旧客户端出错）
日志、监控系统缺陷（无法及时发现问题）

这些“生产级”问题在校园环境几乎不可能自然出现。
因此，我在阅读第 15 章时产生了疑问：如果没有真实的线上复杂性，我们要如何“模拟”出这些问题？

在学校中，我们的课程项目大多以“功能实现”作为考核重点。即便安排了部署环节，也很少涉及维护性和可用性层面的考察。所以，我和同学往往只做到“能跑”，但从没经历过“出了问题该怎么修”的阶段。我也尝试过在自己的小项目里部署服务，但由于访问量太小、权限模型简单，几乎不会产生类似“限流”或“并发”问题。

书中提到的维护阶段包含反馈收集、版本迭代、监控与修复等步骤，这些对工程师的成长至关重要。
但在教育环境里，这些“真实问题”不会自然发生。
那么：

教师是否可以设计虚拟的上线问题，让学生通过“故障排查”来体验真实维护流程？
在有限的课堂资源下，这种“模拟上线问题”的训练是否能有效地培养学生的工程思维？
又或者，只有在真实商业项目中经历“生产事故”，才能真正理解书中所说的“稳定、发布与维护”的意义？

问题二

在进行需求分析时，如果自己的研究方向或学术成果暂时没有明显的商业或应用场景，该如何从个人的能力与研究内容中“反向”挖掘可实践的需求？

书中第8章提到类似“需求分析的关键，是从客户或用户的角度出发，理解他们真正的需求，而不是从开发者的角度去‘替他们想’。好的需求分析应该能将模糊的想法逐步转化为明确的规格、功能与约束，最终成为可实现的目标。”的想法。

这一章主要讨论了从客户需求到团队分析、从架构设计到测试再到最终验收的完整过程。但我在阅读时感到一个困惑：作为一个研究生，我并没有真正意义上的“客户”。我所研究的课题虽然在理论上具有一定意义，但当我尝试用《构建之法》的视角来做需求分析时，会发现：

没有明确的用户群体；
没有现实场景驱动；
很难分析“市场需求”或“痛点”；
也不容易发现自己研究内容相较于已有解决方案的“优势”。

这让我意识到——学术研究和工程项目在“需求”上似乎存在一条鸿沟：
学术研究强调问题的深度与理论价值；
工程需求则强调现实可用性与场景匹配度。

一些高校（如 MIT、清华）都有“科研成果转化”课程，鼓励学生用工程化视角重新定义自己研究的应用边界。
在知乎上，很多研究生也提到“科研成果难以落地”的问题，原因往往不是技术不好，而是“没找到谁真正需要它”。

这些资料让我重新思考：也许需求分析不仅仅是“听客户说什么”，还包括“自己作为潜在开发者，如何发现被忽略的场景或细分需求”。

我在研究中主要做理论建模与算法设计。从工程视角看，这些内容似乎距离“产品化”很远，但在我复盘过往项目时发现，有些小工具、数据可视化模块、自动化分析脚本，其实已经具备某种潜在的实用价值。只是我们没有像做需求分析那样系统性地思考：它到底能帮谁？帮到什么程度？是不是值得优化或重构？

当我尝试写需求文档时，最大的困难不是写功能列表，而是回答——
“这是谁的需求？”
“这个需求在现实中真的存在吗？”

书中提到的需求分析流程是以“客户—团队—开发”三层结构为前提的。
但对于一个研究生或个人开发者来说，没有真正的外部客户，也没有团队之间的职责分工。
在这种情况下，需求分析似乎无法套用传统的软件工程框架。

因此，我的问题是：

对于学术或研究型项目，是否可以通过“自我需求建模”的方式来完成需求分析？
是否有方法帮助我们从已有的知识或研究方向中**“反向挖掘需求”**，从而把理论研究转化为可工程化的原型？
“获取需求”这件事，是否可以理解为一种“创造需求”的过程？也就是说，研究者能否通过对领域的洞察，发现他人尚未意识到但客观存在的需求？

问题三

在软件工程中，面对已经高度成熟的开源框架（如 Qt、Django、TensorFlow 等），创新是否仍然可以体现在编码范式、协作流程或开发模式上？
换句话说，是否存在一种“对标优秀框架的范式化开发流程”，让后来的开源工具类项目能在工程层面持续创新、提升效率与可维护性？

第 16 章 IT行业的创新内容上我看到了很多创新角度的发现，同时我在学习或使用开源框架时会有一些想法：

当我学习像 Qt、Django 这样的框架时，我注意到它们本身的开发过程就是软件工程的典范。
例如：

Qt 项目的模块化架构、跨平台构建系统、信号槽机制；
Django 的开源协作流程、代码提交规范、自动化测试体系、文档同步更新机制。

这些大型开源项目的开发过程本身就代表了一种成熟的工程实践。
同时它们的 Git 记录（例如 Django 的 GitHub 提交历史）也体现出一种可追溯、可演进的工程创新路径。

如果创新不仅限于“造一个新框架”，那是否存在一种范式化的软件工程创新方法论？
例如：

针对开源工具类项目，是否有一套“最优协作流程”的模板？
是否有关于“如何组织开源项目架构与提交规范”的统一工程范式？
这些流程是否也能像框架本身一样被“重用”？

JetBrains 和微软的工程博客中提到，他们的创新之一正是工程流程的自动化与可重现性，例如 CI/CD、代码质量门控（Quality Gate）等。这些内容让我意识到，创新并不一定是技术层面的革新，有时是把流程标准化、自动化、模块化本身——这也是工程的创新。

我自己在学习框架开发（尤其是 Django）时，常常被它的目录结构、命名规范和自动化工具所启发。这些设计让一个复杂项目能在多人协作下保持统一风格，也让后续开发者能快速上手。

但如果我尝试自己做一个“工具类项目”，即便我模仿 Django 的架构，也很难有系统的方法论去保证：

提交规范一致；
模块分层合理；
架构具备长期扩展性。

这让我思考，是否可以像“设计模式”那样，总结出一套“开源项目开发模式（Open Source Engineering Patterns）”？比如：

分支模型（Branching Pattern）；
Issue-PR 流程模式；
测试与文档同步策略；
社区参与激励模式。

在如今框架林立、生态完善的情况下，软件开发者似乎已经不太可能再在框架本身上“重新发明轮子”。那是否可以理解为：

现代软件工程的创新更多地体现在范式层面的优化？
“创新”可以是一种系统性的“效率再设计”而不是“功能再发明”？
未来的软件工程教育，是否应该更多地教授这种“工程流程创新”的能力，而不仅仅是“技术创新”？

问题四

我注意到当前很多国内软件（尤其是视频类应用）在设计上似乎已经超出了“服务用户”的范畴，而更多地转向“引导用户”或“占用用户”。比如：

启动页广告（强制几秒倒计时）
播放前广告、暂停广告、悬浮广告、轮播推广栏
非会员无法快进、只能看低画质
UI 上刻意复杂化、诱导点击“特权”或“升级”的入口

我的问题是：
在现代软件工程的“设计”阶段，这种为了商业化而牺牲用户体验的设计，是否已经背离了以用户为中心的软件工程思想？或者说，在软件工程层面，我们是否需要建立“反过度商业化设计”的设计原则或伦理规范？

我在阅读本章时，作者强调“优秀设计的核心在于让用户感到自然与高效”。但我观察到很多现实软件恰恰相反：

设计师为了商业KPI而牺牲可用性；
开发团队被迫实现越来越多与“功能目标”无关的广告逻辑；
用户体验从“以人为本”变成“以留存率、点击率为本”。

这让我困惑：
软件工程在教学与行业实践中是否已经默许了这种商业导向？
如果我们仍在强调“面向用户的设计”，那“用户”究竟是付费的客户还是被设计的对象？

国外例如 Apple、Notion 等软件仍坚持极简设计原则，但国内 App 越来越“流量化”。
从工程角度，广告模块、会员控制逻辑已成为架构设计的一部分，这似乎说明“商业化设计”已被视为系统性需求。

我的困惑是：
在软件工程教育中，我们是否应该重新定义“用户价值”与“商业价值”的平衡点？
尤其在课程或项目实践中，是否有必要讨论“伦理化设计”的范畴？

问题五

随着 AI Agent 的智能化和自动化程度不断提升，软件测试领域是否也会像过去“脚本自动化取代人工点击”那样，再次经历一次从“人主导”到“AI主导”的变革？
换句话说，AI 是否会成为未来的主要“测试工程师”？甚至，当 AI Agent 具备理解业务逻辑的能力时，它会不会像在做单元测试一样，对代码逻辑本身进行“随机探索性测试”？

提出这个问题的原因：
阅读本章时，我发现作者强调“测试的艺术在于人的思考与经验”，这让我想到当前AI在代码层的演进。
例如：