BUAA 软工 Week_17 个人作业-提问回顾与个人总结
| 内容 | |
|---|---|
| 这个作业属于哪个课程 | |
| 这个作业的要求在哪里 | |
| 我在这个课程的目标是 | 通过课程、编程实践、小组合作学习软件工程的基础要领，提高改善自己的编程习惯 |
| 这个作业在哪个具体方面帮助我实现目标 | 总结了本学期所学的知识 |
一、解答
1.该做单元测试的人？
第二章
在自己写完代码之后，会最熟悉自己的代码实现的逻辑，知道在编写代码时考虑的情况，对这些情况进行各种测试，在首先保证了自己所负责的部分或考虑到的情况进行充分的测试之后再交给下一阶段的人进行进一步的测试，这样有效提高代码的质量。通过和助教进行交流以及自己在团队项目中对自己的代码进行验证得知写代码的人做单元测试的必要性。
2.结对编程中的平等权利如何争取？
关于
在结对编程中，我和队友是一种互相商量讨论得到的，方案可能存在差异，但是可以对两份方案进行讨论，从优化的想法出发，大家本着相同的目标，就题论题，给出客观的计算进行对比，如果有多种优化方案，则一起实现进行比对，因此从这一点出发，只有水平上的差距没有级别上的差距。
3.敏捷开发类比爵士乐？
第五章中提到敏捷开发具有像
敏捷开发是由于目前移动设备或者网络等发展迅速，为了适应不同的人、变化的需求所需要的软件开发方法，但是因为其安全性可靠性不够所以对于一个要求高质量的工程是不适用的。
如何去衡量一个软件所需的可靠程度呢？在这个点上需要根据用户的需求来判定，比如给出指定的测试范围和正确率，一个要求很高的工程，在质检验证可能会有所侧重，或者会有需要快速得到一个效果或者功能的时候，这个可以将整个的各个部分进行拆解，可以通过单元测试和回归测试综合起来。
敏捷开发也是不断迭代的过程，不断的完善任务，适应新的条件需求或者测试需求。软件开发的过程中，需要对需求分析，写设计文档，讨论规范等步骤，敏捷中没有设计文档，代替其他软件开发中的设计文档的是“可用的软件”，通过团队合作任务我了解到，这需要根据“可用的软件”的技术实现进行任务规划分配，通过前期对“可用软件”的技术实现划分对小组成员进行任务分配，而爵士乐曲一样的即兴发挥则是针对敏捷开发过程中灵活的应对各类突发情况或者需求，灵活的完成任务，调整进度以及技术实现上的规划和相应的任务分配。
4.Ad hoc Test & Bug Bash低效率的解决办法？
第五章中的
如果说探索式测试的边界即为目前自动化测试中的盲区，而因为其探索式一次性且临时的特点会导致测试是不够系统的，且容易被丢失遗忘的，有什么办法可以把这种测试和之前的测试统一管理记录？此外，它的必要性如何衡量，因为需要更多的对代码的理解和对数据测试范围等的理解，如果投入测试的时间和测试出来的Bug的收益不高呢？目前对于Ad hoc Test的收集管理的办法就是对软件的反馈系统进行完善，并通过专门的维护的人员对bug收集并及时修正，在个人作业寻找QQ音乐和网易云音乐的bug的时候，可以比较完善的表达这个Bug的复现过程，并且将其反馈到这两个软件专门的收集问题的地方，还有就是建立软件使用反馈群，可以作为前期软件用户直接讨论和反馈软件体验的地方，除此之外目前没有搜到合适的管理Ad hoc Test的方法，另一个由此提出的问题是当普通用户无法描述清楚bug的复现步骤和环境时，只是靠一个反馈软件对bug的位置进行一个说明，工程师该如何针对他们的形容进行修正。
后文的小强扫荡也面临着相似的问题，如何在大扫荡的时候提高bug检测的效率，即不要有多针对一个问题的不同的测试，很多错误点其实只是一个Bug所导致的，大家可以靠随时进行交流，程序员及时的找到错误的原因并给出错误样例的模式，让大家避开这个问题或者及时修正，减少同质bug的出现。
5.平衡点在哪：及时解决客户的问题和及时修改软件的问题
在第四章
用户的需求可能并不能专业、客观或者严格的定义高质量软件，当定义的权力落到了开发者手上时，如何去衡量所谓“高质量”的软件？我们首先要和用户规定好这个高质量的标准，可以是一个具体的测试样例池，也可以是一个需要达到的时间要求，如果我们在当前版本没有达到一个弱的要求，我们需要告知用户，并且继续对此版本进行迭代开发。能够做到“全面质量管理”无疑是一个严谨准确率高的软件，只是因为在敏捷开发中，速度的权重大于质量，追求的是“可用”，所谓欲速则不达，因此敏捷开发也不能被用在可靠性要求高的地方。这个平衡点没有一个严谨的规范标准，一切是根据需要发布的时间节点和用户需求进行调整，这也是敏捷开发的灵活性所在，因此这也要求我们不停的去完善。
6.放到屁股后面盲拧VS魔方贴纸
在第9章，作者举了
魔方本身的用意是计算最少的还原的步骤，并且通过熟练的手法将其还原。作者在文中批判为了技术创新而“用屁股对着目标用户”这一概念，但是为了吸引市场，用一些花里胡哨的包装和噱头，去迎合目标用户，但是通过和同学进行讨论我们认为这只是一个暂时的成功，市场上如果通过这种空架子花架子进行竞争，消费者的激情总有被消磨殆尽的时候，比如现在某款游戏，通过不断的推出新的皮肤、比赛，而不是从游戏的策略、玩法这些根本处进行创新，导致用户的体验感从最初的猎奇到觉得没意思。软件开发的时候，如果选择创新，是选择提高自身软件功能的创新，哪怕没有被消费者当下看不到但是通过不断的提高是能够长久的吸引用户的。
7.绩效管理的尺？
在
这个其实还是无法进行衡量，在所处的团队当中，如果有一个说什么是什么的管理者，并且团队信服他或者直接为其工作，那么由团队各个成员都认同的情况下可以交给他进行评定，如果没有，即团队内部地位几乎平等，那么这个绩效管理从某种意义上是一个团队之间的协议，要求在团队在开工之前进行全面的商议，事后再进行分析，团队内部对各个组员进行评估。
1.如何推进团队之间的沟通
在团队合作中，我们组组员之间的总体联系不够密切，组员对于整个软件的规划没有一直跟进了解，态度也不够积极，不知道这种情况该如何促进团队之间的沟通。
三、实践中学习到的内容
1.需求
首先是学会了NABCD的需求分析过程，并且在需求分析阶段我学会了通过问卷调查去调研软件，在问卷调查中我们需要通过普通用户对于软件的比较主观的体验和评价当中去寻找他们的需求，他们的描述不是很准确的，更多是一种模糊的形容，所以在这个提取是要基于我们对这类软件有一个详细的了解，对大家的真实需求通过比较客观的更加专业的方式描述出来。
2.设计
通过文字为主去记录，根据需求和现实所需的条件筛选功能，设计相应的功能，并且通过图形去构造，从功能出发去设计软件相应的模块，再把各个模块相结合成一个完整功能的软件。在最后分配任务和接口的时候通过伪代码和相应的注释去规范定义。
3.实现
团队开发的过程中可以将任务分配成若干小模块，通过燃尽图对项目进度进行管理。同时一个小组在合作的过程中一定要有充分的交流，随时通告疑问、进度、需求。我也了解了一个包含一组工具、库和服务，可以实现用 JavaScript 构建 Android 和 iOS 的原生应用Expo 。
4.测试
根据用户需求、类型和软件功能设计测试矩阵，按照矩阵进行全面的测试，但是不同组合的重要性是不一样的。
5.发布
通过多个版本的迭代开发，将新的功能、通过了测试的功能逐步发布出来，这样可以保证一个软件的可靠性，但是同时又在版本不断的更新当中使用户获得更好的功能体验。
6.维护
在软件发布之后，不同的用户会有不同的想法、意见和建议，通过设立用户群、建立反馈站获取他们的反馈并不断的更新，对原有细节进行调节，修复bug。
三、心得
结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得
在个人项目的时候我了解到了持续集成、持续交付、持续部署这些可以辅助自动集中代码，自动化了从提交再到测试和发布产品过程，更快获取用户反馈并进行迭代的工具，他们避免了人工合并检查整个系统的错误，它依赖于测试套件和自动化测试执行，有助于降低总体构建成本，并鼓励频繁迭代构建，在周期的早期发现缺陷。我认为这些自动化工具对于开发工作来说是非常重要的，通过部署这些自动化工具减少额外的管理和部署开销。在结队编程过程中，通过和同伴的合作，可以了解到其他的编程习惯和优点，是使我受益很多的，并且需要和队友进行协商，针对问题分析讨论，一起追求相同的目标。同时在这次结对项目中还直接实践了动态库以及封装核心的做法。在团队项目中我了解到了expo这一开发工具，也通过一些推广和调查对软件的功能进行设计。
