悠悠，不尽长江滚滚来
| 相关问题 | 具体内容 |
|---|---|
| 这个作业属于哪个课程 | <2021春软件工程实践S班> |
| 这个作业要求在哪里 | <软工实践总结&个人技术博客> |
| 这个作业的目标 | <回顾课程与总结> |
| 其他参考文献 | <> |
第一部分：课程回顾与总结
问题链接
<寒假作业二>
问题解答
问题一：对软件工程职业道德的探讨
对职业道德的道德标准提出了疑问，经过查阅《构建之法》第十七章了解到IEEE/ACM发布的《软件工程师职业道德规范与标准》，这一规范包括有关职业软件工程师的行为和决断的八项准则，设计软件工程方面的实际工作者、教育工作者、经理、主管、决策制定者以及相关受训人员和学生。而解决道德冲突最好的办法是对基本原则进行全面思考，而不是盲从某些具体条目，这些原则应当会促使软件工程师们去更广泛思考哪些是他们工作受众，去思考他和他的同事是否给与其他人以足够的尊重等，在这些思考中，对公众健康、安全与福利的关注是最主要的，也就是说，“公众利益”为核心。就抢票软件来说，确实没有损害公众利益，公众以钱购票。就这一方面它没有违反职业道德。
问题二：两人合作方式
两人合作究竟是以平等方式还是有一人导向方式提出了疑问，查阅《构建之法》发现，两人合作的不同阶段有不同的技巧，没有绝对正确或错误的方法，只有合适或不合适的方法，“三明治”方法就是能够给别人提供容易接受反馈的方法。在经过结对作业后发现没有绝对的领导关系，二人就自己的专长提出建议，互相赞同，二人的合作关系才能走得长远。
问题三：需求分析与软件设计关系
当软件设计超过需求该怎么办，就软件设计而言，用户需求是最低底线，如果在完成需求之后进行拓展不是问题，但如果忽略需求一味研究新功能而浪费时间则不可取。
问题四：bug的重现性低
对于复现性低的bug，是要积累用户反馈后统一解决还是只要用户反馈就反复多次执行寻找？在实践过后我觉得，bug描述方式很重要，一般都需要写清操作系统、运行环境、出现的地方、导致出现的操作等具体信息，这时开发人员再去重现bug时可重现性会大幅增加，如果还是无法重现，可以暂时记录，然后等其他用户提一样的问题后再根据提交的详情进行bug重现，这样的话效率也会提高，比开发人员毫无头绪乱找一通可操作性强。
问题五：软件重构与重写
软件临近发行发现某个功能可以更好，是要推迟发行时间还是忽略更新？如《构建之法》第十五章终所说，项目的当前阶段是一个阻尼振荡的过程，要收敛与稳定，等到下一个版本再进行发散思考，可以使用DCR管理。发布方式其实有很多，在经历Alpha、Beta、Beta1、Beta2等发布方式后，在发布间隔可以接收用户反馈对项目进行改进，发布本身就是一个渐进过程，可以一步步改进，没有必要为某个功能延迟发布第一关。
问题六:创新时机
有了创新却在执行过程中受阻，此时有新的idea是否要放弃之前创新？《构造之法》第十六章提到“创新者就是冒险家”，根据研究，创新人士关键特点不是喜欢冒险，也不是躲避风险，而是从错误中恢复并继续努力，即“屡败屡战”。只有坚持到最后才能知道自己的创新是否有意义，如果打一枪换一地，永远不会有成就，不是说有创新点就一定会成功，重要的是坚持。
各阶段收获知识和能力
项目需求
主要是进行需求分析，通过沟通与收集资料获取需求，并通过NABCD模型进行针对性分析，学会了问卷调查、资料分析、NABCD分析等
项目设计
进行系统设计、数据库设计，通过画类图对需求进行进一步细化，掌握了图形化设计
项目实现
此次团队项目做了游戏，实现用C#，学会了脚本语言，熟悉了unity使用
项目测试
测试有用到单元测试，兼容性测试，学会通过测试代码找bug，也学会通过第三方软件测试，也知道了测试不止测功能还有用户体验
项目发布
发布不是一次发布就结束的，先发布初版，然后用户反馈开发修改再发布，在发布阶段学会收集用户反馈并针对bug寻找修改
阶段理解与心得
个人项目
个人作业任务是写词频统计，代码写完之后并没有在自动化测试下获得通过，说明代码书写能力还有待提高；GitHub的代码迁入在当时也不熟悉，走了很多弯路，也浪费了很多时间，不过最终掌握了新的类用法和git
结对编程
结对编程是做顶会热词，我们用了php做网页，我主要负责前端设计实现，发现前后端交互还是有问题，有时候一样的布局代码在不同页面下显示不一，不过最后与队友一起努力完成了这个项目，也理解了两人合作的好处
团队项目
团队项目很考验团队合作，我们在队长指导下各司其职可以事倍功半，也学习了新知识
第二部分：个人技术总结
基本介绍
使用自动化测试工具Selenium IDE打开系统页面录制操作，导出自动化代码
