北航2026软件工程作业 - I.3 结课总结

项目	内容
这个作业属于哪个课程	课程社区首页
这个作业的要求在哪里	作业要求
我在这个课程的目标是	系统学习“敏捷开发”这一软件工程范式，提高自己系统、规范化开展软件工程开发，并在其中进行团队合作的能力
这个作业在哪个具体方面帮助我实现目标	回顾课程进行过程中的开发与学习历程，总结课程中收获的经验与教训

以前提问题的博客见北航2026软件工程作业 - I.1 阅读与提问。

对先前提出问题的解答

在一学期的实践后，我对学期一开始提出的问题有了明确的答案，没有尚不明白的问题。

提出创新一定要“避免过度描述复杂的技术”吗？

对于这个问题，我的答案与我先前提问题时，对答案的倾向是一致的：这要取决于你的听众是谁。

如果你的听众是评委/投资人，那显然是不能过分描述复杂的技术实现的。因为此类听众的注意力无外乎于创新点/核心竞争力在哪，阐述复杂的技术对此并无益处，甚至会消耗听众的耐心。即使创新点本身在技术，在提出创新时，也只需要几个核心的 takeaway message 即可，因为听众的注意力是有限的。

但如果你的听众是开发人员的话，此时你自然希望将你的技术事无巨细地描述出来，这是为了保证最后的开发结果确实符合你的预期。或者说，论文，或者标准文档的存在就是响应这种需求而生的：为特定领域的专家，详细阐述某个技术的具体实现。

“过早泛化”这个说法合理吗？

这个问题确实是存在的。

举例而言，我们在设计我们项目的图形化规则构建语言时，将组件抽象成了执行组件、值组件、运算组件、逻辑组件四类。对于我们当前的设计，这个分类是够用了，但在后续拓展的话，这一抽象不见得是最佳的方案。

在AI出现以后，“问题解决”能力还需要包括熟练解决低层次问题吗？

在一学期的开发时间后，我认为我在学期之初对于这一问题的答案倾向过于乐观了。结合我们的开发过程，我现在对此的评价是：以当前AI的发展水平，“熟练解决低层次问题”这一能力仍然重要，不过不会如AI出现之前那么高。

仍然重要的原因是：

• 现在的AI，从解决问题的角度而言，还没有发展到绝对可靠的水平。对于低层次问题，有时仍然需要开发者人工介入。
• 一个现实的例子，我们的软工项目后端是使用 Rust 开发的。在开发赶工期间，我们尝试让AI自行解决开发过程中出现的 Bug，但是效果并不理想，对于 Rust 出现了诸多生成结果不符语言特性预期的情况。
• 现在AI的可用性还没有达到社会基础设施的程度，现在下我学期之初那样的论断为时过早。

项目经理应该干预程序的具体编码实现吗 ？

对于一个负责任的产品经理而言，是要的。

“负责任”的定义是：

• 知道自己需要实现一个什么样的软件。
• 对团队使用的技术有了解。
• 与团队成员一同参与开发过程。
• 实时掌握开发进度。

项目经理是负责项目的最终交付的，项目质量显然需要其保证。从负责任的角度而言，他难免会对实际编码实现的质量进行干预，从而对具体实现进行直接干预。当然，我们假设这位项目经理有技术背景。

有了AI，软件测试还需要专人吗？

在实践过后，我的答案是：仍然需要。

开发过程中，我们发现，AI对于编写规范化的单元测试较为拿手，也确实帮助我们发现了一些 Bug。

唯涉及用户实际操作与使用的部分，现有的AI并不能完全感知到在用户端会产生不便的地方，例如字体的颜色。AI是直接提取前端代码来进行访问的，它们不会注意到这种问题。

测试是为了保证用户的使用体验。从这个角度而言，是必须需要有人充当用户的角色，对于软件进行测试。若需测试完全，这一工作量是相当可观的。因此，软件测试仍然需要专人。

新的问题

项目经理应该具有相当的技术栈吗？

结合本人在上文的论述，以及本人在本学期内担任PM的经历，我的倾向是应该。

理由是，本人在开发过程需要多次协调负责各部分开发的同学的开发进度。在不了解具体技术实现的情况下，很容易出现分工不合理等情况。

而现实看起来常常不是这样，各大企业对于项目经理的招聘要求更要求项目管理能力，而非技术能力。

学到的知识点

• 需求阶段：如何找到一个需求痛点，并提出对应的解决方案。 举例而言，我们发现了市面缺少支持线上游玩自定义卡牌规则的游戏平台，而用户希望游玩自定义卡牌规则的需求。
• 设计阶段：实践了自顶向下的设计方法。 在设计阶段中，我们主要完成了图形化规则构建语言，以及大部分前端页面的设计。从抽象到具体编码的设计，为我们的后续开发带来了便利。
• 实现阶段：团队应该如何高效协作。 对于我们这一7人的团队，协调各部分工作的沟通成本是相当大的。在实现阶段，我们通过预先约定各部分负责内容，并对于涉及多部分协作的内容编写了规范文档（如API规范），尽可能减小了协作期间的沟通成本。
• 测试阶段：实践了CI/CD与规范的单元测试流程。 我们使用CI/CD，对每一次在发布分支上的 Commit 进行单元测试，这一自动化方案有效地降低了测试阶段所需的人工测试时间。
• 发布阶段：这部分学到的，仍然是CI/CD有关的内容。我们基于活跃分支的最新提交，使用CI/CD自动部署到我们的服务器上，节省了相当多的人力。
• 维护阶段：感受到了日志系统的重要性。我们的项目事实上只对运行时的 Bug 进行了日志记录。在课程后期，需要统计发布后用户活跃情况时，由于我们未实现这一方面的日志，我们只得通过服务器访问情况来进行统计，这为我们带来了不便。

个人心得

个人项目

本门课程的个人项目，看起来只有前两次个人作业，以及课上的实验课。

对于个人作业而言：

• “阅读与提问”部分，我发现其中对于软件工程，以及项目管理的通用方法论，在十年后的今天仍有一定的参考价值，值得借鉴。不过随着时代的发展，十年后的今天，随着AI的出现，书中有相当一部分问题的前提假设发生了变化，我们需要对此辩证看待。比如说，我在上文提到的“在AI出现以后，‘问题解决’能力还需要包括熟练解决低层次问题吗？”这个问题，就是在AI改变了编程范式这个新前提下引起的。
• “软件案例分析”部分，其一是，对于任何软件，尤其是对于自己开发的软件，都要假设他有Bug；其二是，在案例分析期间，我对于市场现状这些的分析均有涉及，这位我们后续考虑项目选题时积累了经验。

对于课上实验课而言，心得就相当有限了，因为实验课的主要目的是练手：

• 项目有关文档，是需要注意术语一致性等规范问题的。
• 比起文档的纯文字而言，UML一类的图形化规范建模语言，确能更好地帮助团队确定架构设计。
• CI/CD 是相当有用的自动化工具，无论是对于迭代后的回归测试，还是对于项目更新后的自动部署而言。

结对编程

主要是体验了一下一人负责具体编码实现，一人负责确定开发方向的这种开发范式。

个人认为，这种范式适合满足以下条件的开发情景：

• 有一位编码能力足够强的开发者，且其希望全身心投入开发工作，对开发以外的项目工作不感兴趣
• 有另一位专职负责项目管理的管理者，负责确定开发方向，并负责处理开发以外的项目管理工作

在两人的情况下，这一开发范式确能提高整体开发效率，且不会引入过多的沟通成本。

团队项目

我作为PM，在本学期内收获了以下心得：

• 对于开发阶段，PM的职责是负责协调好项目各部分的协作。这要求PM对各部分的开发进度，以及各部分如何进行协调都有充分的了解。因此我在上文中提到，一个负责的PM是应该具备一定的技术栈的，否则整个项目根本无从协调，只能依赖组员自行协商。
• 频繁的开会核对进度，事实上反而会给组员带来不必要的压力，并因此浪费宝贵的开发时间。我对课程期间我们各次 Scrum Meeting 的占用时间，以及各次会议期间的开发进度进行了统计，发现每次开会至少都要占用40分钟，会上组员普遍不愿意主动发言，且平均3次 Scrum Meeting，即6天才会出现明显的开发进度。于我的观察而言，如此频繁的开会事实上对我们的开发进度有负面影响。举一个类似的例子，在研究生阶段，你也不希望你的导师每两天就开一次组会吧（笑）
• 规范化开发是有必要的，尤其是在项目开发者规模较大的情况。在我们项目的开发初期，我们对此并未太作重视，仅做了简单的约定；后面随着开发进度深入，我们事实上做了更多的规范化工作，比如规定API规范等等。不这么做的话，势必引起更多的沟通成本。