个人博客作业 3：回答博客1 提出的问题，提出新问题，并总结收获
课程：现代软件工程
学期：2025 年秋季
学生：李梦洋
项目：汪洁步道
第一部分：回顾《构建之法》中的提问与现在的理解
在学期初阅读《构建之法》并完成提问作业时，我更多是站在“读者”和“旁观者”的角度，对书中的方法和观点提出疑问。经过大半个学期的课程学习与项目实践，尤其是在团队项目中的实际参与，我开始能够从实践角度重新理解当初提出的问题。
第一次博客原文链接：https://blog.csdn.net/2302_80926211/article/details/153052578?spm=1001.2014.3001.5502
以下是我对第一次博客中五个问题的回顾与现在的回答
问题一：在强调「共享愿景」的 MSF 模型中，个体创新是否会被限制？
现在的理解：
在学期初，我担心当团队过于强调“方向一致”时，会不会反而限制个人的创新想法。但在经历了“汪洁步道”项目之后，我对这个问题有了新的认识。
在项目过程中，我们团队对整体目标和方向是比较一致的，这种一致性并没有限制个人的想法，反而提供了一个共同讨论的基础。在此之上，每个人依然可以提出不同的实现思路和改进方案。通过不断讨论和交流，大家的想法被不断碰撞、修正，最终形成一个更合理、也更可执行的方向。
我现在的理解是：
方向一致并不等于思路单一。
只要团队中允许讨论和表达不同意见，共享愿景不仅不会压制创新，反而能让个人的创新更容易被理解、被整合，并转化为团队的成果。
问题二：为什么“能力高但动力低”的成员最难管理？
目前的状态：暂时无法回答
对于这个问题，我目前还没有足够的实践经验来给出明确回答。
在这学期的团队项目中，我们小组只有三名成员，合作关系相对平等，也没有明显的“领导者—被管理者”结构，更不存在通过绩效或激励来调动成员积极性的情况。因此，书中提到的“高能力但低动力成员”的管理问题，并没有在我们的团队中真实出现。
我认为，这个问题可能更适合在规模更大的团队、或更接近真实企业环境的项目中去观察和理解。现阶段我只能保留这个问题，等待未来有更多实践经验后再重新思考。
问题三：在“快速交付”的文化下，如何防止“萝卜型程序员”主导项目？
现在的理解：
结合课程项目的体验，以及对书中内容的再理解，我逐渐意识到，“萝卜型程序员”并不只是个人问题，而更多是团队评价方式和目标导向的问题。
如果一个团队过于强调“做得快”“展示效果好”，却忽视代码质量、可维护性和长期成本，那么追求速度的人自然会占据优势。这种情况下，即使成员本身并非有意忽视质量，也会被环境推向“快而不稳”的做法。
因此，真正需要调整的不是某一类程序员，而是团队是否建立了合理的反馈与评价机制，例如代码评审、阶段性回顾，以及对后期维护成本的关注。只有当“长期价值”被真正纳入考虑，团队才能避免被短期产出牵着走。
问题四：CMMI 的层级文化与敏捷精神是否存在冲突？
现在的理解：
在学期初阅读《构建之法》时，我觉得 CMMI 强调流程和规范，而敏捷强调灵活与快速反馈，两者在理念上似乎存在冲突。但结合课程中的项目实践来看，我的看法有所变化。
对于学生团队或小规模项目来说，过于复杂、严格的流程确实容易增加负担，甚至流于形式。但这并不意味着流程本身没有价值。关键不在于“是否使用流程”，而在于使用到什么程度，以及是否服务于实际问题。
我现在更倾向于认为，CMMI 提供的是一种“底线思维”，帮助团队避免混乱，而敏捷方法则强调在此基础上的快速调整和反馈。如果成员能够理解流程存在的意义，而不是为了完成任务而机械执行，那么二者并非不可结合。
问题五：创新与失败是否可以在课程教学中共存？
新的思考（结合本课程）：
在阅读书中关于“鼓励失败”的内容后，我开始思考：这种理念是否也可以应用到课程教学中。
在很多课程中，失败往往意味着扣分或否定，这容易让学生在项目选择和实现方式上趋于保守。如果课程中能够为“失败”提供一定的空间，例如允许学生尝试有风险的方案，即使结果不理想，老师依然能给出反馈、点评和指导，那么学生可能会更愿意尝试真正具有挑战性的想法。
我认为，鼓励失败并不等于不要求成果，而是在失败后给予分析和反馈的机会。这种方式或许更有助于培养学生的探索能力和工程思维，而不仅仅是完成任务本身。
第二部分：AI 时代的软件开发——我产生的新问题与思考
在学习《现代软件工程》这门课程的过程中，AI 工具已经逐渐成为编程和软件开发中无法忽视的一部分。无论是在代码编写、问题排查，还是在理解新技术和新框架时，AI 都能提供快速而直接的帮助。这种变化也促使我开始重新思考：在 AI 时代，软件开发者的角色是否正在发生转变？
1. 当 AI 可以快速生成代码时，程序员的核心价值是什么？
在课程项目中，我多次使用 AI 工具来辅助完成代码编写或解决调试问题。相比过去完全依赖搜索引擎和文档，AI 的响应速度和针对性都更高，这让我明显感觉到“写代码本身”的门槛正在降低。
这也引出了一个问题：
如果 AI 可以在短时间内生成结构完整、语法正确的代码，那么程序员是否会逐渐从“代码编写者”转变为“代码评审者”和“问题定义者”？
我目前的理解是，AI 更擅长回答“怎么写”，但很难回答“为什么要这样写”以及“这个问题是否值得解决”。在 AI 辅助下，程序员的价值可能更多体现在需求理解、系统设计、技术取舍以及对结果负责的能力上。
2. AI 的使用是否会弱化软件工程方法的重要性？
在某些情况下，借助 AI 工具可以绕过原本较为复杂的设计和分析过程，直接得到一个“看起来能用”的解决方案。这让我一度产生疑问：在 AI 的帮助下，是否还需要像《构建之法》中强调的那些软件工程方法和流程？
但结合团队项目的经验来看，问题的关键并不在于“有没有 AI”，而在于“是否理解自己在做什么”。当缺乏清晰需求和合理设计时，即使 AI 生成了代码，也往往难以维护、扩展或与他人协作。
因此，我逐渐意识到：
AI 并不会替代软件工程方法，反而放大了不懂工程方法所带来的问题。
流程和方法依然是团队协作和长期开发的基础，而 AI 更像是一种加速器，而不是方向盘。
3. 在团队协作中，如何合理使用 AI 而不削弱个人能力？
另一个让我困惑的问题是，在团队项目中，如何界定 AI 的合理使用边界。
如果过度依赖 AI，成员可能会逐渐减少对底层逻辑和实现细节的思考；但如果完全排斥 AI，又可能降低效率，甚至脱离现实开发环境。这种矛盾在课程学习中也逐渐显现出来。
我认为，课程和团队项目中更值得鼓励的，或许不是“用不用 AI”，而是是否能够解释清楚 AI 给出的方案、是否理解其中的原理，以及是否能在此基础上进行修改和优化。这样，AI 才能成为提升学习效果的工具，而不是替代思考的捷径。
4. 软件工程课程是否需要因 AI 而调整教学重点？
在 AI 时代，学生可以更快地完成“功能实现”，这也对课程设计提出了新的挑战。
相比单纯考察代码是否正确，课程是否可以更加关注：
- 学生是否能清晰描述问题和需求；
- 是否能进行合理的系统设计和模块划分；
- 是否能在团队中有效沟通、协作和复盘。
这些能力往往是 AI 难以直接替代的，也更接近真实软件工程中对开发者的要求。这也是我在学习这门课程后，对未来软件工程教学方式产生的一个重要思考。
小结
总体来看，AI 的出现并没有让我觉得软件工程变得“更简单”，反而让我更加清楚地认识到：
真正困难的部分从来不是写代码，而是理解问题、做出取舍并对结果负责。
如何在 AI 的辅助下，依然保持对软件工程方法、团队协作和长期价值的重视，是我在本学期课程结束后，仍然持续思考的问题。
第三部分：从 NCL 理想教学环境出发，对本学期教学方式的反思与评价
学期初，老师向我们介绍了 NCL 所提出的理想教学环境（https://www.cnblogs.com/xinz/archive/2011/12/29/2306652.html#ncl）。该理念强调实践导向、学生主动参与、持续反馈以及接近真实工程环境的学习方式。
在学期接近结束时回顾这门《现代软件工程》课程，我认为本学期采用的多种教学方法，确实在方向上与 NCL 理想教学环境高度一致，也给我带来了不同于传统课程的学习体验。但在实际实施过程中，这些方法在反馈机制、组织方式和现实可行性上，仍然存在一些问题，与我理想中的学习环境有一定差距。
以下结合具体教学方式，逐一进行评价。
1. 以公开博客交作业 & 千帆竞发图的进度跟踪
公开博客作为作业提交方式，增强了作业的公开性和持续性，也促使我更认真地整理自己的思考过程。千帆竞发图在一定程度上起到了进度对比和督促作用，让我能够直观地看到自己在整体中的位置。
但在实际使用中，我认为千帆竞发图的反馈信息不够充分。虽然每个阶段给出了分数，但并没有明确说明评分依据和扣分原因。例如，在某些阶段我们得到了较低分数，但从我们的理解来看，已经按要求完成了任务，却无法明确知道问题出在哪里。这种“只有结果、没有解释”的反馈，削弱了评价本身的指导意义。
如果能在分数之外，给出简要的评价说明或改进方向，千帆竞发图的价值会更大。
2. 结对编程与 API 驱动的编程方式
结对编程本身是一种非常贴近真实工程实践的学习方式，但其效果高度依赖队友的参与度。如果队友不够积极，很容易出现一个人承担主要工作，另一个人参与度较低的情况，这在实际操作中并不少见。
此外，在实际测试和提交阶段，DDL 的设置和通知方式也存在问题。有些提交时间是临时公布的，助教或老师并未提前明确说明，导致部分同学没有合理安排时间，最终出现项目晚交的情况。这种突发式的截止时间，与强调工程规划和时间管理的软件工程理念本身是有冲突的。
3. pq-问答的当堂测试与软件 UX 的现场测试
pq-问答这种形式本身非常好，能够有效考察学生对问题的理解程度，也符合软件工程中“即时判断”的特点。
但在实际使用过程中，pq 系统本身存在一些明显问题，例如：
- 缺乏明确的答题提醒机制；
- 系统 bug 较多，稳定性不足；
- 容易在不知情的情况下错过答题。
这些问题在一定程度上影响了测试的公平性，也干扰了原本应有的教学效果。如果 pq 系统本身能持续迭代和优化，这种测试方式的价值会更加突出。
4. 学生自行组队并选择项目
学生自行组队并选择项目这一点整体来说是非常好的，能够提升参与感和责任意识。
但在具体项目设计上，我认为仍有改进空间。以我们组的“汪洁步道”项目为例，该项目的核心难点和重点更多集中在硬件层面，软件内容在项目前期很难展开，直到后期才被迫紧急补入。这导致软件工程相关的方法和流程，在项目前半段难以充分体现。
我认为，如果是由老师提出的项目，最好能在立项阶段：
- 明确项目的主要难点和侧重点；
- 对软件工程相关内容提出更具体的要求；
- 或由老师提前审核项目结构，确保项目本身适合本课程的学习目标。
5. Alpha 阶段后强制团队人员变动
我们小组并未经历人员变动，因此这一环节对我个人的直接影响不大。
从工程实践角度来看，人员变动在真实项目中确实很常见，但在学院环境中，学生课后和课下仍需要长期共同学习和合作。强制性的人员调整，可能会在一定程度上影响同学之间的人际关系，甚至带来额外的沟通成本。
我认为这一机制在理念上值得理解，但在实际执行时，是否需要更灵活的方式，仍有进一步探讨的空间。
6. 邀请业界专家、相关老师与工程师进行讲课与 Demo
这一部分我认为整体效果非常好。业界人士的分享让我对软件工程在真实环境中的应用有了更直观的认识，也帮助我建立了课堂知识与未来工作的联系。
这种形式相比纯理论讲授更有吸引力，也更容易激发学习兴趣。
7. 用“天使投资”的方式评选团队项目
通过“天使投资”的方式评选项目成果，让我第一次从“价值”和“可行性”的角度重新审视团队项目，而不仅仅是功能是否完成。这种评价方式非常新颖，也很有现实意义。
我个人认为这一教学方式是成功的，值得保留。
8. 对课程组织与信息传达方式的补充意见
一个非常实际但重要的问题是课程信息的传达方式。目前课程群中经常转发大量文章和资料，这在一定程度上造成了信息淹没。当需要查找关键通知（如提交时间、测试安排）时，会变得比较困难。
我建议可以考虑将课程群分为：
- 通知群：只发布与课程安排、DDL 相关的重要信息；
- 分享群：用于转发文章、资料和扩展阅读。
此外，学生通常同时修多门课程，很难像老师设想的那样，将大量时间持续投入到一门课程中。如果在课程设计中能更充分考虑学生整体时间分配情况，学习体验可能会更加合理。
小结
总体来看，这门课程在教学理念上是先进的，很多方法也确实让我跳出了以往“听课—考试”的学习模式。但在具体实施过程中，反馈透明度、组织方式和现实可行性仍然是影响学习体验的重要因素。
如果未来能在这些方面进一步优化，我认为这门课程将更接近我心中理想的学习环境。
第四部分：基于自我评价表的学习反思与成长总结
参考老师提供的自我评价表（https://www.cnblogs.com/xinz/p/3852177.html），我从“课前状态”和“课后变化”的角度，对自己在本学期《现代软件工程》课程中的成长进行了简要回顾。以下是我认为提升最明显的几个方面。
1. 从“只关注代码实现”到“先思考问题本身”
课前：
在以往的课程和项目中，我更习惯于拿到任务后直接思考“怎么写代码”“怎么实现功能”，很少花时间系统性地分析需求是否合理、问题是否定义清楚。
课后：
通过课程中的项目实践和反复的讨论，我逐渐意识到：
很多问题不是写代码解决不了，而是从一开始就没有被正确理解。
现在在开始动手之前，我会更主动地思考问题的边界、目标以及实现是否有现实意义。
2. 团队协作意识的提升
课前：
虽然也参与过小组作业，但更多是“任务拆分 + 各自完成”，对整体协作过程关注不多。
课后：
在本课程的团队项目中，我更深刻地体会到沟通、同步和理解他人想法的重要性。结对编程、阶段展示和反思过程，都让我意识到：
软件工程不是个人能力的简单相加，而是协作质量的体现。
3. 对不确定性和反馈的适应能力
课前：
我更习惯于有明确要求和评分标准的任务，一旦目标模糊或规则变化，容易产生不安和抵触情绪。
课后：
在经历了多次不确定的项目要求、现场反馈和阶段调整后，我逐渐学会接受这种不确定性，并尝试从反馈中寻找改进方向，而不是只关注结果是否“对或错”。
4. 表达与反思能力的提升
课前：
写作业更多是为了完成任务，很少系统总结自己的想法和过程。
课后：
通过公开博客的形式，我开始有意识地整理自己的思考路径，并尝试把模糊的感受转化为相对清晰的文字。这一过程虽然一开始并不轻松，但对我反思学习过程帮助很大。
小结
总体来看，这门课程让我最大的变化，并不是掌握了多少具体技术，而是逐渐学会了如何面对复杂问题、如何在不确定的环境中协作，以及如何通过反思不断调整自己的学习方式。
这些能力的提升，可能在短期内难以量化，但我认为它们对今后的学习和发展具有长期价值。
)
)
)