【BUAA软件工程】提问回顾与个人总结

[BUAA软工]提问回顾与个人总结

项目	内容
这个作业属于哪个课程？	北航软工
这个作业的要求在哪里？	提问回顾与个人总结
我在这个课程的目标是？	学习高效严谨的软件工程开发过程，建立团队意识
这个作业在哪个具体方面帮助我实现目标	回顾总结本学期学到的一些知识

之前的阅读作业，点这里。

请尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。

1.软件开发中的风险控制？

现代软件开发中难免要用到一些第三方开发的开源库，比如python，js等语言，这些库为我们的开发带来便利的同时，也为我们带来了安全隐患，因为这些库的质量是我们无法保证的。比如18年圣诞节发生的阿里的开源UI框架Ant Design中的彩蛋事件。那么，在成熟的商业公司的开发中，是怎样看待和使用这些第三方库的？

在个人或者小型团体的项目中，自己制造所有轮子是不现实的。经过一个学期的实践，我认为使用第三方库是必须的，但是需要尽量保证库的权威性，使用那些经过众多项目实践测试过的开源库。越大的开源项目，代码审核，规范和权限管理反而越严格。针对问题的反馈和解读更加丰富。反而是小型开源项目的质量堪忧，针对问题的讨论及可以获得的帮助也较少。

2.单元测试的随机性，复杂性，如何建立合适的断言

测试已经是软件开发中必不可少的一个步骤，我们确实是有必要对程序进行全面严谨的单元测试。但是以我们本次的结对开发任务为例，我们提供一个找到最长单词链的接口。测试的时候，难道我们就只测试返回的长度而不去考虑整个链的组成么？尤其是我们将测试集的单词量级定为10000时，如何构造一个合适的数据集？人工构造耗时耗力。

在实际的开发中，程序猿为了满足测试的随机性还是有一套完整的工具的。比如针对android开发来说，有一套叫做monkey的脚本，就是针对程序进行随机化测试的。他会捕捉界面上的元素，进行随机模拟输入，点击，滑动等操作，成千上万次的模拟达到随机性的压力测试。但是针对复杂性来说，我并没有在实践中找到很好的构造方法。只能依赖项目的积累。从一开始就做好单元测试，满足从下到上的完整测试。

3.代码的命名规范

书中好像对代码的简洁性要求比较高，例如它给出这样的例子，”表示全年假日的列表“不用写arraylistOfHolidays,可以直接写作holidays，我感觉这个与我的开发经验是不符的，按照我的写法，应该会被命名为holidaysList，这样可以看出变量的数据类型。

在实际的开发中，只要满足团队的代码规范就好。代码面对的下一位使用者是开发伙伴，以满足开发伙伴的易读性为主。在java和c++这种静态语言来说，两种命名规范都是合理的。比如我们的android代码风格检查插件规定方法中变量的声明和第一次使用之间间隔不能超过四行。声明往往是伴随着变量类型的，这样其实能体现是一个容器类就好。但是在python这种动态语言来说，我更偏好名字有一个*list或者*set的后缀。

4.代码的验收测试

越长的代码越不可能没有bug，我们平时几百行的程序当然可以做到完成所有测试并改正找到的bug，像一些商业软件最后的验收会不会有妥协。是一定要做到测试中的零bug，还是对bug分类，不影响核心功能的bug如果工期紧或者代价大就不改了？

开发中不可避免地伴随着妥协。具体的要求以团队事先定义好的说明书和文档为准。必要时，开发者甚至能联合起来修改文档。通常我们定义的出口条件是满足所有实现定义好的功能以及没有严重影响功能和使用体验的bug。做了半个多学期的测试，终于发现测试是de不完的！！！

5.需求引导与变更

我之前用的一款手机APP突然从左右滑动翻页，换到了上下滑动自动加载。我不太习惯，用户社区里也有很多反对的声音。但是几个更新版本下来，APP并没有回滚的意思。我们在开发中遇到这种事应该怎么决定，比如处于技术或者美观的考虑需要改正用户的习惯操作时，我们应该怎么抉择？

这个需要测试。以分发问卷的方法询问用户对两种方式的意见。然后综合改变后的收益来权衡。还是以我问题中的这个app举例，虽然社区内反对声音很多，但是经过使用我发现企业在页面的最下方加上了广告，这样一来上下滑动就比左右滑动增加了广告的曝光率，可能会增加企业的收入。收入和短期的客户满意度（长期改变会造成新的使用习惯）在这种场景下组成了博弈。在我们的课程开发中，参与博弈的大概是程序猿的自我满足😂与用户满意度。

请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”

• 需求
  • 落在纸面上，没有调查就没有发言权。
• 设计
  • 结合成员的能力，切忌好高骛远。无法实现的设计就是没有设计。
• 实现
  • 学会使用搜索引擎。明白“你遇到过的问题肯定之前有人遇到过”。好好利用框架给出的demo。
• 测试
  • 不是只有单元测试才叫测试。测试是多种多样的，压力测试，场景测试，兼容性测试都体现整个项目的完整性。
• 发布
  • 预留出足够的时间。除了自己完全控制的部分，任何涉及多方的过程都有可能出现意外。
• 维护
  • 借助工具的力量，使用工具来监控而不是依靠用户的反馈。

结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。

我是团队中的测试。这门课是第一门面对工程的课程。之前的课程都是一个针对算法的函数，一个实现功能的类文件或者一个能够运行的小项目。目标明确，路径清晰，简单粗暴，只管输出。这门课程却是从开始前的计划到实现到给出结果都是自由的。你需要调研需求写出规划书，寻找适合的框架，安排成员以合适的进度实现功能，规定接口，将代码合并，完成测试，打包发布，后期维护，撰写文档。这一套完整地做下来，程序猿们就知道什么是社会的铁拳了，明白什么是工程。