[I.3] 个人作业：结课总结

项目	内容
这个作业属于哪个课程	课程链接
这个作业的要求在哪里	作业要求
我在这个课程的目标是	提升代码水平，学会团队协作，通过敏捷开发开发出预期内的应用程序
这个作业在哪个具体方面帮助我实现目标	学期末总结课程收获，回顾整个过程的所学所思，进行反思总结，梳理自己的成长

提问回顾

提问博客

课程的开始阶段，我仔细阅读了邹欣老师的《构建之法：现代软件工程》一书，那时的我还不了解软件工程，因此整体阅读下来会有不少的疑惑，我也在课程第一次作业中列出了其中最困惑的五个问题。经过了一学期的课程学习，在整个过程中我也参与了结对编程、团队开发等，对这些问题也有了新的理解。

---

问题一：断言的意义何在

在课程初，我对断言的意义并不了解，觉得只使用错误处理就可以了，不明白在错误处理更加直观且也能验证正确性的时候为什么还要使用断言。在课程后面的团队开发当中，我其实仍然没有使用断言，但有一次突然想起来，也试着在编写代码的时候同时写上断言，在当时我仍然没有太感受到这样做的意义，同时感觉反而会增加开发阶段的任务量。但在后续继续迭代开发的时候，我再重新审视了那些断言，有了一些新的理解。
再仔细思考后，我对断言的看法是：断言不是用来处理错误的，而是用来暴露程序员对程序状态的错误假设；错误处理不是用来证明程序正确的，而是用来应对程序运行中可能合理发生的异常情况。
我之前说，把断言用在开发阶段的正常代码中，这会给我一种“上帝编程”的感受。但我发现，当写断言的时候，开发者其实正是由于不是上帝，不知道程序正确与否，才会去进行一些假设，这便是断言。所以断言的意义在于把开发者脑中的隐含前提显式写出来，它不是因为开发人员已经知道最终结果，而是因为开发人员需要不断检验自己的设计理解是否和程序真实运行状态一致。

问题二：结对编程中，怎样才能实现两人之间的有效沟通

在本门课程之前，我从来没有接触过结对编程，但“花见小路”游戏让我第一次体验到了结对编程的整个过程。在课程开始之前，我确实对怎样实现两人的有效沟通有疑惑，也带着这样的疑惑，开始了我的结对编程，同时在这个过程中，和我的队友找到了一个适合彼此的沟通方法。
现在，我对这个问题有以下的一些理解与看法：
结对编程不是两个人去争夺代码控制权，而是两个人围绕同一个目标建立一种有规则的协作关系。结对编程不是简单分工，而是共同思考，两个人要在同一时间面对同一问题围绕同一份代码进行协作，所以在结对编程当中沟通并不是额外的负担，而是这种模式本身的核心。结对编程也并不会自动产生良好沟通，它需要规则，“驾驶员”可以说明自己现在为什么这样写，而不是沉默地一味敲代码，“领航员”也需要说明自己担心某个地方具体会出现怎么样的问题。
同时，角色互换不是为了推翻对方，而是为了共享理解。角色互换之后，修改应该是让代码更符合需求、更清晰、更容易测试或维护，这是结对编程的价值之一。
总结下来，我认为结对编程中的有效沟通至少需要做到三点：第一，双方要围绕需求、测试和代码质量讨论，而不是围绕个人习惯和能力争论；第二，双方都要表达自己的思路和疑问，使代码背后的设计假设能够被共同理解；第三，当出现分歧时，应尽量通过测试、实验或共同约定的代码标准来判断，而不是依靠某一方的权威。只有这样，结对编程才不会变成形式上的“两个人写一份代码”，而能真正发挥互相检查、互相启发和共同提高的作用。

问题三：图形化建模在如今软件设计中的实用性与意义

我现在重新审视我当初提出的这个问题，发现我这个问题提的不止是在说“要不要画UML图”，其实更多的是在讨论软件设计阶段的模型是用来提前规定实现还是用来帮助思考和沟通。
我在当初承认了图形化建模是很有价值的，我提出的怀疑是，在代码还没成型之前，其是否拥有真正的价值。经过我的思考和总结，我认为首先需要明确的是：并不是所有项目都必须在写代码前画完整的UML图或实体关系图。对于规模较小，逻辑简单以及开发者较为熟悉的问题，强行画图可能会增加负担。
而设计阶段的图，不一定是最终实现的蓝图，而是探索设计方案的草稿。设计阶段画图的目的不是一次性画出完全正确的系统结构，而是帮助我们发现问题。图的价值不在于它正确，而是在于让不清楚的地方暴露出来。
所以，图形化建模在软件设计阶段是有意义的，它的意义不在于提前规定所有实现细节，而在于帮助开发者思考、沟通和发现问题。设计阶段的图可以是轻量的、不完整的、可修改的；实现阶段的图则可以帮助我们理清已有结构、定位问题；项目完成后的图还可以作为总结和维护资料。因此，图形化建模并不是只有在软件实现之后才有价值，而是在设计、实现和维护的不同阶段都有不同作用。关键不在于是否必须画图，而在于是否在合适的时机、以合适的粒度画出真正有助于理解和沟通的图。

问题四：AI时代下，怎样提升测试的效率

在课程结束之际，我仍然对《构建之法》里的一句话印象十分深刻，那就是“程序员写完功能的时候，我们感觉好像项目完成了80%,殊不知后面的20%往往要花费80%的时间”。我在课程初也结合面向对象程序设计课程的经历提出了怎么将AI高效利用在测试中的问题。经过了一学期的团队开发，虽然我是主要负责开发工作而不是测试工作，但我仍然需要在开发过程中尽量做一些测试来保证自己的功能不要出现太大的问题，以减少测试同学的工作量。现在重新回顾我当初提出的这个问题，我有以下见解：
AI不能替代测试人员对需求、风险和质量目标的判断，但可以在测试用例生成、边界条件发现、代码理解、缺陷定位和测试维护等环节提升效率。我认为在AI时代下，合适的测试方法为可以使用AI生成边界数据和异常数据，以帮助测试人员减少大量重复性、机械性的分析和编写工作，但同时应该牢记于心的事，AI在测试中的角色应该是助手，提出的所有意见以及设计的样例等，都需要开发者或者测试人员进行进一步的判断，AI可能能够保证高覆盖率，但高覆盖率不等于高质量测试。在需求阶段，我们可以让AI列出测试点和异常场景；在设计阶段，我们可以让AI思考模块之间的交互风险；在编码阶段，我们可以让AI辅助生成单元测试；在集成阶段，我们可以让AI分析可能的兼容问题；在维护阶段，我们可以让AI总结受影响的模块和需要回归测试的范围。

问题五：当今时代，创新到底是什么，是否又只能于前沿科技发生或者伴前沿科技发生

其实我在课程初提出的这个问题，是我一直在思考的问题，什么是创新，在阅读完《构建之法》后，这个问题更加困扰我。
现在这个问题仍然困扰我，但我可能在学期结束的时候会有一点新的体验。
创新不是简单的改变，也不一定等同于使用前沿技术；创新应当是通过新的方法、新的组合、新的体验和新的效率，解决了原本没有被很好解决的问题，并产生了实际价值。我仍然很认可在提出该问题时所抛出的观点：创新一定伴随着改变，但是改变不一定就是创新。改变不一定是创新，创新一定要产生价值，创新伴随的是带来了新的价值的变化。同时反响变好可以说明这个改变可能有价值，但不能单独证明其就是创新。我之前还提到创新是否只伴随着前沿科技才会发生，现在我想对这个问题进行回答，使用前沿技术不必然等于创新，不用前沿技术也可能产生创新。即是一个系统使用的不是最前沿技术，但通过合理的工程设计、产品设计或流程优化，改善了用户体验或行业效率，那其仍然可以算是创新。

仍然疑惑的问题

在第一部分我也写到，其实课程初的五个问题我在经历过一学期的实践过后，在现在这个阶段或多或少都有了新的理解，对于大部分的问题，现在也都有了回答，但也正如我第一部分所说，对于“创新是什么”这个问题，我可能还需要一个长期的时间去探索，我觉得这也必然是一个将会长时间伴随我的问题，这需要我在未来的科研或者开发当中继续去探索并回答。

新的问题

在结束本学期的团队开发后，我也产生了一些新的问题，主要是围绕AI方面的一些问题，在人工智能发展迅速的今天，我发现AI执行任务的效果越来越好。在团队开发的过程中，我们也使用AI帮我们完成了一些繁琐的任务。同时，我在网络上也看到各种关于vibe coding的帖子，说有人通过vibe coding可以快速开发出一个强大的软件之类的。我自己也有试过利用vibe coding来开发一些自己感兴趣的东西。
我很想使用鸦片来形容vibe coding，因为当你一个项目大量使用vibe coding的时候，这个项目的体量还比较大的时候，这个时候你就很难再脱离它。我认为这不是说“上瘾”，当然有上瘾的成分在，毕竟几分钟可以写几千行的代码，谁还愿意自己花一周去写完全一样效果的代码呢。但我认为这里面危害更大的是，当你大量使用vibe coding，你会没有精力或心情去阅读AI写的代码，而这时候，当一个项目有几千行乃至几万行的代码你都没有阅读的时候，你一定是不了解这个项目的，可以说对这个项目一无所知。而这个时候，当你的项目有什么想新增的功能或者出现了问题，你一定还是只能依靠AI，而不能自己去解决，然而你并不知道AI是否能够按你的意愿真正完成修改。因此我觉得用鸦片来形容vibe coding是很恰当的，你一旦使用了，便很难逃脱。
因此我想知道的是，在面临大型项目的时候，应该怎么去平衡AI和人工之间的关系，如果不使用AI，效率确实会比较低，但如果AI使用过头，那你会操控不了项目，项目会和你毫无关系。

阶段知识点收获

软件工程这门课并不只是讲一些抽象的“知识点”，更重要的是让我们在项目实践中理解这些知识点为什么存在。在经历了一个相对完整的团队项目之后，我逐渐意识到，软件开发并不是从编码开始，也不是在代码写完时结束。需求、设计、实现、测试、发布和维护，每一个阶段都有其独立的价值，也都会影响最终软件的质量。

需求阶段

在需求阶段，我最大的收获是认识到需求分析并不是简单地罗列功能。最开始做项目时，我们很容易用一种开发者视角去理解需求，觉得只要知道大概要实现哪些功能就可以开始写代码。但真正进入项目后会发现，很多问题如果一开始没有说清楚，后面就会反复修改。

例如，一个看似简单的登录功能，背后可能还涉及账号格式、密码规则、错误提示、权限区分、异常处理等细节。如果需求阶段只是写一句“实现用户登录”，那么到了实现和测试阶段就会出现很多理解不一致的问题。因此，需求阶段的知识点让我明白：软件工程首先要解决的不是“怎么写代码”，而是“到底要解决什么问题”。只有把用户需求转化为清晰、可验证的功能描述，后续设计和实现才有基础。

设计阶段

在设计阶段，我的一个很重要的收获是模块划分。以前我写代码时，经常是想到哪里写到哪里，只要功能能实现就认为问题不大。但在项目规模稍微变大之后，如果没有提前思考模块之间的关系，代码很容易变得混乱，后续修改也会越来越困难。

通过设计阶段的学习，我认识到设计并不是为了写一份形式化文档，而是为了提前思考系统应该由哪些部分组成，每个部分负责什么，不同部分之间如何交互。比如在团队项目中，如果没有明确前端、后端、数据库、接口之间的边界，成员之间就很容易出现重复工作或接口对不上的情况。设计阶段让我意识到，好的设计可以降低后续实现和维护的成本，也能让团队成员对项目整体结构形成共同理解。

实现阶段

在实现阶段，我最大的收获是意识到编码并不只是把逻辑写出来，还包括代码规范、版本管理和团队协作等工程习惯。过去我个人写小项目时，代码风格是否统一、提交记录是否清晰、变量命名是否规范，似乎都不是特别重要。但在团队项目中，这些细节会直接影响别人是否能读懂我的代码，也会影响后续调试和修改的效率。

在多人协作时，如果每个人都按照自己的习惯随意命名、随意组织文件，项目很快就会变得难以维护。相反，如果大家遵守统一的代码规范，并通过版本管理工具记录每一次修改，就能让协作过程更加清晰。实现阶段让我明白，软件工程中的“实现”并不是个人英雄式地把功能写完，而是在保证代码可读、可维护、可协作的前提下完成开发。

测试阶段

在测试阶段，我最大的体会是：程序能运行并不代表程序正确。以前写代码时，我常常只用几个自己想到的样例测试一下，如果结果正确，就会觉得功能基本完成了。但在课程实践中，尤其是经历测试之后，我发现很多错误并不会出现在最普通的输入中，而是隐藏在边界条件、异常输入和复杂组合情况里。

测试阶段让我认识到，测试不是开发结束后的附属工作，而是保证软件质量的重要手段。一个好的测试不仅要覆盖正常情况，还要考虑极端情况和错误情况。比如输入为空、数据越界、重复操作、非法状态等，都可能暴露代码中的问题。通过测试，我也逐渐理解了为什么软件工程中强调“质量保证”：因为很多时候，真正耗费时间的不是写出第一版代码，而是不断发现问题、定位问题和修正问题。

发布阶段

在发布阶段，我学到的一个知识点是软件交付。以前我对项目完成的理解比较简单，认为只要程序在自己的电脑上能够运行，项目就算基本完成了。但真正从软件工程角度看，软件还需要被部署、配置、打包，并且能够在目标环境中稳定运行。

在项目实践中，我发现“本地能跑”和“别人能用”之间其实有很大差距。比如环境配置、依赖版本、数据库连接、路径问题、权限问题，都可能导致程序在别人电脑上无法正常运行。因此，发布阶段让我意识到，软件开发不能只站在开发者自己的环境中考虑问题，还要考虑用户或使用者如何安装、启动和使用软件。一个项目真正完成，不只是代码写完，而是能够被稳定交付和使用。

维护阶段

在维护阶段，我最大的收获是认识到软件并不是写完就结束的。过去我完成课程作业后，往往提交之后就不会再关注它。但在真实的软件工程中，软件上线之后还会遇到需求变化、bug 修复、性能优化和功能扩展等问题。维护阶段往往持续时间更长，也更考验最初的设计和代码质量。

如果前期需求不清、设计混乱、代码可读性差，那么后期维护就会变得非常痛苦。相反，如果项目一开始就有较清晰的结构、规范的代码和必要的文档，那么后续修改就会容易很多。维护阶段让我明白，软件工程强调文档、规范、测试和设计，并不是为了增加形式上的工作量，而是为了让软件在未来仍然能够被理解、被修改、被扩展。

总结

通过这次项目实践，我对软件工程有了比单纯阅读教材更深的理解。需求阶段让我学会明确问题，设计阶段让我学会规划结构，实现阶段让我学会重视工程规范，测试阶段让我学会验证质量，发布阶段让我学会考虑交付环境，维护阶段让我学会从长期角度看待软件。以前我更关注“能不能写出来”，现在我开始意识到，一个真正的软件项目还要关注“是否满足需求、是否容易协作、是否可靠、是否能够交付、是否方便维护”。

软件工程中的很多知识点，如果只停留在概念层面，可能会觉得它们有些抽象，甚至有些繁琐。但当自己真正经历一个项目之后，就会发现这些流程和方法并不是多余的，而是在帮助我们降低复杂度、减少沟通成本、提高软件质量。软件工程并不是让开发变得更麻烦，而是让复杂的软件开发变得更可控。

本学期的软件工程课，从最开始听到团队项目的时间节点的时候，其实我的内心很担忧、很焦虑，因为时间紧，而且我们的系统实现起来并不简单，但经过团队成员的努力，我们也按时交付了系统，这也是我第一次如此正式地按照各种规范来进行开发，团队也进行了充分的交流，每两天就开一次例会，在这个过程中收获了许多。