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

提问博客链接

个人作业：阅读和提问

疑问回答

我在最开始的博客中提出了五个问题，经过一个学期的实践和思考，虽说并不是都能够完整解答，但无疑都有了新的理解。

问题一 ：结对编程真的足够易于实现吗？

我在一开始曾怀疑没有配合经验的两个人会难以进行结对编程，我的结对编程也是找到了相熟的同学，得到了不错的编程体验，事实上我觉得不熟悉的两个人本身就会经历一段磨合期，也并非是结对编程的问题，所以我觉得两个人先稍微相互了解后就能够顺利进行结对编程了。

问题二：如何在实际项目中平衡用户的核心需求（Need）与潜在需求？

先区分需求类型：核心需求应该是用户能明确表达的痛点。可通过访谈或问卷直接收集，而潜在需求则可能是用户未意识到的优化点。需观察行为或分析数据得知，实际软件开发中因为收集数据和产能有限，优化核心需求是最关键的。

问题三： 根据项目规模的大小与所处阶段该如何合适地调整设计变更的默认响应模式？

需要量化阈值，在整体代码完成度低于80%时采用tell-mode

评估变更涉及的模块数，超过3个模块或者相关部分由多人负责完成，则采用Ask-mode

问题四：在事后分析中，如何评估用户反馈对项目的影响？需求变更是否被有效管理？

首先，变更和修改是难以避免的，所以必须要避免口头变更，所有变更需记录在工具，其次，对于用户的反馈，团队团队的策略是评估其必要性，若需要解决，则应当放入待办列表，并调整其优先级。

问题五：如何切实体会敏捷开发？

我之前以为“目前分工明确、需求和ddl相对固定”的情况可能无需敏捷开发，不过我还是太高估了软件开发进度的规律性。实际开发时进度常常会出现不一致的问题，譬如组员在某个时间段正好有事，没有太多时间去推进自己的工作，接口之间的协调也偏慢，这时候有必要开短小的例会，用以简单交流进度和互相帮忙处理问题。最关键的是按照预想的节奏推进进度。

我从各阶段学到了什么知识点

需求阶段

我们学会用“必须做/应该做/可以做/不做”来分类需求，确保先做最重要的功能。比如用户登录是“必须做”，而评论区是“可以做”。

设计阶段

我们需要去把整个软件的功能尽量解耦，拆成独立模块，而登陆模块这种关联全局的模块尽快完成，每个模块只负责一件事，把修改代码对其他部分的影响控制到最小。

实现阶段

因为对微信小程序的调研不足，我们发现很难绕过微信的审核限制去发布一款含有交易类内容的小程序，所以不得不转而采用uni-app，导致实现上遇到了一些预料之外的困难，幸而顺利解决了。

测试阶段

因为我没有负责后端的分支测试，所以只解除了黑盒测试，也就是不看代码内部，只检查功能对不对（比如点登录按钮能否跳转），这样能发现用户视角的问题。

发布阶段

先内部测试新版本，然后逐步放开发布范围，如果没有问题则可以进一步公开发布。

维护阶段

定期整理混乱的代码（比如重复代码合并成函数），否则越拖越难改

课程心得

上完软工课，我最大的收获是从"只关注功能实现"到工程化思维的建立：

• 学会用Git Flow管理分支
• 文档与代码同步更新（采用Swagger自动生成API文档）

正如课程中强调的："软件工程是团队的艺术"，这些经验将指导我未来的协作开发。