[I.3] 个人作业：结课总结
[I.3] 个人作业：结课总结
一个学期的软件工程课程结束，从最开始的书本阅读提问，到经历个人项目、结对编程、团队项目，再回头看期初提出的问题，很多困惑在实践的过程里有了更具体的答案，也产生了新的思考。这篇博客既是对期初问题的回顾解答，也是一学期实践的个人总结。
一、原有问题的解答与认知更新
问题一：COCOMO模型中的指数1.05是否低估了大规模项目的协作复杂度？
原问题核心：基础COCOMO模型的指数1.05意味着工作量与代码量近似线性关系，这是否与Brooks法则揭示的沟通成本平方增长相矛盾？
当前解答：是的，基础COCOMO模型确实低估了大规模项目的协作复杂度。在团队项目中，多人协作时的沟通成本远超线性增长。跨模块联调阶段，不同功能模块之间的对接，让我切身体会到Brooks所说的沟通路径的真实存在。COCOMO II模型引入的调整因子（1.05-1.20）更贴近实际，但对于学生团队这种经验不足、规范尚未统一的场景，仍然可能低估。
问题二：单元测试必须由最熟悉代码的人（作者）来写，这一原则是否绝对？
原问题核心：作者写测试效率高但存在"自我验证"盲区，学生团队是否应互相审查测试用例？
当前解答：这一原则不是绝对的，尤其在学生团队和经验不足的场景下。在花见小路结对项目中，T1的胜负判定逻辑相对简单，由作者编写测试确实高效；但到T2的状态推演时，竞争和赠予的反转逻辑极其复杂，作者在编写测试时反复陷入自己的思维定式，漏掉了一些边界场景。后来我们改为"作者写基础路径测试 + 结对伙伴专门设计边界/异常测试"的混合模式，才补上了这些盲区。团队项目中，我们对核心模块也采用了类似机制：作者写初版，同伴审查补充。效率与客观性可以兼顾，关键是根据模块复杂度灵活选择策略。
问题三：敏捷流程中的"每日例会"在学生团队中如何避免流于形式？
原问题核心：学生团队规模小、耦合度不高，每日立会容易变成流水账，是否应灵活调整？
当前解答：应该灵活调整。我的理解是：例会的本质是同步阻碍而非汇报进度，当团队耦合度低、进度透明时，完全可以降低频率。
问题四：结对编程中"驾驶员"和"领航员"的角色切换如何真正落地？
原问题核心：技术水平差异导致"一人主导、一人旁观"，强制轮换是否现实？
当前解答：在花见小路三人结对项目中，我们深刻体会到强制轮换键盘效率很低。初期严格遵循"每30分钟轮换"，结果由于技术熟悉度差异，队友轮换后经常陷入"不知道该怎么写"的窘境，反而拖慢了进度。后来我们调整为"按任务模块轮换主导权"：每个人在自己理解最深的模块主导编码，其他人全程审查、随时打断提问。这种"基于领域知识的轮换"比"基于时间的轮换"更适合学生团队。对于技术差距较大的配对，"导师-学生"模式并非坏事，关键是明确当前角色定位——重要的是知识传递和代码质量，而不是形式上的平等。
问题五：教材中"猪、鸡和鹦鹉"的比喻是否过于简化了团队成员的复杂性？
原问题核心：角色是否应固化？是否应关注如何帮助"鸡"成长为"猪"？
当前解答：这个比喻确实过于二元对立，但仍有其价值——价值在于识别当前状态，而非固化标签。与其分类，不如思考是什么阻碍了投入——是任务匹配度、能力瓶颈还是沟通问题？帮助队友成长的关键，是创造让他能深度参与的责任场景，而不是贴标签。
二、项目全流程
结合个人项目、结对项目与团队项目的完整流程，六个阶段各有一个让我印象最深刻的知识点：
1. 需求阶段：优先实现用户最在意的需求
团队项目初期，我们罗列了很多待做功能，想一次性做全。经过需求调研与优先级排序后，我们优先落地了用户最核心的需求，把次要功能后置。最终不仅按期交付了可用版本，也精准命中了用户的核心诉求，避免了在非核心功能上浪费开发资源。这让我理解了产品初期"少即是多"的真正含义。
2. 设计阶段：高内聚低耦合是降低维护成本的核心
在花见小路T1的设计中，我们将胜负判定拆分为多个独立辅助函数，而不是写在一个大函数里。这个设计在T2和T3中被反复复用，节省了大量重复开发时间。拆分模块后，后续迭代效率明显提升。这不是书本上的空口号，是能实实在在减少后期返工的设计原则。
3. 实现阶段：团队协作中，可读性优先于"炫技式优雅"
团队项目中，优先写直白、注释清晰的代码，哪怕多几行也没关系。结对项目里也一样——花见小路T2的状态推演逻辑，我最初写了一个嵌套很深的条件表达式，队友完全无法审查，后来拆成多个简单判断后，虽然代码量变多了，但审查效率大幅提升。团队项目里，能让所有人快速读懂、快速修改的代码，才是好代码。
4. 测试阶段：边界异常场景比正常流程更能发现问题
最初我们的测试用例全是正常操作路径，几乎测不出bug；后来专门设计空输入、超长字符、并发操作等边界场景，立刻测出了大量隐藏问题。在花见小路T1中，我们设计的测试场景覆盖了各种边界情况，这些测试在后续T2/T3迭代中多次提前暴露问题。测试的核心是"找异常"，而不是验证"正常流程能跑通"。
5. 发布阶段：灰度发布是控制上线风险的最低成本手段
在个人项目分析网易云音乐时，我注意到成熟产品普遍采用灰度发布策略——先向小部分用户推送新版本，观察运行数据后再逐步扩大范围。这种策略的核心价值在于：当新版本存在潜在问题时，影响面被严格限制，团队有充足时间修复后再全量推送。即使在小体量的课程项目中，这种"先验证、后推广"的思路同样适用，它本质上是工程实践中风险控制的底线思维。
6. 维护阶段：用户反馈是最高质量的测试用例来源
维护不是被动修bug，而是主动收集用户反馈，持续补充产品的边界场景。这让我意识到，软件工程不是"开发完就结束"，而是一个持续演进的闭环。
三、结合项目经历的理解与心得
个人项目[I.1]（软件案例分析）
通过对网易云音乐的调研、评测和分析，我第一次以"产品工程师"而非"普通用户"的视角审视一个软件。从多个维度进行量化评分，让我建立了系统化的产品分析框架。特别是Bug分析环节，让我学会了如何规范地描述、复现和评估软件缺陷，这为后续团队项目的测试工作打下了基础。
结对项目（花见小路桌游）
这是我第一次接触AssemblyScript和Wasm，从环境搭建到T3的AI策略实现，整个过程充满了挑战。三人结对的模式让我们体会到：结对编程在复杂逻辑推演时效果显著，认知负担的分摊让我们能快速理清复杂逻辑；但在简单模块时略显拖沓。最大的收获是学会了"在约束中找平衡"——时间有限、算力有限、信息不完整，简单的贪心策略比追求完美的算法更实用。这种"够用就好"的工程思维，可能比具体的算法实现更有长远价值。
团队项目
团队项目让我真正理解了软件工程是"关于人的工程"。沟通成本、任务分工、代码规范、冲突解决，这些"软技能"的重要性不亚于技术能力。这也让我对学期初提出的"猪鸡鹦鹉"问题有了更深的理解：角色是流动的，环境塑造角色，而非角色定义人。
四、新产生的问题
AI辅助编程对结对编程模式的冲击：本学期我们大量使用AI辅助开发，AI在某种程度上扮演了"永不疲倦的领航员"角色。在这种情况下，传统的双人结对编程是否还有不可替代的价值？
浙公网安备 33010602011771号