继往开来
| 这个作业属于哪个课程 | 2021春软件工程实践W班(福州大学) |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 对软件工程实践做出回顾与总结 |
| 其它参考文献 | 《构建之法》 |
目录
第一部分 课程回顾与总结
问题回顾
提出问题博客链接
问题
- 问题1
第二章2.1.3提到了回归测试，说到“如果一个模块或功能以前是正常工作的，但是在一个新的构建中除了问题，那么这个模块就出现了一个‘退步’”，下文又说“对于‘回归测试’中的‘回归’，我们可以将其理解为‘回归到以前不正常的状态’”，那么回归测试到底是处理旧的未发现的问题，还是处理由于模块更新而产生的新的问题？我的理解是在新版本上重新测试已经发现的bug，然后看是否引起了问题，需要进行相应的更新修改，查阅了资料之后发现也有部分声音认为回归测试指对于以前曾经测试过的内容（未出现bug）在新版中的重复性测试，所以应该怎么去理解？
回归测试官方的定义是指修改了旧代码后，重新进行测试确认修改没有引入新的错误或导致其他代码产生错误。我之前的理解是只要在新版本上重新测试已经发现的bug不会发现问题就不会带来软件的衰退，但是后来发现回归测试不仅仅需要对已经出现过的bug进行新一轮的测试，还需要对新添加的功能进行测试。新功能在实现与旧功能的集成之后，很有可能会产生一些新的bug。这个现象在团队作业中最有体现，因为每个成员负责的是不同模块的功能的编写，在将代码整合到一起的时候可能会出现新的问题，比如数据的传输等，如果仅仅是测试旧的bug而没有实现功能的有效整合最终的结果只能是一团糟。
引用助教的评论
张吖点:回归测试的目的是保证本来能够正常工作的软件在发生变化的情况下不产生衰退。触发回归测试的变化是多样的。它既可以是增加一个新功能，也可以是修复一个bug，还可以是修改软件配置。无论哪一种变化，都不应该导致软件衰退：即本来能够正常工作的部分(不管是功能点还是性能指标)被破坏。通常来说，实现回归测试的方法是重新执行测试用例。根据执行结果是否成功，来鉴别软件是否发生衰退。
- 问题2
第六章提到了敏捷流程，其中提到了敏捷的三个步骤，“第一步：找出完成产品需要做的事情；第二步：决定当前的冲刺；第三步：冲刺”。从字面上理解来看，再和平时所认知的开发流程进行对比，感觉差别不是很大。对敏捷还是无法理解，敏捷是不是就是要做什么事都要及早，及早发现问题，及早提交可运行的软件。我查阅了相关资料，传统的瀑布模式和敏捷开发模式适用于不同程熟度的软件公司，“软件成熟度较好的手机软件开发公司，引入了PM，按照CMM流程重视软件开发过程控制以及软件开发技术积累，同时为了能适应手机软件开发需求变化比较快的特点，不采用传统瀑布模式软件开发，引入了敏捷开发模式，在软件实践过程中，引入了FDD,ASD,XP的敏捷开发模式，在软件开发过程中，强调以构架为中心，以需求为驱动的迭代开发模式，通过构架，确保软件的可扩展性和接口合理性，强调接口设计，方便于迭代和合作开发”。还是无法很好地理解敏捷，那照查阅的资料来看，我们团队做普通的项目会有一些技术上的限制，是不是就无法采用敏捷流程了？
敏捷流程从我现在的角度看，就是在用户需求的基础上不断进行循序渐进的软件迭代过程，并且要求这个过程相对简单。敏捷流程可能需要的是将项目分成许多的项目来实现，就如同团队项目把它分成许多的模块来实现，每个模块各自可以拆开运行，同时也可以最后合并成最终的完整的项目。而实现过程简单，我们就在最初的需求分析阶段将一些不可靠的功能给排除在开发之外同时将一部分功能暂定，在后续的开发中再根据实际的情况进行取舍或是新功能的加入，有效的避免了过于复杂的开发过程。
- 问题3
第七章7.3提到了MSF团队模型，并且提到“在MSF团队模型中，人和技术项目都必须达到特定的关键质量目标，才能够被认为是成功的项目。任何一个角色无法实现其目标，都将危及整个项”，这个问题可能在我们后面团队合作的项目中都会遇到，每个人的能力不同，根据每个人的所长最初分配好了各自的职责，但是到最后可能由于各种各样的原因而导致一部分目标无法完成，那这样是不是在最初分配任务的时候多强调能者多劳，但是那样会给少部分人分配更多的工作时间，而且可能会让能力差的人产生依赖的心理，或者自身也可能会嫌弃自己的团队成员，而使得团队的气氛下降。所以遇到这种角色无法实现其所分配的既定目标时该如何处理？作为成员或者PM？
引用我当时的回答：我认为作为成员的话，完成自己所分配的任务是前提。当然，遇到这种角色无法实现其所分配的既定目标的时候，难免会出现矛盾，以我的做法是会在自己的能力范围之内再负责一些未完成的部分，以完成团队目标。学生生涯可能成员之间关系比较好，所以会互相迁就，但是一个团队不可能所有人都甘愿一次又一次地揽别人的活。如果再次发生，可能就需要与相关的负责人当面阐明相关的问题并解决。作为PM的话，首先得考虑到最初分配职责的时候是否真的根据团队成员的情况分配到位了，情况比较严重的时候要和当事人进行谈话了解实情并解决，为下一次的团队工作总结教训。因为参与团队项目的时候自己是从团队成员的角度去出发，比如在alpha冲刺阶段我完成了自己负责的代码部分，前端组长发现有成员的学习新知识的进度会比较慢，就会把其中一部分的任务分配给我，然后组长也会相应的增加该成员的其他任务比如说文档博客的撰写，内心的想法肯定是想抓紧时间一起把团队项目给做完，也不会考虑其他的东西，工作后可能就会比较在乎自身的任务量吧。
- 问题4
第十章10.4提到了功能驱动设计FDD，并且提到FDD适用于团队成员对于需求没有切身体会的情景，例如要实现不熟悉的行业（银行、证券、物流等）的业务系统，仅从纸面上看，FDD对单元测试之外的测试的讲述不足，那么有什么方法能在遇到这种情况下来替代FDD呢？查阅了资料，“PDD(Product-Feature Driven Design)产品特性驱动设计,我们可以将它使用在我们的日常设计工作中,它可以运用在你的大小设计项目中,这是一种行为模式,一种思考角度,或者我们把它作为一种指导方法.它依靠产品的自身特性来驱动设计”。我可以把它理解为更大众化的FDD，能够在不同规模的项目设计中进行使用，那么一些身在其中的行业的项目可能就可以换个思路，不知道我这样理解是否妥当？
FDD是一种模型驱动开发的软件工程，适用于敏捷开发，主要以实现功能为目标，把系统分解成功能集，每个功能又细分成具体的功能，经过团队项目的实践，对这个FDD有了一定的概念。我们变成的时候也会先把整个项目分成几部分需要实现的模块，再将这些模块细分成许多的功能，比如说发布博客与查看博客划分进同一个板块然后再分步去解决并整合，有字底向上的感觉，当然对FDD还需进一步去接触更多的知识或是项目过程来得到更好的认知。
- 问题5
第十六章16.2出现了一张技术采用生命周期图，到早期采用者会出现一个鸿沟，“大众平均值再往前一步就是‘早期采用者’那个区间，有时一个崭新的技术，推出的时机太早，它就跨不过那道沟”，如何理解？查阅了资料，“早期采用者是远见家，他们看的远，站的高，能够想到新科技产品带来的巨大影响，但这样的人又非常少，不可能直接和早期大众交互。远见家通常扮演着成了都是自己的功劳，败了拍拍屁股走人的形象。所以和实用主义者们并不是很协调。实用主义者选择接受一个新高科技产品，是要考虑它的实际价值的。因此，这两类人差异比较大，很多东西在远见家眼里前途无量，在实用主义者眼里根本就没法落地”。按照我的理解，推出的时机太早主要影响的是技术的可行性、适用性，而新产品一定要在解决实用的问题的前提下再进行推出工作才能够跨越鸿沟。这样解决的是早期采用者与早期大众的跨越，那如何让更多的一部分人能够承担早期采用者的角色呢？技术应该何时推出才能够更好地把握这个点？
严格来说这个问题对现在的我有些不太好回答，因为没有接触过很正规的产品发布过程。就拿团队项目来说，我们能够实现的可能就只有找到一些早期的用户，或者不能严格意义上被称作早期采用者而更像是测试用户，测试我们的软件有没有bug、有没有闪退的现象、有没有功能上的缺失或是需要改进的地方。可能他们到了第二天就不再关注这个app，也就不会过渡到早期采用者的阶段，因此我认为app的功能完善或是说用途新颖亦或是有较好的推广团队会让一个软件更好地收获早期采用者，还有很重要的一点，在产品发布之前一定要反复测试软件的完整性。
“做中学”
- 需求
需求阶段最大的收获就是如何更好地去做需求分析。最初认为需求而分析只需要分析软件要做什么，要实现什么功能，到项目实践的时候发现还是挺复杂的，我们按用户的需求讨论出一个功能的时候还需讨论实现的方法以及可行性再对需求做出一定的修改，总的来说需求是以用户的想法为基础，我们需要站在用户的角度去思考才能做出更好的贴切的需求分析。
- 设计
设计阶段让我熟悉了其中的一部分：原型设计。因为自己参与了原型设计的部分，所以深有感触。原型设计是把需求分析阶段的讨论出的项目用原型的方法进行展现，供用户更好的理解。如何做出比较好的原型，以及如何能够包含需求的所用供能板块，从前期的相关app借鉴到原型的制作以及后期的修改都需要投入较多的精力，尤其是后期的修改阶段，需要与组长商量如何修改界面使得UI更符合用户的需求，可以说，设计阶段除了文档的撰写最大的收获就是原型设计以及axure的使用了。
- 实现
最初的想法就是参与前端部分的工作，最初也是先花一写时间去重温android一些必要的知识点，最大的收获就是学习了Retrofit框架吧，能够很好的解决网络请求问题，也是一步步从一般的框架开始照着范例学习，印象比较深刻。
- 测试
测试阶段自己参与的可能只是界面的显示以及数据的显示的查看吧，因为Retrofit会遇到需要更新界面的问题，最初代码写完因为一直想着需要后端的数据就没有用模拟数据去测试，到最终测试的时候发现数据无法正常更新到界面上，而后也是寻求前端组长的帮助才解决。今后肯定会注意要及时测试代码的完整性。
- 发布
发布阶段的话收获就是发布前要多进行自测。我们团队在发布用户使用的版本前也进行了自测，在不同的机子上测试会发现一些机子会出现闪退等问题，然后组长也是先解决了这些问题，再发布可行的版本，但是在用户的调查中还是会反映很多的问题，证明自测的不够全面。今后在处理软件发布的时候，提高自测次数也可以很好地提升用户的体验感。
理解&心得
- 个人项目
个人项目的难度不是很大，不过最初思考正则表达式的时候还是遇到了一些问题，可能某个正则表达式无法覆盖到所有的情况。另外，在如何读取文件上也遇到了一些问题，修改到最后还是发现运行的速度不是很快，可能还有其他的方法没有考虑到。同时在不断地更新、调试的过程中学着用GitHub来存放和更新自己的代码，为今后的软件工程学习又添了一项新技能。当然，在完成作业的过程中，自己也会去查阅各种各样的资料，也是一个不断进步的过程，同时，在和大佬们的交流中也收获到了许多，认识到了自己的不足。项目难在不断的测试和优化，这是最深的体会，今后也会更加努力地完成每一个项目，尽力做到更好。
- 结对编程
结对编程的话第一次是原型的制作，第二次是具体的实现。虽然最后的成品不是很好，没有达到我自己的预期，但是总的来说还是收获挺多的。首先就是第一次与其他的同学一起合作编程，可以综合双方的优势，但同时也需要考虑到双方的知识量的问题，所以最后还是有点吃知识的亏。由于在短时间内需要学习前后端的框架，所以在使用的时候会不太容易上手，可能看懂了示例代码也不好直接写出自己想要的效果。嗯，今后还是要多学习些新知识，实践的初期对自己规划了学习路线，然后发现最终的实际情况不太好，可能只是单纯地接触了点皮毛，书到用时方恨少吧。
- 团队项目
由于之前也没有相关的项目经历，所以团队项目也是第一次体验一个团队将产品从无到有制作出来的过程。感觉团队协作的过程还是会有一些问题，比如说沟通的问题，可能团队成员之前的想法会有一定的差异有时候会难以统一，又或者表达的意思不够明确有时候会产生误会。但总体来说还是挺不错的，和团队成员之前可能没有太多的接触但是依然能够很好的进行合作，也有些不可思议。同时，在前端组长的带领下也接收了些android方面的新知识，虽然学习的过程很坎坷，但是最后运用到了代码中并且能够很好的实现也是挺不错的。还是像上面提到的那样，吃了些知识的亏，要努力获取新的知识，争取做个大腿？！靠谱的队友，完美的团队。
个人技术总结
概述：团队项目中前端需要获取后端的数据，android开发中网络请求比较频繁，可以使用Retrofit框架来简化网络请求操作，因为其网络请求的工作本质是OktHttp完成的，而Retrofit仅需负责网络请求接口的封装，可以使编程简单化。
