[T.12] 团队项目:Alpha 阶段项目展示
校易咕: 北航校园二手交易平台
项目与团队亮点
一、团队成员与分工
团队构成
团队由 7 名成员组成,共有 2 名后端成员(刘鸣翔、赵楠),3 名前端成员(张昊博、刘鸣翔、仇志轩),1 名部署(石伊聪),1 名测试(夏经纬),2 名PM(刘鸣翔、池柏诚)
项目管理
采用 GitHub 进行代码管理,前端后端分成两个独立的仓库开发。前端后端都使用 issues 标记当前任务并生成相应的燃尽图。
后端 issues 与燃尽图:
前端 issues 与燃尽图:
由于前端的首页与帖子详情等关键部分存在样式等问题需要多次打磨,因此前端进展比预期慢。
到目前为止前后端的与开发任务相关的所有 issue 均已完成关闭。
接口文档
开发过程中使用 postman 充当前后端接口文档,相较于传统的文档式接口可以做到实时更新、快速验证、记录修改历史。在3周的开发流程中,后端在第一周将基本框架完成,因此在前端开发时可以充分展现 postman 接口与测试一体的优点。
团队例会
在开发过程中,团队共计开展了 20 次例会,其中 19 次为线下会议,共计58人次参会。例会采用了类似于小组会议的方式,只召集当前具有开发或其他任务的同学参加。这样的小型会议提高了会议上的有效交流时间占比,也节约了开发团队其他成员的时间。
二、典型用户场景
身份 | 二手交易大王 |
---|---|
使用动机(场景) | 快速出售本学期用过的课本与笔记回血 |
用户要求 | 商品曝光率高、交易流程快、方便快捷 |
满足场景的方式:
- 多次交易的用户更加值得被信赖,推荐系统推荐其帖子快速提升曝光率
- 公式化发帖并上传图片,方便快捷
- 支持用户私聊,可以平台内部快速协商
- 可以根据订单确认双方共识,避免潜在的误解
身份 | 偶尔使用者 |
---|---|
使用动机(场景) | 四六级考试在即,希望购买一本单词书,且希望当面交易 |
用户要求 | 精准搜索目标商品、确认卖家信用、操作简单 |
满足场景的方式:
- 支持发布求物帖,方便征集所需物品
- 支持使用关键字或者 tag 检索售物帖,快速查找是否有人正在售卖相似物品
- 点击用户头像即可查看用户征信信息,方便查证对方信用
身份 | 二手小白 |
---|---|
使用动机(场景) | 避免被坑,安全完成第一次交易 |
用户要求 | 清晰的交易指引、了解卖家信用情况 |
满足场景的方式:
- 帖子搜索、用户交流流程参考了咸鱼等平台,本身具备简洁与易上手的特点。如果用户先前使用过类似平台则可以容易的在本平台上完成交易。
- 支持查看用户信用,可以选择信用高的用户来保证第一次交易体验
- 订单全流程存在文字引导,按照引导即可完成订单。如果遇到欺诈等行为还可以遵照指引发起投诉
三、杀手功能
校易咕的定位是针对北航校内的二手交易平台,其目的是帮助同学们更好的利用校内资源。因此,本产品的主要竞品并非咸鱼等主流平台,而主要是与校内二手群(主要)以及其他校内交易平台竞争用户。
一、推荐系统
推荐系统主要根据 tag 进行推荐。通过点击帖子,完成的订单等历史信息,综合“热度”、“关注度”、“信任度”等多角度得出推荐结果。
-
热度主要考察当前商品是否是普遍受欢迎的。如果一件商品被大多数用户喜欢,那么对于某一个用户来说,其喜欢这个商品的可能性会更高。通过热度推荐还可以探索用户兴趣,避免推荐内容过于单一。
-
关注度主要考察某一个用户对于不同商品感兴趣的情况。系统会根据该用户的历史信息来推荐用户过去多次浏览的物品,实现个性化的投其所好。
-
信任度关注于用户与用户的关系。如果两名用户曾经交易过,那么他们再次交易时可能会更加容易融洽。对应的,如果两名用户曾经发生过纠纷,那么就不应该推荐对方的帖子。换一种角度来说,如果两名用户多次交易,那么他们之间可能会有一种共性特征(比如同一个学院、都喜欢羽毛球等),推荐对方的帖子更可能实现投其所好。
推荐系统对三种指标随机加权排序并得到最终结果。这样推荐系统可以综合个性与共性,并且可以产生具有随机性的结果。与校内二手群相比,推荐系统可以让用户在大量冗余的消息中解放,帮助用户便捷的发掘/寻找自己感兴趣的商品。
二、征信系统
完成订单、收到点赞、发起/遭到投诉等行为都会影响用户的信用分数,系统会自动记录并计算。
用户可以在自己的个人信息模块中查看自己的过往交易经历与当前信用情况
可以在多个场景下方便的查看别人的信用情况
与校内二手群相比,征信系统让每个人的信用记录变得更加透明。交易大王可以通过刷高信用分来快速收获信任,新人也可以通过查看信用分获取在微信群中无法得到的对方的信息,大大方便了积极交易的进行。
四、软件工程质量
项目文档
项目在开展的过程中为了方便后端成员理解数据库设计,制作了一张简易的 ER 图。
此外,为了在团队成员形成关于项目功能的共识,还有一张流程图介绍了二手交易的业务逻辑。
除此之外,对于一些较为复杂的系统(比如推荐系统、征信系统),有一份专门的文档描述其设计思路与一些实现细节。
用户信息安全
- 使用 https 实现报文加密传输,防止密码等信息在传输过程中泄露
- 后端对用户密码等敏感信息进行加密存储
软件测试
-
单元测试
后端使用 django 内置的单元测试框架进行单元测试,使用 coverage 包统计测试覆盖率。后端对大部分的接口编写了单元测试,最终单元测试覆盖率达到了95%
-
压力测试
使用Artillery针对登录、聊天、搜索三大主要可能存在的负载场景进行了压力测试。高请求速率下,成功响应数多,表明系统在正常负载下运行稳定。
在长时中负载情境下,平均响应时间和中位数响应时间均较低,95 百分位和 99 百分位响应时间也均在可接受范围内,表明系统响应迅速。出现少量 ECONNREFUSED 错误,可能是由于服务器资源接近饱和或网络问题导致个别连接被拒绝,但对整体性能影响不大。
在短时高负载情境下,请求速率达到 368/sec,表明系统在高负载下仍能高效处理请求。平均响应时间和中位数响应时间均较低,95 百分位和 99 百分位响应时间也均在可接受范围内,表明系统响应迅速且稳定。所有请求均成功,表明系统在该阶段运行稳定,没有出现连接错误或内部服务器错误。
项目与团队总结
团队成员博客地址
团队贡献分
我们团队的贡献分按照成员的实际工作量进行分配,不同分工的工作量分配占比如下:
后端: 30%
前端: 30%
设计与管理: 15% (其中,博客作业占 3% )
参与例会: 5%
测试: 12% (其中,后端单元测试占 4% )
部署: 8%
团队成员的贡献分为:
名字 | 角色 | 团队贡献分 | 具体贡献 |
---|---|---|---|
刘鸣翔 | PM, 前端, 后端 | (后端)20% + (前端)(2348/2590 * 0.5 * 30% = 13.6%) + (设计与管理)(12%) + (单元测试)(0.5 * 4% = 2%) + (例会)(5% * 20 / 58 = 1.7%) = 49.3% -> 172.6 -> 173 | 1. 后端开发(共1241行代码)与单元测试 2. 前端开发(共 2383 行代码) 3. 组织开展例会 20 次 4. 交易流程设计,绘制ER图与流程图 5. 燃尽图绘制 6. 完成团队博客 |
赵楠 | 后端 | (后端)10% + (单元测试)(0.5 * 4% = 2%) + (博客作业)(3% / 6 = 0.5%) + (例会)(5% * 7 / 58 = 0.6%) = 13.1% -> 45.9 -> 46 | 1. 后端开发(共459行代码)与单元测试 2. 参与例会 7 次 3. 完成团队博客 |
张昊博 | 前端 | (前端)15% + (博客作业)(3% / 6 = 0.5%) + (例会)(5% * 13 / 58 = 1.1%) = 16.6% -> 58.1 -> 58 | 1. 前端开发(共 3542 行代码) 2. 参与例会 13 次 3. 完成团队博客 |
仇志轩 | 前端 | (前端)(485/2590/2 * 0.5 * 30% = 1.4%) + (博客作业)(3% / 6 = 0.5%) + (例会)(5% * 10 / 58 = 0.9%) = 2.8% -> 9.8 -> 10 | 1. 前端开发(共 252 行代码) 2. 参与例会 10 次 3. 完成团队博客 |
池柏诚 | PM | (博客作业)(3% / 6 = 0.5%) + (例会)(5% * 1 / 58 = 0.1%) = 0.6% -> 2.1 -> 2 | 1. 参与例会 1 次 2. 完成团队博客 |
夏经纬 | 测试 | (测试)(12% - 4% = 8%) + (博客作业)(3% / 6 = 0.5%) + (例会)(5% * 4 / 58 = 0.3%) = 8.8% -> 30.8 -> 31 | 1. 用户场景测试与压力测试 2. 参与例会 4 次 3. 完成团队博客 |
石伊聪 | 部署 | (部署)8% + (博客作业)(3% / 6 = 0.5%) + (例会)(5% * 3 / 58 = 0.3%) = 8.8% -> 30.8 -> 30 //作业要求每个人分数不能一样,少一次例会,因此向下取整 |
1. 服务器部署 2. 代码仓库管理 3. 参与例会 3 次 4. 完成团队博客 |
用户场景
在发布博客中有对主要功能与用户场景比较详细的介绍。详见[T.11] 团队项目:Alpha 阶段发布说明
Beta阶段计划
Beta阶段的主要任务是:
- 小程序
完成微信小程序开发,使用户可以更加便捷地在平台上完成交易流程 - web管理端
实现用户、帖子等信息的增删改查功能与投诉处理功能。后端已经有这部分对应的接口,主要是开发对应的前端界面。 - 功能优化
加入帖子评论、历史订单等比较有用的功能。进一步美化界面。