Beta阶段展示博客
Beta阶段展示博客
1. 团队成员的简介和个人博客地址
刘畅
博客园ID:森高Slontia
身份:PM
个人介绍:
弹丸粉 || 小说创作爱好者 || 撸猫狂魔(x || 生命的价值在于创造
(我绝对不知道,我一个写代码的怎么就当PM去了?)
张安澜
博客园ID:MinstrelZ
身份:后端开发
个人介绍:
张安澜,来自北京航空航天大学2015级计算机学院,喜欢旅游,修仙党,lol大乱斗选手,吃鸡萌新,喊666贼6
辛德泰
博客园ID:Alethia
身份:前端开发
个人介绍:
我是ZnTcTi
赵奕
博客园ID:ohazyi
身份:开发
个人介绍:
擅长做梦,喜欢折腾
*科栋
身份:测试
个人介绍:
无。
2. 团队开发情况
2.1 项目预期
2.1.1 团队项目的目标
红色为Alpha阶段实现的功能,蓝色为Beta阶段实现的功能。
完善功能
Beta阶段中我们对Alpha阶段实现的功能进行了改进,增加了课程收藏功能、资源评价功能、资源分类功能等等,这些细微的功能可以大大增强用户体验。
提供交流平台
我们认为,在学习过程中,同学们最需要的是总结和交流。和Alpha阶段一样,我们的最终目标一直是排除同学们在学习道路上的困难,因此在Beta阶段中,我们增加了讨论版功能,同学们遇到任何问题都可以在讨论版进行交流。
2.2 用户量情况
在排除所有测试账号的情况下:
- 截至Alpha阶段结束,网站访问ip数(不计APP)约为220,注册量为30;
- 截至Beta阶段结束,网站访问ip数为633,同期增长率为187.7%,注册量为148,同期增长率为393.3%。
经统计,截至Beta阶段结束,Android用户占比最高,为45%,其次为网页端用户,为33%,同袍用户占19%。此外,还有少部分用户同时为同袍和Android用户。
结果显示,超过80%用户只是临时使用iCourse获取资源,但依然有近百位用户多次使用iCourse获取资源(访问天数为10以上的ip可能属于开发人员)(该结果仅为网页端)
目前APP下载量为214
2.3 一些进步
2.3.1 分工协作情况
Beta阶段相比于Alpha阶段,团队的分工更明确了。在Beta阶段开始前,我们将要实现的功能分为两类,一类是对资源共享的扩展,一类是全新的博文功能。这两大类功能之间关联性较低,由两位后端成员各自负责一类最为合适,这样各自的工作会变得独立,降低沟通带来的成本。
2.3.2 贡献分分配
在Alpha阶段中,贡献分分配规则太过复杂,如任务难度还要分为预计和实际两部分,记录贡献的成本有些高。在Beta阶段中,贡献分被简化为时长、难度和完成情况三部分,其中难度和完成情况的评分有着明确的标准,而时长一旦确定,之后会尽量避免改动。对本人实现功能的bug修正,不再新建“贡献项”,而是根据bug类型适当提高原“贡献项”的难度。
任务完成得分 = 完成度 * 时长 * (1 + 难度) * 5
2.3.3 文档完善情况
Beta阶段我们有了较为完备的数据库说明文档、API说明文档,并在老师的建议下添加了配置说明文档,全部文档位于/docs/目录下。
在Beta阶段中,成员们可以根据事先设计的API文档实现功能,缩短了沟通的时间,提高了工作效率。
同时,每名成员的贡献分也同样在/docs/目录下,做到了贡献情况的透明,保证公平性。
2.3.4 issue的建立
经老师建议,我们将测试及使用中遇到的bug及时以issue的形式记录在github上,当bug被解决的时候再将其close。
2.3.5 推广手段
Alpha阶段中,我们唯一的推广手段只有朋友圈;而在Beta阶段中,除了在朋友圈中进行推广,我们还在未来花园、同袍App、公众号上进行推广,从用户量增长情况可以看出取得了一定的效果。
未来花园:
同袍:
2.4 时间/质量/资源的平衡
Beta阶段中团队面临的情况十分险峻——前端开发人员的减少(2人变为1人)、编译课设的开始、期末各种DDL轮番轰炸都是我们面临的挑战。不仅人手少了,成员们可分配给软工的时间也远远不如Alpha阶段。最终的结果是后端实现了充分的功能,而前端只能视情况挑选必要的将其衔接到界面中。
2.5 测试情况
-
jmeter中设置用户数为30,循环次数为“永远”,运行起始时间为2017.12.23 00:30, 运行结束时间为2017.11.25 00:34, 平均请求响应时间为3.6s,错误率为0,30个用户,3.6s的平均响应时间偏慢,响应最慢的url是course/contrib,这个是计算课程的用户贡献度的,速度比较慢的原因推测是每次计算课程用户复杂度时,都要重新遍历数据库,重新计算用户贡献度,因此较慢,具体数据见下图:
-
测试人员同样尝试了用户数为35,33,31的情况,运行10min左右后,发现均会出现微小的错误,大约千分之几到百分之几的样子,这说明30个用户已是网站的最大负载。
-
2017.12.28 将服务器上运行的进程数由1增加到10,最大负载增加到141个用户。尝试142/143个用户时都会出现微小错误。
-
2017.12.29 经过刘畅同学和赵奕同学的优化,平均响应时间降至1.4s,较第一次测试的平均响应时间降低61%,最大用户数不变。
2.6 代码规范
我们使用的是npm自带的代码规范审查,包括但不限于:
- 大括号之中的内容和左右大括号之间必须有空格或换行
- 所有引号必须为单引号
- 不允许出现tab
- 每行末尾必须有空格
- 不允许出现声明变量未使用的情况
另外在view.py中,我们对函数实现的功能进行了一个简要的说明,大大提升代码可读性,如图:
2.7 一些反思
- Beta阶段出现的最严重的问题是预计实现的功能太多,而由于临近期末大家时间都很紧,导致最终也只是实现了一部分。当全部功能的实现得不到保证的时候,不同功能之间的优先级就显得很重要,然而PM却没有及时对计划进行调整,实在是缺乏大局观
- 代码管理得不到位,基本上全部后端的实现都堆在几个.py文件里(views.py文件达到了2000行),影响开发效率,而且命名规则也没有统一
- 除了Beta阶段开始时备份过一次数据库,此外再也没有对数据库进行备份
3. 进展情况
3.1 燃尽图
最后一次会议的燃尽图:
这个燃尽图是根据github中issue的关闭情况自动生成的,因此符合开发的实际情况。
由于编译课设比较紧张,而且团队人手又不太充足,团队进展速度时快时慢,最终未能在期限内完成预计的工作,只得暂时放弃一些非核心的功能。
3.2 发布的功能
我们的网站: 北航iCourse课程资源平台
3.2.1 首页
3.2.2 课程搜索页面
3.2.3 课程信息页面
3.2.4 课程资源页面
3.2.5 资源信息面板
3.2.6 课程讨论版
3.2.7 帖子页面
3.2.8 登录面板
3.2.9 个人中心
4. 团队成员在Beta阶段的角色和具体贡献:
4.1 代码贡献
使用如下指令,统计每个人Beta阶段(2017-11-22以后)代码贡献
git log --format='%aN' | sort -u | while read name; do echo -en "$name\t"; git log --since==2017-11-22 --author="$name" --pretty=tformat: --numstat | awk '{ if ($1 >= 0) {add += $1; subs += $2; loc += $1 - $2} } END { printf "added lines: %s, removed lines: %s, total lines: %s\n", add, subs, loc }' -; done
辛德泰(前端):3139
方科栋(测试):170
张安澜(后端):923
赵奕(后端):3966
刘畅(PM):3760
使用如下指令,统计全部代码贡献:
git log --format='%aN' | sort -u | while read name; do echo -en "$name\t"; git log --author="$name" --pretty=tformat: --numstat | awk '{ if ($1 < 500) {add += $1; subs += $2; loc += $1 - $2} } END { printf "added lines: %s, removed lines: %s, total lines: %s\n", add, subs, loc }' -; done
辛德泰(前端):5259
窦鑫泽(前端):2067
方科栋(测试):519
张安澜(后端):2283
赵奕(后端):5380
刘畅(PM):5360 + 1351
由于git的代码贡献统计不一定准确,该结果仅供参考。
4.2 最终贡献分
各成员贡献情况。贡献分的计算方式依照事先制定的贡献分分配文档(有一定调整)。
由于又出现了同分的情况,具体分配结果有待调整
分配结果:
姓名 | 贡献分 |
---|---|
方科栋 | 51 |
辛德泰 | 52 |
刘畅 | 47 |
张安澜 | 40 |
赵奕 | 60 |
5. 存在的问题
2018.1.1
搜索到的结果可能会不全,目前还没有定为到具体原因。