| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 班级博客 |
| 这个作业的要求在哪里 | 作业要求 |
| 我在这个课程的目标是 | 系统地提升软件工程能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾与总结学到的软件工程知识 |
一.提问回顾
1、关于第一章中的“软件的非连续性”
经过一学期的软工，我认识到这种“软件的非连续性”其实是指因为软件是一个离散的系统，当系统逻辑变得复杂时，输入上的微小变化可能会导致其经过不同分支，产生截然不同的结果，这种情况下，测试就变得尤为繁重和困难，需要保证每一个逻辑分支都能被覆盖，才能保证软件的可靠性，因此这种"非连续性"较大的影响了软件的开发成本。解决这个问题的一个重要方面便是在设计阶段合理的拆分和解耦合，将复杂逻辑拆成互不相关的简单逻辑，分而治之。
2.第二章---单元测试应覆盖所有的代码路径
我的观点同之前一样，还是认为不需要保证单元测试覆盖所有的代码路径，理由跟之前一样：
当一个项目非常庞大的时，对代码所有路径的100%测试覆盖需要编写的测试代码量可能比代码本身还大，测试工作量非常大；而其中的很多很多简单的代码，这种情况下我觉得不必为其编写测试代码。如何平衡测试效率和测试覆盖率是测试人员需要磨练的东西
3.第三章---软件工程师思维误区之过早泛化
我当时提的问题是有些项目扩展性不足、有些项目存在过早泛化问题，那么项目扩展性的度如何把握？
这个问题现在想想其实要求两点：
1.设计阶段就要对项目的架构、API等了解足够清晰。回顾我们软工开发的游戏《源码召唤》，我们发现一个问题：因为我们团队刚开始都是Unity小白，对很多游戏功能的实现都不了解，是后来边学边用的。因此回看我们设计阶段的技术规格文档，其实它非常简陋，此外不同人员负责游戏的不同模块，他们之间的对接主要是彼此商量出来的结果，并没有在设计阶段就很好地定义这些接口。设计阶段的接口定义模糊会导致项目的扩展性充满了未知。
2.认清你的预期
即给你的项目定个目标，预期能发展到什么程度，朝着那个目标去设计扩展性。
4.第四章-----关于结对编程的如何落地
我的观点同之前一样：
在我看来，结对编程的复审可以以一个函数为单位，这里说的“任何一段代码”不必细化到每一行代码，在复审时对方只需要对这个函数的功能做一定的单元测试+了解这个函数的实现思路即可。在开发前设计好各个函数的输入输出以及边界情况等，就像OO课程里的JML一样;同时通过代码规范检查等机制来限制每个函数的大小、行数，这样在对方复审时检查工作会容易进行得多，有利于结对编程的落地
5.第九章---高效的团队讨论
之前我对“高效的团队讨论”提出了自己想到的一个问题
有些会议存在这样一个问题：议题过于庞杂，有些议题无关乎一些与会者当下正在做的或者是相关的工作和领域，被强行凑进一个会，这时的会议的讨论与与会者其实是无关的，也浪费了与会者的时间。
回过头来看，开发阶段我的软工团队例会基本是每天一次，大家一起通过腾讯会议说说自己这一天完成了什么工作，并由PM分配下一天的任务。可能其他队员说的工作跟你毫不相关，但是我仍然觉花时间听别人的工作汇报和问题反馈非常有意义：别人汇报的工作让你对项目的进度有了更深入的了解，而不是只将焦点放在你负责的部分；通过别人的汇报你可以了解到对方干了啥，也敦促自己别摸鱼；别人遇到的问题可能下一个踩坑就是自己。总之会议内容与你无关的部分并不是就浪费了你的时间，多听多学也是很有帮助的。
二.知识点回顾
需求阶段
明确需求，保证调研的需求得是真需求，否则做好产品，再发现没人使用，那么整个项目的努力都会付之东流。
设计阶段
设计要定义好整个项目的架构给出明确的接口，定义好可重用的部分。在我们的开发的游戏中，这一点在游戏开发中尤为重要，因为各关卡的游戏场景里可重用的部分较多，定义好哪些组件可以重用，就把它做成一个prefab，后期修改这一组件会非常方便。
实现阶段
实现阶段我感受最深的是每日例会的作用，它帮助了我了解项目的整体开发进度，也起到了监督的作用，敦促了我不摸鱼，努力干活，同时每日例会也能反馈自己开发中遇到的问题，寻求技术帮助。
测试阶段
重视测试，频繁测试，全面测试。测试是保证产品可靠性和稳定性的重要手段,需要我们付出较多时间和精力。同时别将测试工作堆到开发完成后再统一做，否则测试工作将十分紧张。
发布阶段
注意给发布留出缓冲期，提前确定好发布平台，发布条件等，例如游戏的发布是否需要提供版号，这项要求在小米、华为应用商店就是必需的，在其他一些平台就没有硬性要求。提前确定发布在哪，能否发布，如何发布等环节非常重要，否则发布之时就会麻烦不断。
维护阶段
注意收集反馈，汇总问题和Bug，形成文档。
三.心得体会
结对编程
主要是明确分工，同时保持良好的沟通。明确分工，两人并发编程，提高效率，代码审查也多了一双眼睛；但同样为了让别人能看懂你的代码，又需要你像JML那样定义好各函数的输入输出、功能，增加了许多工作量，沟通不畅也会带来很多交流成本，有利有弊吧。
团队项目
此前我从未在一个多人团队中开发一个项目，这次的团队项目对我来说确实是一次有意义的经历与实践。从需求调研到设计到开发、测试再到发布、维护，我们团队7个人都为了同一个目标而努力，遇到问题可以互相请教和沟通，这种氛围、这段经历让我觉得开发并不孤独。此外，随着项目的一点点推进，产品也越来越完善，成就感也是很强的。总而言之，这学期的软工实践非常充实，丰富了我的团队开发经验，我学到了很多。