[软工顶级理解组] Beta阶段项目展示

团队成员

郭骏（https://www.cnblogs.com/sharinka0715/）

普通程序员预备一枚。喜欢编程，想要做软件。担任过计组助教，进行过一段时间的网页后端开发。自己没事也喜欢鼓捣一些无聊的小脚本、小程序。

希望在软件工程这门课上能够做出自己未曾实现过的级别的软件，相信团队的力量。

目前掌握技术：C/C++， Java， Python控制台编程，C# Winform开发，Django后端开发，（一定程度上的）Linux服务器维护

职位：PM

李嘉铖（https://www.cnblogs.com/bakahentai/）

什么都会一点但是什么都不精通，非ddl玩家，喜欢提前把任务做完。

希望在软件工程的项目上可以通过担任测试的岗位，学习其他人的代码风格和编程思想，提高自己的编程能力、设计测试用例的能力、执行自动化测试的能力，提高项目软件的质量。

目前掌握技术：C/C++， Java， Swift， Ruby和基础Rails框架， Python控制台编程

职位：后端开发

单彦博（https://www.cnblogs.com/shanyanbo/）

精通C语言，能熟练使用java，python，c++等语言，作为组长组织过无线网络系统项目的编写和集成，对团队工作有一定经验。本学期是我第二次参加团队项目，希望能有更多收获。

目前掌握技术：C， C++， Java， Python， Ruby on Rails.

职位：前端开发

胡彬彬（https://www.cnblogs.com/ilwf/）

能够熟练使用C，C++，python，java等语言，曾做过数据库课设，对于MySQL有一定的了解，自己也比较喜欢计算机图形学相关知识。在这次想进行前后端开发。

目前掌握技术：C，C++，Java，Python，MySQL

职位：后端

张艺璇（https://www.cnblogs.com/zhyixuan/）

个人属于ddl玩家，不过希望且愿意接受push。上学期安卓课上做过一点客户端开发。在这次软工中希望和大家一起做意思的项目，学习团队合作的经验。在这次团队项目中想做前端或者测试的工作。

目前掌握技术：C/C++， Java， python，安卓客户端开发

职位：前端开发

杜博玮（https://www.cnblogs.com/cuogeihong/）

C/C++，Java，Python均有所涉及，会用其中一部分内容。写代码时经常上网查函数定义。

我希望在这次软件工程的项目中担任前端或者后端的开发。有了PM和测试人员的存在，在团队中进行开发工作可以使我得到更多的收获。

目前掌握技术：C/C++，Java，Python，MySQL

职位：爬虫开发

孙旭东（https://www.cnblogs.com/ring-of-sun/）

来自高工大三计算机专业的老笨比，会使用python，C++，Java等编程语言，具有爱运动和死肥宅的双重属性，喜欢社交，为人友善，希望能在软件工程这门课上学到新知识，交到新朋友。

职位：前端开发

软件介绍

项目简介

这里是航胥，一款更懂你的教务助手。

我们团队做的是一款集课表查询、空教室查询、成绩查询、课程评价、校历查询、课程中心DDL查询等教务服务为一体的北航教务助手APP。

预期典型用户

• 北航普通学生

  用户信息	用户情况
  姓名	吉良吉影
  用户身份	北航一位普普通通的学生党
  用户动机	希望能有一个美观、迅速且无需手动导入的软件来查询课表、空教室、成绩等信息
  用户困难	教务系统需要电脑操作，且界面透露出过时的气息，手机端的北航小程序运行速度慢
  典型场景	通过手机查询自己的课表等信息

• 经常忘记DDL的冒失同学

  用户信息	用户情况
  姓名	广濑康一
  用户身份	对日期和DDL不敏感的同学
  用户动机	希望能有一款产品时刻查看、提醒自己作业DDL，且无需手动导入
  用户困难	课程中心没有手机相关的适配，且电脑端访问课程中心比较麻烦
  典型场景	通过手机端直接收到了作业DDL的截止信息，立马投入工作

• 对定制化有要求的同学

  用户信息	用户情况
  姓名	岸边露伴
  用户身份	对软件的自定义有一定偏好的同学
  用户动机	希望教务软件能够按照自己的需求进行一定的定制
  用户困难	课程中心没有手机相关的适配，且电脑端访问课程中心比较麻烦
  典型场景	上课周将主界面设置为课表，考试周结束后将主界面自定义为成绩

• 想评价课程的同学

  用户信息	用户情况
  姓名	东方仗助
  用户身份	很想了解课程评价，以及参与评价的同学
  用户动机	希望能有一个有学校开设课程信息的软件，供大家分享不同课程的口碑
  用户困难	目前市面上没有这种东西，只能靠大家在微信群口口相传
  典型场景	通过航胥来查询课程评价

功能描述

预期目标用户数

• 发布一周内注册用户数：400人
• 发布一周内主动查询次数：4000次

下面是实际使用人数统计。因为我们的推广方式是朋友圈等社交网络，所以在Alpha阶段，组员社交圈内的用户数量已经趋于饱和。Beta阶段使用朋友圈和大班群推广无济于事。

为了进一步扩宽用户，我们组员尽力发给了所有认识的外系的同学，包括但不限于1系、2系、3系、4系、17系、21系、高等理工学院、高研院等。最终，我们的用户数定格在此表。

用户反馈

在Beta阶段，我们设置了用户反馈页面，用户可以直接在个人中心—用户反馈页面将对软件的意见反馈到服务器后台。如果是BUG方面的反馈，我们会及时进行修复。其他方面的反馈如图所示：

团队管理

分工协作

我们团队没有将开发和测试人员分开，而是让每部分的开发人员兼任测试，这是考虑到我们需要开发的板块本身就较多，且功能之间沟通性强，可以由不同的开发部分之间进行互相测试。

团队分工如下：

在近一个月的开发测试过程中，我们这套团队制度的优点和不足都有所体现，也让我们吸取了不少的经验教训。

• 优点：开发效率高，部门之间通过接口交流，耦合度低，测试出bug时能够很快定位到bug所在。
• 缺点：由于缺乏专门的测试人员，只是在每个功能上线前进行本地测试，难以产出很详尽的测试数据。不过在Beta阶段项目框架完成，开发技术趋于熟练之后，Alpha阶段在测试阶段爆出大量BUG的现象不复存在。这代表着我们团队的磨合更上了一层楼。

项目管理

• Repository

  将前端和后端的仓库分开，分别维护不同语言的代码，以不同的标准进行开发。

• Pull Request & Code Review

  所有代码签入使用PR进行，而所有PR需要经过负责人的Review。这样可以有效避免提交冲突，且代码复审会减少设计阶段出现的bug数量。

• Issue

  我们项目的所有任务放在Issue中，每个Issue都绑定着对应的开发人员，且有PR的Issue都会和PR绑定。Issue的性质和工作量标签可以帮助我们更好的进行项目的时间管理，在计算贡献分时也有更加具体的数据。

• Code Style

  前端遵循Dart语言的一般代码规范。由于Android Studio没有合适的适配Dart语言的Checkstyle配置文件，所以我们主要靠AS自带的Reformat功能对缩进换行等进行限制，而变量名、程序结构等其他风格由组员自行维护。

  后端和爬虫使用Python，我们使用pylint和pylint-django第三方包对代码进行静态检查，并配置了适合于我们项目的.pylintrc配置文件。目前提交到主分支中的每一个commit都要求通过代码风格检查。

• GitHub Action

  后端和爬虫的代码中设置了GitHub的Action，每次commit或merge时自动触发。Action会检查代码风格，并运行Django单元测试。如果有一项不通过，则PR不会允许通过，需要重复修改。

• Documentation

  除了在仓库的主目录下编写合适长度的README.md文件，我们项目的所有文档维护在GitHub Wiki中。Wiki文档中包括编译运行指导、接口规格说明、错误处理说明、更新日志等详细信息。

取舍平衡

我们想做的事情有很多，在Beta阶段我们依然无法一一完成。我们在纠结中，选出了以下几个功能作为优先开发项：

• 用户呼声较高的内容

  校历查询、意见栏、iOS版（因为苹果开发者账号688一年被劝退）

• 效率问题

  爬虫彻底重构——从selenium换成requests包，内存占用大大降低，并且登录速度大大提升。所使用的爬虫服务器数目由4个降低到2个。

• “杀手功能”

  课程评价——我们项目规划时的核心，也是和DDLKiller项目组试图区分开的功能

• 不得不放弃的功能

  考期考表查询，因为一直到发布阶段才出数据，所以在这之前爬虫没法做，我们也无法实现。

  博雅课程功能，因为本学期博雅叫停，无法测试，所以我们没有实现相关功能。

代码管理

程序测试

Alpha阶段单元测试：测试用例47个，测试覆盖率78%。

Beta阶段单元测试：测试用例94个，测试覆盖率88%。

使用django-coverage工具测试覆盖率，我们录制了单元测试的视频以供播放。

前端没有进行单元测试，因为Flutter框架不同于原生Android，没有合适的覆盖率插件来帮助我们进行测试。且前端本身逻辑较为简单，常规的用户使用已经足够测出许多错误。所以前端的测试通过在测试阶段有限分发我们的apk安装包来进行。

代码规范

Alpha阶段，我们没有对代码规范提出过多的要求。Beta阶段，我们吸取了之前的教训，有了一定的进步。

前端遵循Dart语言的一般代码规范。由于Android Studio没有合适的适配Dart语言的Checkstyle配置文件，所以我们主要靠AS自带的Reformat功能对缩进换行等进行限制，而变量名、程序结构等其他风格由组员自行维护。

后端和爬虫使用Python，我们使用pylint和pylint-django第三方包对代码进行静态检查，并配置了适合于我们项目的.pylintrc配置文件。代码风格检查在GitHub平台上使用Action功能进行了自动化部署，每个commit都需要通过代码风格检查。

为了改进我们Alpha阶段堪称混乱的代码风格，我们在Beta阶段伊始引入pylint时，将一条条报错suppress的过程，工程量几近重构。但是最后做出来的成果是值得的，如今的代码非常整齐清爽，格式整齐。

文档撰写

在之前已经提过。除了在仓库的主目录下编写合适长度的README.md文件，我们项目的所有文档维护在GitHub Wiki中。Wiki文档中包括编译运行指导、接口规格说明、错误处理说明、更新日志等详细信息。

继续开发指导性

如果有下一届同学接手我们的项目，并且具备相关框架的基础知识，是能够很容易上手我们的项目的。原因如下：

• 我们使用的是现成的框架，启动方式是现有框架的常见启动方式。
• 我们的文档中有对新手较为友好的编译指导说明，可以帮助用户上手我们的项目。
• 我们的文档中有详细的功能和结构说明，代码中也有足够的注释来指导新人上手。
• 抛弃selenium后，我们的依赖安装过程几乎不存在难点，只需要用pip安装requirements.txt即可上手。

用户沟通

需求分析

从立项开始调研到的需求“做一款像同袍一样的软件就好”，我们在Alpha阶段靠着方便的DDL查询功能，吸引到了200位用户，也展现出了我们能和同袍、北航小程序等不一样，我们有我们的优势。我们更快捷、功能更多样、迭代开发更及时、界面更丑。

但Alpha阶段收到的用户反馈较少，依然没有什么新功能，所以我们只能沿着我们先前规划的道路走。通过之前提到过的一番取舍之后，我们最终产出了现在的项目。

数据分析

我们对从用户收集到的数据，画出了用户数量随时间变化的折线图。

可以看到，因为我们在发布的一周中每天都在推广，所以我们的数据增长较为平稳。但总的来说，没有达到我们的预期400人。其主要原因有：

• 没有像预期一样开发出iOS版本，导致没有争取到占比不小的iOS用户。
• 考期阶段，大家对课表查询、课程评价等的需求大大降低，而可能有高需求的内容（比如考表查询等）我们并没能实现。

软件发布

发布文档：（博客发布公告）

https://www.cnblogs.com/se2020djlj/p/13034817.html

发布位置：大班群，朋友圈，委托进行“口口相传”。

用户反馈截屏：

最终燃尽图：

（后端最后一个是PM的贡献分统计）

我们认为，燃尽图较为真实的反映了我们项目的状态，项目如同燃尽图一样平稳推进。因为燃尽图绑定了issue，而issue绑定了PR，所以燃尽图上的每一个节点，都是我们的代码。

前端的曲线相较于预测实线偏上，原因是当时前端存在部分技术难题，加上大家计网实验比较忙，卡了比较久的时间，在之后催更一波进度之后渐渐好转。

团队贡献

我们的评分思路遵循以下原则：

• 不同开发部门之间的代码行数、PR数目等不能直接比较。
• 综合考虑Bug数开发issue数目。
• 不对开发完成的时间做出奖励。

下面是Beta阶段个人代码提交量。代码行数使用git log输出，等于增加行数减去删除行数。只计算5月12日之后的commit。

功能展示

在答辩时使用模拟器演示。

我们Beta阶段的特色功能——校历和课程评价，是我们着重需要介绍的部分。

总结

所学到的

• 团队的力量是伟大的，众人拾柴火焰高，可以做到许多难以想象的事情。
• 庞大的任务可以分解为多个小任务，逐个击破。
• 软件质量、运行速度、开发时间很难做到三者兼优，取舍和得失也是敏捷开发的魅力。
• 给北航学子一个DDL，真的可以创造奇迹。
• 无脑撸代码不是唯一，代码规范、项目管理、合理规划、充分调研都是软工不可或缺的部分，磨刀不误砍柴工。

课程建议

• 做推广、发布是一个不小的门槛，用户群体越广阔的项目反倒更对推广无所适从。如果没有用户量的要求，课程内是否会有更多的组选择开发更有意思的项目呢？
• 如果课程组认可，我们的软件是否可以交由下一届继续开发？