总结和回顾
| 这个作业属于哪个课程 | 软件工程2021春软件工程W班(FZU) |
|---|---|
| 个人学号 | 221801435 |
| 作业要求 | 作业链接 |
| 作业目标 | 课程回顾与技术总结 |
| 参考文献 | 构建之法 |
课程回顾与总结
问题解答
问题1：单元测试的密度如何安排？
回答：
经过软件工程实践，我认为单元测试的密度还是越小越好。因为单元测试主要有开发人员来执行，其目的在于测试刚刚编写完成的代码是否按照预期功能工作，如果单元测试的密度过大（比如几个模块合起来），则不好确认错误发生的位置（可能A觉得是B的代码错了，B觉得是A的代码错了）。且密度大的测试（比如集成测试、系统测试）应该由测试人员来完成，而不是开发人员。单元测试应该与编写代码同步执行。
问题2：单元测试一定要由程序的作者来写吗？
回答：
是的。按问题1的解答，单元测试的目的在于测试编写的代码有无错误，应该由开发人员在编写完一个模块不久之后进行。代码编写者一定是最先测试的人，如果遇到解决不了的问题才去请教他人。
问题3： 敏捷开发一定是好的吗？
回答：
敏捷开发好不好取决于许多因素，例如团队的技术水平、团队的管理水平等，需要依照实际情况而定。书上也提到敏捷开发并不对立于传统的软件工程实践，相比于传统的开发模式用“纪律”来约束软件工程师，敏捷开发显得更为“宽容”。敏捷开发需要保留最重要的工作产品并使其保持简洁，并要求成员团队之间、技术人员和客户之间进行快速的交流，以达到灵活调整的目的。我认为在这次软工实践中，我们团队虽然有交流，但是只局限与个别核心开发人员，且每个人负责的部分相对独立（例如前端、后端、算法，只是在接口上做了约定，没有在结构上考虑到扩展性问题），并不满足敏捷开发的要求。
问题4： 团队之间如何配合做好代码的整理工作？
回答：
首先，制定统一的代码规范是必要的，只有代码规范相同，队友才“有可能”读懂你的代码，并在此基础上进行合并。虽然每个人的代码实现逻辑不同，但从实践经验来看，每个人并不需要去理解队友的代码逻辑，只要写好注释，知道输入什么，输出什么即可，还有要标注这段代码是谁负责的，出了问题（输入、输出和预期不相符）只要找编写代码的人就行。这样才是高效的团队协作。
问题5：关于创新的思考。
回答：
我认为，创新大致可以分为两个方向，一个是技术上的创新，一个是功能上的创新。技术上的创新，是在大家功能都相同的基础上，我做的效果比你的好，具体来说，可以从实现效果、响应时间等进行优化，也可以利用业界最新推出的算法，和技术结合，比如山烛中的视频推荐算法、视频超分辨率算法等。功能上的创新，指的是做出一个从来没有人实现的功能，当然这个比较难，比较常见的还是将已有的功能结合在一起，看看能不能产生新的“化学反应”，例如山烛中将视频和讨论结合，每个视频都对应一个问题解答区这样，当然，现在看来这两个功能的关联还没有那么大，这个可能以后还得再想想。
新的问题：PSP表格没有那么有用？
提问：
在实战开发过程中，PSP表格要求我们预计一下在每个阶段所耗费的时间，最后再统计一下实际所消耗的时间，但是这对于开发好像没有什么帮助，请问这里记录时间的意义是为了让我们意识到时间规划上的错误，方便我们在下一个项目中进行时间上的安排吗？
新的问题：测试所花费的时间太多
提问：
测试要花费大量的时间（有时候开发和测试的时间占比能达到1：1），在时间有限的情况下，如何合理的安排测试范围，有重点地进行测试？
每个阶段的收获
需求分析
最大的收获是学会了从用户的角度来思考问题，在写一个软件之前，我会考虑用户为什么要使用这个产品？相比于市面上已有的产品，我们的优势是什么。以及学会了NABCD分析这样一种比较系统的需求分析方法。还学会如何利用axure制作原型。
系统设计
最大的收获是学会了如何绘制类图，将类图和我们实际项目相匹配，理顺类与类之间多对一、一对一、多对多的关系，理清类与类之间的聚合关系，为实际编码做准备。此外，我还负责设计系统的体系结构，明白vue+spring+mybatis之间是如何进行通讯的。
实现阶段
学会了springboot+mybatis的具体用法，复现了YoutubeNet论文，并会编写简单的flask代码，将算法执行结果以接口的格式返回。在编写算法的过程中，需要考虑一些应用上的因素，比如没有审核过的视频不能推荐给用户（这里要在输出前进行一次过滤），当用户没有搜索记录时如何推荐视频（最终采用随机推荐，因为网站也不知道客户想看什么视频，只能每种都推荐一点，再收集用户的喜好）。在编写后端的过程中，要注意参数校验，不然会有空指针异常等bug产生。
测试阶段
让我明白了测试的重要性：在编写代码时使用白盒测试可以让我们验证函数的正确性；在发布之前进行黑盒测试、集成测试可以让我们提前发现一些交互上的bug；在进行压力测试的过程中，我们能大致了解我们的系统的性能满不满足实际应用的要求。
发布阶段
这个阶段主要在收集用户反馈，并对产品进行微调。收获是：用户反馈是改进系统的最佳材料。一些我们预设的功能在用户看来并不是很方便，我们可以根据用户反馈对系统进行整改。
个人心得
个人项目
项目内容为统计单词出现的次数，这题算法不算复杂，但是需要考虑一些边界情况，总体来说还是要多做测试，并根据测试的结果调整算法代码（有点类似于leetcode）。此外，还得注意算法的时间复杂度能不能满足处理大篇幅文章的需要。
结对编程
结对编程，即团队只有两个人。相比于软工实践10个人的团队，结对编程所需要的沟通成本较小，且两个人也可以从不同的角度思考问题，思维和技术上的互补为解决编程上的难题提供了很大的帮助，但是前提是多交流，多沟通，否则两个人容易手忙脚乱。由于只有两个人，一些约定显得不是那么重要，比如一定要遵守一样的代码规范。
团队项目
相比于结对编程，团队项目的参与人数更多，工作量更重。这要求我们必须在开始写代码之前就制定好统一的规范，并严格遵守，这样才能方便后续分配任务，以及整合代码。在沟通方面，团队项目的沟通成本比较大，可以分为几个小组，比如前端小组、后端小组、算法小组、测试小组，每个小组指定一名负责人，小组成员与负责人沟通，负责人之间再进行协调，这样可以大大减少沟通成本。
个人技术总结
基于YoutubeNet的视频推荐接口实现
概述：该技术的使用场景包括视频推荐、书籍推荐、文章推荐等，多用于在页面主页给用户推荐用户可能感兴趣的内容。学习该技术的原因：模型简单、速度快，满足在线使用的需求。 该技术的难点：论文的提到的结构可能和实际应用场景不同，需要对其进行数据预处理、修改网络结构。
