【敏杰开发】Beta阶段项目展示
【敏杰开发】Beta阶段项目展示
项目相关地址汇总
线上地址：http://roadmap.imcoming.top
前端仓库：https://github.com/MinJieDev/Roadmap-Frontend
后端仓库：https://github.com/MinJieDev/Roadmap-Backend
博客目录：https://www.cnblogs.com/minjiekaifa/p/12885923.html
功能规格：https://www.cnblogs.com/minjiekaifa/p/12661245.html
技术规格：https://www.cnblogs.com/minjiekaifa/p/12657347.html
发布说明：https://www.cnblogs.com/minjiekaifa/p/13039803.html
前端代码文档：https://github.com/MinJieDev/Roadmap-Frontend/wiki
入门指南：https://www.cnblogs.com/minjiekaifa/p/13080164.html
团队成员简介
请参考团队介绍博客 https://www.cnblogs.com/minjiekaifa/p/12544284.html
PM：zwx
前端：zwx yzn ljy ym cc
后端：zzy zxz
Beta发布与新增功能
Realease Beta v1.0.0: 发布声明
[新增功能]参见发布声明博客
- 用户系统
- 文献管理
- 路书管理
- 随笔管理
- 社区元素
部署形式与发布流程
部署形式：nginx+uwsgi，双环境
- nginx负责静态资源分发，并把所有数据请求根据wsgi协议转发给后端服务
- uwsgi开启多个后端实例，接收请求并分配后端服务实例响应
- django服务实例响应请求，并经由uwsgi、nginx逐层返回
数据库开放了测试环境与生产环境，通过替换服务器配置文件实现对不同环境的连接（默认开发时使用测试环境，线上使用生产环境）
发布流程：
前端：打包dist并推至服务器，nginx分发允许了热更新
后端：服务器上拉取生产分支prod，（迁移数据库后）uwsgi --reload roadmap.pid实现热更新
目标/用户/功能描述/预期用户数量
Beta阶段预期用户数量：超过200人
实际注册用户数量：230人（截至6月11日）
分析：
推广思路：我们的目标用户为有大量阅读文献需求的科研工作者，主要是研究生、博士生、导师等。
在alpha阶段我们的推广思路发生了偏差，只是像其他团队一样在学生大群中进行广告投放。考虑到群内本科生（多为2017及2018级的大二、大三学生）大多还对文献阅读没有需求，这样的推广收效甚微。
在beta阶段，我们调整思路，针对目标用户进行定向投放，向实验室中的实习生、研究生同学进行推广，让其在组会报告时使用我们的软件，这样可以让整个实验室的师生都了解我们的产品，用户量快速增加。
另外，我们的成员也在其各自的科学方法论课堂展示中推广我们的产品，这门课程正是培养我们本科生阅读文献整理文献能力的，如果使用我们的产品，将使同学们的思路更清晰、展示效果更理想。下图为我们组员在课上推广时的截图：
相信下一届学弟学妹在上科学方法论这门课时就可以更加愉快地使用我们的产品了。
如何满足需求
我们在页面中设置了反馈入口，Beta期间收到75条反馈：
滤除无效信息，列举有参考意义的反馈如下:
72 这个分享功能蛮不错的呀，今天上课看到一个大佬拿你们的网站做的导图，很好看
51 方法论课上看到yzn做了attention相关的roadmap，蛮实用的
49 看到那个篇GAN的做的好认真呀。\n用这个做文章梳理还挺不错的。\n可以做一套科研的工作流嘛？
路书就是为了向他人清晰地展示自己对于文献间脉络但梳理的，当我们在科学方法论课堂上展示我们的产品后，得到了很多好的反馈，我们的产品后续还会推出其它功能更好地帮助大家实现与文献调研相关的科研工作流。
54 应该早出来点......\n我方法论作者都是手写统计的.....
55 挺好，用了这个方法论作业写得快了不少\n文献管理加一个搜索功能就更好了
51 这个Arxiv推荐可以直接发到我的邮箱里面吗
作者统计是我们在beta阶段实现的一个新功能，可以清晰的对所选的文献集进行作者统计，画出统计图，哪位是真正的领域大咖一目了然，有助于科研人员分析该领域内作者的关系。当然此项功能也迎合了科学方法论课程的一些作业要求，因此广受好评。
67 需要一个社区功能，就是大佬发博客讲论文那种
84 怎么样看到别人的路书呀？想学习一下
37 有没有交友功能啊
我们在beta阶段只实现了一些常见的社区功能，如点赞、评论、分享、最新论文推荐等。分析用户反馈我们得知，应该搭建更完善的社区功能，让用户更容易接触到优质的路书示例。
76 是否能加个云盘功能呢？\n把论文PDF存在云盘上，然后可以用浏览器页面进行读取、标注\n每个设备都可以看到\n很实用！\n如果有云盘功能我一定冲会员！
77 随笔可以加一些模板吗？\n便于我们直接在模板上整理内容
59 挺好，用了这个方法论作业写得快了不少\n文献管理加一个搜索功能就更好了
51 这个Arxiv推荐可以直接发到我的邮箱里面吗?
65 和文献相关的基本功能都实现了，鼓励一下。\n另外，能否实现Mendeley那样的文献数据库呢？
我们也收到了很多用户的新需求建议，可见我们的产品有较高的人气，可提升改进的空间很高，适合进行下一步迭代开发。
78 bug 反馈\n路书编辑页里面，文献如果名字太长了会看不到全部....\n
81 路书编辑那里，会有文献拖不进画布的情况
当然，我们也收到了一些bug反馈，可以在后续的开发过程中解决
网状协作
我们的开发协作是网状的：每次同步会大家确定接下来一个小阶段的开发目标与各自负责方向，然后采用分散开发的形式各自完成开发工作。如果遇到问题需要协作解决，由PM组织小规模会议迅速聚焦问题。在两至三天的迭代后再此进行全体同步会继续推进。期间穿插结对编程与互动式review，实现项目的异步-同步推进。
即，我们的总体流程是：同步会 - 小规模会与分散开发 - pr与review - 小规模会与分散开发 - ... - 同步会
在关键开发节点（如冲刺末尾、发布前），根据进度需要安排集中开发，共同解决最后余留的问题，并集体review发布前的代码，完成冲刺
- 与集体日会制度相比，引入分散的小规模会议可以把每次会议需要解决的问题高度聚焦，提升会议效率
- 参考okr管理，每次同步会为每个成员制定阶段大目标与小任务，成员就可以自行评估小任务的完成质量，自主补充小任务改善大目标的实现。这种总-分的管理更加节能。
项目管理与工作流
此部分详细可参考我们的这篇博客[技术博客]使用Github进行软工开发管理
所有的代码首先要从主分支（dev分支）迁出，修改后提交到一个新分支（或自己的fork），再发起pull request合入dev分支。要求合并至dev前必须被至少一名其他开发者复审
发布时将dev分支的代码并入prod分支，要求必须至少2人参加复审
这样的双主分支工作流，允许在发布前拥有一个汇总分支（dev），所有测试工作在其上完成无误后再实际并入发布分支（prod），为生成环境创造一个错误缓冲区，也方便之后引入CICD
时间与效率管理
Q: 团队如何平衡 时间/质量/资源 争取如期完成任务的
在不可替代性与可替代性中取得平衡
我们的分工安排，每个人主要专精一个小方向的开发，使他/她可以大幅节约开发时的学习成本，这是开发者的不可替代性。同时同步会又要求所有人必须理解、熟悉其他人的代码，使得每个人都具备可替代性。
这样，开发可以高度并行化展开，每个人总主要负责推进自己所负责的小方向；当某个方向的开发遇到阻力时，便可以抽调其他方向的开发人员进行协助。
这可以自适应地最大化时间利用效率。
同时，我们频繁引入、穿插结对编程，以此进一步优化开发效率。
测试用例数量与覆盖率
测试方法论：后端狠，前端稳
前端随发布随测，团队成员的开发环境覆盖了windows、ubuntu1604/1804和mac xos，浏览器覆盖safari、chrome。
单元测试主要针对后端展开，前端主要以表格枚举测试为主（参考beta测试报告）
后端目前为所有模型接口的CURD行为与权限添加了单元测试，共12个case
借助coverage实现后端测试覆盖率分析：
Name Stmts Miss Cover [1/1932]
-----------------------------------------------------------------------
manage.py 12 2 83%
roadmapBackend/__init__.py 0 0 100%
roadmapBackend/settings.py 22 0 100%
roadmapBackend/urls.py 3 0 100%
roadmapData/__init__.py 0 0 100%
roadmapData/admin.py 5 0 100%
roadmapData/apps.py 3 0 100%
roadmapData/migrations/0001_initial.py 9 0 100%
roadmapData/migrations/0002_auto_20200531_1303.py 6 0 100%
roadmapData/migrations/0003_auto_20200601_2235.py 6 0 100%
roadmapData/migrations/0004_auto_20200601_2247.py 4 0 100%
roadmapData/migrations/0005_auto_20200601_2250.py 4 0 100%
roadmapData/migrations/0006_auto_20200601_2301.py 4 0 100%
roadmapData/migrations/0007_auto_20200601_2307.py 4 0 100%
roadmapData/migrations/0008_essayshareid.py 5 0 100%
roadmapData/migrations/0009_auto_20200602_2349.py 5 0 100%
roadmapData/migrations/0010_auto_20200603_1222.py 4 0 100%
roadmapData/migrations/__init__.py 0 0 100%
roadmapData/models.py 71 0 100%
roadmapData/serializers.py 74 0 100%
roadmapData/tests.py 214 0 100%
roadmapData/urls.py 18 0 100%
roadmapData/utils.py 50 4 92%
roadmapData/views.py 196 4 98%
-----------------------------------------------------------------------
TOTAL 719 10 99%
代码规范
对于前端代码，我们使用eslint进行自动化的代码质量检查
对于后端代码，我们要求所有提交的代码必须通过ide自带的格式化（基于pep8）
此外在review时会进行一定程度的代码质量复审，如命名等。原则上，不影响理解的代码都能通过，我们只追求自注释的清晰代码，不希望把大部分时间花费在维护commit与注释上。
文档
前端：我们在前端仓库的wiki中写了详细的文档，首先介绍代码的整体架构，使用的框架和工具，之后详细说明代码仓库中每个文件的意义，再按功能模块说明每个功能的实现思路、编码细节等，方便以后自己查看或其它团队接手。
后端：自动化文档。借助django restful framework与coreapi生成的自动api文档，便利前后端协作的同时解放后端同学双手
产品：为方便用户尽快上手我们的产品，我们为其撰写了一份上手文档，利用随笔功能发布在我们的知识路书平台，同时发布在博客园。
燃尽图与功能发布
在github中我们将beta的project截止时间定位冲刺的截止时间，但是为了方便任务量统计我们将测试和发布阶段的bug修复也算入此project中，因此燃尽图中结束点后移了，这并非我们拖延怠工的结果，特此说明。
角色与贡献
贡献量化表
| 姓名 | 任务 | 按时(-5~1) | 质量(-2~2) | 任务量(1~5)x10 | 得分 |
|---|---|---|---|---|---|
| cc | cc test-nouse | 1 | 1 | 1 | 12 |
| cc | 修改删除文献结点 | 1 | 1 | 1 | 12 |
| cc | 路书连接曲线拖动 | 1 | 2 | 4 | 43 |
| cc | 路书阅览界面的连接拖动 | 0 | 0 | 1 | 10 |
| cc | 路书编辑时连接拖动的bug修正 | 1 | 1 | 2 | 22 |
| cc | 路书节点颜色自定义修改 | 1 | 2 | 3 | 33 |
| cc | 路书：文献的alias别名 | 0 | 1 | 1 | 11 |
| 总 | 143 | ||||
| ljy | tag前端 | 0 | 1 | 4 | 41 |
| ljy | 面包屑改进 | 0 | 1 | 3 | 31 |
| ljy | 社区功能：推荐系统相关 | 0 | 1 | 5 | 51 |
| ljy | 文献推荐导入：导入文献作者分隔符问题 | 0 | 1 | 2 | 21 |
| ljy | Get New Paper 脚本部署 + 推荐界面更新 | 1 | 2 | 2 | 23 |
| ljy | 修正 推荐文献导入 字段 | 1 | 1 | 1 | 12 |
| ljy | 部署脚本请求Arxiv，写入数据库 | 0 | 1 | 4 | 41 |
| 总 | 220 | ||||
| ym | Article Table 多选删除 & 仅显示第一作者 | 1 | 1 | 3 | 32 |
| ym | Add MindTable expanded | 0 | 1 | 2 | 21 |
| ym | Article Read Unread status & Pagination in FrontEnd | 0 | 2 | 3 | 32 |
| ym | 批量导出bibtex | 0 | 1 | 3 | 31 |
| ym | 改进文献管理表格UI | 0 | 2 | 2 | 22 |
| ym | Article: Bibtex 批量导入时存入后端字段，导出时读取 | 0 | 1 | 2 | 21 |
| ym | article 页面分页 | 0 | 1 | 3 | 31 |
| ym | 前端的路书分页 | 0 | 1 | 2 | 21 |
| ym | 随笔管理界面 | 0 | 1 | 3 | 31 |
| ym | 社区功能：注册页面加感兴趣方向的选择 | 0 | 1 | 2 | 21 |
| ym | 社区功能：个人中心 | 1 | 1 | 5 | 52 |
| ym | 文献统计：全部文献的作者出现频次统计 | 0 | 1 | 4 | 41 |
| ym | 文献导入：作者分割与bib导入问题 | 0 | 1 | 1 | 11 |
| ym | 文献笔记完成状态：根据后端接口做修改 | 0 | 1 | 2 | 21 |
| ym | 个人中心：和后端新增个人信息对接 | 1 | 1 | 1 | 12 |
| ym | 文献统计：添加文献管理页向文献统计页面的跳转按钮 | 0 | 1 | 1 | 11 |
| ym | 导出：复制功能 | 0 | 1 | 2 | 21 |
| ym | 文献管理：打开文献修改drawer时无法显示 | 0 | 1 | 1 | 11 |
| 总 | 443 | ||||
| yzn | 路书管理卡片布局 | 1 | 1 | 3 | 32 |
| yzn | switch导致的卡片对齐问题 | 0 | 2 | 1 | 12 |
| yzn | 路书的导出与缩略图 | 0 | 1 | 5 | 51 |
| yzn | 路书卡片界面浮窗显示 | 0 | 2 | 3 | 32 |
| yzn | 路书管理界面：卡片/表格使用偏好的缓存 | 0 | 1 | 1 | 11 |
| yzn | Attention is All You Need 样例路书 + 用户使用简介 -> 博客形式 | 0 | 1 | 4 | 41 |
| yzn | 优化路书卡片的预览浮窗 | 1 | 1 | 1 | 12 |
| 总 | 191 | ||||
| zwx | 路书解决节点重名 | 1 | 1 | 4 | 42 |
| zwx | 路书编辑器：拖拽添加文献节点 | 0 | 1 | 3 | 31 |
| zwx | 路书编辑器，查看文献笔记，跳转编辑文献笔记页面 | 0 | 1 | 1 | 11 |
| zwx | 路书阅览界面处理路书重名问题 | 1 | 2 | 1 | 13 |
| zwx | 后端的api分页引起的roadmap变化 | 0 | 1 | 1 | 11 |
| zwx | 前端路书编辑器和阅览器改回得到全部api | 0 | 1 | 1 | 11 |
| zwx | 新路书保存后跳转路由 | 1 | 1 | 1 | 12 |
| zwx | 随笔相关启动 | -1 | 2 | 3 | 31 |
| zwx | 社区功能：点赞评论前端 | 0 | 0 | 3 | 30 |
| zwx | 根据文献反查路书 | 0 | 1 | 3 | 31 |
| zwx | 路书：文献的alias别名 | 0 | 1 | 1 | 11 |
| zwx | 随笔节点引入路书编辑器 | 0 | 1 | 3 | 31 |
| zwx | 路书引入随笔节点、编辑路书随笔、分屏显示阅览器 | 0 | 1 | 4 | 41 |
| zwx | 路书随笔节点，打开跳转链接，节点多行显示 | 1 | 2 | 2 | 23 |
| zwx | 路书删除：删除失败 | 2 | 1 | 1 | 13 |
| zwx | 解决share的bug，添加essay的share | 0 | 2 | 3 | 32 |
| zwx | Comment 接入API | 1 | 0 | 3 | 31 |
| zwx | Like功能接入API | 0 | 1 | 3 | 31 |
| zwx | bug： 跳转url 增补http | 0 | 1 | 1 | 11 |
| zwx | fixbug: 分享，文献和随笔权限：字段变化 & 添加随笔分享 | 1 | 1 | 4 | 42 |
| zwx | zwx--fixbug-share-auth | 0 | 0 | 3 | 30 |
| zwx | articel model page to charfield | 0 | 1 | 1 | 11 |
| zwx | ZWX: add article abbrtitle | 0 | 1 | 1 | 11 |
| zwx | PM工作 | 10 | 100 | ||
| 总 | 641 | ||||
| zxz | 提供一个返回全部article和全部roadmap的api | 0 | 2 | 1 | 12 |
| zxz | 添加文章别名alias | 1 | 1 | 2 | 22 |
| zxz | 添加感兴趣的领域 | 0 | 1 | 1 | 11 |
| zxz | Essay属性添加state & abstract & author 以及分页功能 | 0 | 1 | 3 | 31 |
| zxz | 用户个人信息 | 1 | 2 | 3 | 33 |
| zxz | 添加表newpaper | 0 | 1 | 3 | 31 |
| zxz | add time | 0 | 1 | 1 | 11 |
| zxz | Article：read_state从bool值改为字符串类型 | 0 | 1 | 2 | 21 |
| zxz | 添加点赞功能 | 1 | 1 | 3 | 32 |
| 总 | 204 | ||||
| zzy | tags | 1 | 1 | 3 | 32 |
| zzy | 添加bib | 0 | 1 | 2 | 21 |
| zzy | 添加filter | 0 | 1 | 2 | 21 |
| zzy | 添加分页 | 0 | 1 | 3 | 31 |
| zzy | page | 0 | 0 | 2 | 20 |
| zzy | add tag search | 0 | 1 | 3 | 31 |
| zzy | 添加评论功能 | 0 | 2 | 3 | 32 |
| zzy | hash view | 0 | 1 | 3 | 31 |
| 总 | 219 |
最终分配
根据[知识路书]团队贡献分数分配方案得到最终分配：
| 姓名 | zwx | ym | ljy | zzy | zxz | yzn | cc | 总 |
|---|---|---|---|---|---|---|---|---|
| 总分 | 641 | 443 | 220 | 219 | 204 | 191 | 143 | 2061 |
| 比例 | 0.31101407 | 0.2149442 | 0.1067443 | 0.1062591 | 0.09898108 | 0.09267346 | 0.06938379 | 1 |
| 实际量化分 | 10.8854925 | 7.52304706 | 3.73605046 | 3.71906841 | 3.4643377 | 3.24357108 | 2.4284328 | 35 |
| 去重量化分 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 35 |
| 总分 | 53 | 52 | 51 | 50 | 49 | 48 | 47 | ——— |
特色功能总结
- 文献管理
- 批量bibtxt导入、导出
- 支持markdown的文献笔记编辑
- 可以自定义的文献别名，帮助记忆
- 路书编辑
- 定制的路书编辑器，支持快捷键、鼠标点击、拖动、符合思维直觉的高效编辑方式
- 自动连接文献引用关系，一次定义，到处连接，直观呈现文献发展脉络
- 用户自定义节点颜色，随心所欲，打造漂亮的路书
- 连接曲线自定义拖拽，形状任你定，板式任你排
- 随笔功能
- 知识路书原装的”博客“功能，不用出站即可随手编辑您的想法
- 与路书分屏阅览，更清晰地解释路书中的内容
- 社区功能
- 支持生成站外分享链接，分享给亲朋好友，无需登陆即可一览你精心编辑的知识路书
- 给你喜欢的路书点赞、评论，在思维碰撞中产生灵感的火花
- 每日最新论文推荐，个性化推荐您感兴趣的最新论文，让您实时了解前沿动态
后续开发计划
- 更完备的社区功能
- 最新路书推荐
- 最热路书推荐
- 收藏功能
- 关注功能
- 更好用的路书编辑器
- 提供一份相对约束的路书模版，比如我们把曲线的弧度定为常量，适度约束可以得到更好的使用简便性，易上手、易操作
- 文献栏和随笔栏添加搜索功能，修复无法显示全文字的问题
- 推出随笔路书分屏编辑器，写随笔和写路书同时进行，一边画一边写
收获与启示
zwx：一学期的软件工程课收获满满。软件工程课就应该在做中学、学中做。团队项目中，我从一个开发小白的身份在alpha开发阶段一点点摸爬滚打，从我们的前PM大佬学到了很多开发技术、项目管理方法。进入beta阶段后，我有幸接替原PM大佬的工作成为PM，和团队成员一起不断完善我们的产品。PM的经历让我实践了更多软件工程领域的学问，我学会了如何与人沟通、如何分配任务、如何督促监管任务的执行、如何与团队合作等等。看着我们的产品从无到有再到基本健全、收到用户的积极反馈，真的是一件无比享受且欣慰的过程。我会珍惜这次软件开发经历、珍惜一起结对编程的小伙伴、珍惜在北航度过的软件工程时光～
