[I.3] 个人作业：结课总结

[21373122-张觉]

项目	内容
这个作业属于哪个课程	2024年北航敏捷软件工程社区-CSDN社区云
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	了解敏捷开发，并通过团队写作的方式开发一款具体的产品
这个作业在哪个具体方面帮助我实现目标	总结与反思

一、问题 回答&思考

链接：https://bbs.csdn.net/topics/618189987?spm=1001.2014.3001.6377

• Q1单元测试由作者来构建是否会导致测试覆盖不全(p25）

  虽然单元测试由作者构建可能会出现作者本身理解错误的问题，但是，当进入实际开发的时候发现，每个作者往往都会负责一个独立的模块，而最清楚这个模块各项具体功能的反而就是作者本身。大部分bug都是出现在本身需求的实现上，事实上作者本身进行单元测试就可以找出大部分的bug，剩下的bug可以在后续的测试中找出。

• Q2到底什么时候泛化叫”过早扩大化/泛化/优化“

  个人认为这个问题依旧是比较开放的问题。要想解决这个问题，首先是软件功能的划分前期一定要好，如果之后添加功能的时候不影响之前的功能组件划分，那么就不会出现过早泛化的问题。当遇到问题的时候，可以考虑逐步进行重构。

  我在开发时也遇到了一些问题，其中一个部分就是在app中嵌入一个使用java书写的插件，这个插件需要使用特定的cookie进行请求，为用户自动拉取SPOC平台上用户的数据。我们的app本身是一个网页端app，在使用其它cookie访问的时候会出现问题。这个插件的出现是为了通过调用Android本地网络通信的方法来绕过这个问题。在Alpha阶段，这个插件只需要向一个url发起请求，所以这个请求的返回值都是在插件中去解析的。后来Beta阶段，这个插件可能需要向不同的url发起请求，这时候我就发现之前设计的不合理了，这个插件本身只是为了绕过cookie，那么请求返回体的解析应该放在插件之外，插件将返回体直接交给调用者进行处理。

• Q3怎么衡量易用性测试的结果？(p286)

  我们使用开发者测试+内测用户进行易用性测试，然后再发布正式版本。我发现对于易用性测试的主要目标不是去衡量一个结果，而是发现有问题的地方然后进行修复。只要将其修复为“易用”状态即可

• Q4结对编程的效果疑问(p80)

  个人认为，结对编程依然是一种应用面较窄的方式。它对于两个程序员的要求都非常高，两个人必须每个人都非常熟悉正在使用的编程语言，才能保证处在同样的一个思维线上，并且保证两人一起写大于两人分开写。感觉我们的结对编程效果并不是特别好，而且我们主要的时间是花在学习工具上了。

• Q5渐进交付的流程可能出现的问题(p104)

  在之前的问题中，我担心新的需求可能会影响软件之前的核心架构。不过在实际的开发中，我们并没有遇到这个问题。这是因为我们的核心需求一直没太变动，我们的需求面广泛但是互相之间的依赖很低。不过，根据我的观察，市场上大部分的软件，新需求和旧需求不会出现本质上的冲突，因此新的需求影响之前核心架构的风险应当还是比较低的。

• Q6 新问题：Code review怎样才能发挥最好的效果？

  在开发中，我们对dev分支进行了保护，任何尝试对于dev分支的PR都需要至少一位审核者。然而，我们发现审核代码是一件非常困难的事情，特别是当进行改动的时候，可能涉及数个文件，除了作者谁也不是很清楚其中的各类风险（事实上作者也未必知道），大部分审核都是无效的，也就是无法发现里面潜在的问题。所以感觉我们在这一方面不是很清楚应当怎么做？

学习的知识点

• 需求

  要广泛地听取意见，并找到其中可行的、广泛存在的需求。实现难度过大的需求应当被及时地排除。

• 设计

  设计阶段要准确地进行功能的分割，将其分成子模块分别交给不同的人。

• 实现

  要规范代码风格！我们的产品总共四个前端，每个都是野路子，导致代码风格的巨大差异，在Alpha阶段造成了一些不必要的麻烦。务必要注意安全性，包括xss攻击等。

• 测试

  我们团队倾向于边实现边测试，这是因为我们实现产品的功能之间依赖度很低，上线一个新功能就可以直接测试了。

• 发布

  我们部署了CI/CD，可以持续交付网页端，并在每个稳定的版本发布APP。在大部分情况下不会影响用户的使用

• 维护

  持续收集用户的反馈，初始发布的时候开发人员要随时做好修复恶性bug的准备。

心得

一个成功的项目，必须拥有一个高效的团队。我所在的团队是BugNotFound团队，我们开发的项目是伴航。我认为我们的项目是一个非常成功的项目，首先第一个原因是我们每个人都非常尽职尽责，没有摆烂仔，大家都一心为项目贡献自己的力量，因此，虽然我们遇到了很多问题，但还是解决了。第二条原因，就是对于技术难度的评估，并保证技术难度在可控范围内。我在我们团队担任架构师的职责，决定了电脑网页端+手机网页端+手机app的目标以及使用的前后端架构。我们的目标是一个类似于BBS的项目，因此技术路线基本都比较成熟。虽然也遇到了跨域、xss等问题，但还是被解决了。App端拥有的功能比网页端更加丰富，也集中了大部分的技术难题。我们使用Cordova框架将网页打包为App，但这会拥有一些局限。在工具箱SPOC作业提醒部分，我成功使用Cordova插件的方式，绕过浏览器限制，使用用户提供的cookie爬取到了SPOC的数据，这是成功的技术突破。但与此同时，也有一些技术问题是没有解决的。在工具箱-博雅提醒部分，原先的计划是让App在后台运行，到特定时间后，使用用户cookie自动访问博雅平台并自动抢课。但是我没想到博雅平台的所有请求和响应都是加密的，js也是经过混淆的，搞了两天也没有爬下来。与此同时，让app不被杀后台也是个很大的问题。最后这俩问题都没解决，但是我们通过另一种方式：chromedriver在服务器通过模拟点击的方式爬取博雅相关数据，并在用户手机上进行相关呈现，最后自动抢课的功能就被砍掉了，只保留高级搜索的功能。总而言之，给我们的启示是：1、遇到的技术难题永远比你预想的多。2、如果一个技术难题不确定是否能突破，最好不要让其影响核心功能，并保证有替代方案。