[知识路书]项目展现

时间 2020-08-10

标签知识项目展现繁體版

原文原文链接

项目相关地址汇总

线上地址：http://47.94.141.56/html

前端仓库：https://github.com/MinJieDev/Roadmap-Frontend前端

后端仓库：https://github.com/MinJieDev/Roadmap-Backendvue

日会汇总：https://www.cnblogs.com/minjiekaifa/p/Scrum_Meetings.htmlios

功能规格：http://www.javashuo.com/article/p-wqsswgyj-nh.htmlnginx

技术规格：http://www.javashuo.com/article/p-fwhgjhii-nh.htmlgit

团队成员简介

请参考团队介绍博客 http://www.javashuo.com/article/p-hzzarakr-nm.htmlgithub

PM：hdlvuex

前端：zwx yzn ljy ymchrome

后端：zzy zxz数据库

Alpha发布与新增功能

Realease Alpha v0.1.0: 发布声明

Realease Alpha v0.1.1 20200507:

[问题修复]

修复外链分享时关联article权限问题
修复编辑器页面自动缩放逻辑异常

[新增功能]

编辑器强化
- 添加结点选择与基于其的操做，简化结点、链接删增改逻辑
- 添加快捷键
- 添加使用帮助
- 添加文献笔记的渲染显示
- 显示外观优化
文献管理
- 添加bibtxt批量导入文献
- 表格显示优化，支持行内信息折叠
- 文献笔记强化，添加markdown编辑器

部署形式与发布流程

部署形式：nginx+uwsgi，双环境

nginx负责静态资源分发，并把全部数据请求根据wsgi协议转发给后端服务
uwsgi开启多个后端实例，接收请求并分配后端服务实例响应
django服务实例响应请求，并经由uwsgi、nginx逐层返回

数据库开放了测试环境与生产环境，经过替换服务器配置文件实现对不一样环境的链接（默认开发时使用测试环境，线上使用生产环境）

发布流程：

前端：打包dist并推至服务器，nginx分发容许了热更新

后端：服务器上拉取生产分支prod，（迁移数据库后）uwsgi --reload roadmap.pid实现热更新

目标/用户/功能描述/预期用户数量

Alpha阶段预期用户数量：超过100人

实际注册用户数量：78人（截至5月8日）

分析：

咱们的推广思路起初不够开放，起初只是像其余团队同样在学生大群中进行广告投放。考虑到群内本科生（多为2017及2018级的大2、大三学生）大多还对文献阅读没有需求，这样的推广收效甚微。

5.6及5.7完成alpha阶段主体开发更新后，咱们调整思路，进行定向投放，向认识的同窗中已经参与科研的同窗进行说明推广，用户量快速增长了一倍。

有理由相信在完成了后续开发完善并使得产品更易用后，咱们延续该思路推广能更快速地斩获用户。

如何知足需求

咱们在页面中设置了反馈入口，Alpha期间收到39条反馈：

滤除无效信息，列举有参考意义的反馈以下:

6: 从bibtex导入这个功能作的很好啊，很方便就能导入不少文章
38: 导入Bibtex这个功能不错，不用一条一条往里面加

这是对咱们在alpha期间实现的“bibtex批量文献导入”功能的正向反馈。实际上这个需求是在alpha版本发布前的课上讨论上就被老师提出的，可见其极大补充了文献管理功能。相应的，有用户提出了进一步的需求：

20: 有批量导出bibtex么
17: 赞啊看paper就靠它了能不能导出冯如杯格式的文献引用啊，这几天快被他搞疯掉了

这是一个很是合理的需求。若是把咱们的产品归入学术工做流考虑，写论文时若是能够批量导出先前逐条添加的文献将很是便捷。咱们已经计划在beta阶段实现该需求，前置需求：[为文献table view添加复选框和全选按钮]正在开发

10: 前端很好看，要是有个help页面就更好了
12: 是花花让我随便骂的！并且他说我是目标用户我就姑且是了！可是我没用过相似的文献管理app，不知道怎么用！因此推荐大家添加一个About页面！目前就是这样！

这些反馈实际上说明咱们对产品的使用说明与用户引导作的还不够好。在看到该需求后咱们已经第一时间为路书编辑器添加了操做帮助，同时正在调研更好的引导方法与相应代码工具。或许写一篇路书教用户如何使用路书是一个不错的主意？

8：中间的body有点小宽了
14: 能够作一下手机端自适应，手机点开比较混乱哈！其余都挺好的

这些是用户提出的对界面布局及设备适配的需求。实际上咱们初期受限于开发精力，并无对此做出太多考虑。可是考虑到如今移动端设备高度普及，一些基本的适配仍是必要的。咱们会在beta阶段视开发进度安排决定是否进一步解决这个问题

23: 验证码太难了（哭\n试了3次都不对
20: 登陆的验证码太难了！！！

这是feature。咱们认为对大多数天天看内存模型或者变分推断相关文献的用户来讲，口算百之内加法并不算太难。（yzn：已经调整为30之内加法）

9: 加油呀！没有域名的大哥哥！

缺钱。腾讯云域名备案导入阿里云有点困难。此外咱们原计划beta之后的最终的发布形式将是相似overleaf同样的可自部署的私有云服务，所以这个地址也能够视做一个非正式的live demo

10: 用户名不支持中文编码但愿有空能够改进哦

已知问题。不支持中文是数据库对用户名域设置了latin编码，这个扔将维持，可是前端注册时须要提供更易于理解的错误反馈。将在beta加强

27: 好使啊。但愿有相似博客的交流系统
37: 有没有交友功能啊
28: 但愿能有大佬分享一波本身的路书

社交与学术社区其实是Mendely等产品的杀手功能，但考虑实现难度咱们暂时不予考虑。做为折衷方案，咱们在alpha版本提供了路书的分享外链功能，用户能够生成一条路书的分享连接并经过其余社交媒体传播，站外用户借助这个外链能够无需登录就看到别人分享的路书。

34: 挺好的工具，能搞个微信小程序么

暂时不予考虑。但先后端分离确实容许咱们这样作，或许能够做为之后的软工课程迭代方向。

总结：用户们对咱们的评价是十分中肯而友善的，咱们也借助这些反馈发现了不少不足，完善了不少以前没有考虑的细节，肯定了后续开发的方向。

Q: 对于项目的目标用户是通常学生的项目，大家如何找到学生作需求分析？他们给你什么样的反馈？

A: 群发vs逐个推销，后者数量少但反馈质量通常更高

网状协做

咱们的开发协做是网状的：每次同步会你们肯定接下来一个小阶段的开发目标与各自负责方向，而后采用分散开发的形式各自完成开发工做。若是遇到问题须要协做解决，由PM组织小规模会议迅速聚焦问题。在两至三天的迭代后再此进行全体同步会继续推动。期间穿插结对编程与互动式review，实现项目的异步-同步推动。

即，咱们的整体流程是：同步会 - 小规模会与分散开发 - pr与review - 小规模会与分散开发 - ... - 同步会

在关键开发节点（如冲刺末尾、发布前），根据进度须要安排集中开发，共同解决最后余留的问题，并集体review发布前的代码，完成冲刺

与集体日会制度相比，引入分散的小规模会议能够把每次会议须要解决的问题高度聚焦，提高会议效率
参考okr管理，每次同步会为每一个成员制定阶段大目标与小任务，成员就能够自行评估小任务的完成质量，自主补充小任务改善大目标的实现。这种总-分的管理更加节能。

项目管理与工做流

全部的代码首先要从主分支（dev分支）迁出，修改后提交到一个新分支（或本身的fork），再发起pull request合入dev分支。要求合并至dev前必须被至少一名其余开发者复审

发布时将dev分支的代码并入prod分支，要求必须至少2人参加复审

这样的双主分支工做流，容许在发布前拥有一个汇总分支（dev），全部测试工做在其上完成无误后再实际并入发布分支（prod），为生成环境创造一个错误缓冲区，也方便以后引入CICD

时间与效率管理

Q: 团队如何平衡时间/质量/资源争取如期完成任务的

在不可替代性与可替代性中取得平衡

咱们的分工安排，每一个人主要专精一个小方向的开发，使他/她能够大幅节约开发时的学习成本，这是开发者的不可替代性。同时同步会又要求全部人必须理解、熟悉其余人的代码，使得每一个人都具有可替代性。

这样，开发能够高度并行化展开，每一个人总主要负责推动本身所负责的小方向；当某个方向的开发遇到阻力时，即可以抽调其余方向的开发人员进行协助。

这能够自适应地最大化时间利用效率。

同时，咱们频繁引入、穿插结对编程，以此进一步优化开发效率。

测试用例数量与覆盖率

测试方法论：后端狠，前端稳

前端随发布随测，团队成员的开发环境覆盖了windows、ubuntu1604/1804和mac xos，浏览器覆盖ff、chrome。beta时可能考虑引入e2e测试

单元测试主要针对后端展开，前端主要以表格枚举测试为主（参考测试报告）

后端目前为全部模型接口的CURD行为与权限添加了单元测试，共11个case

借助coverage实现后端测试覆盖率分析：

Name                                                Stmts   Miss  Cover
-----------------------------------------------------------------------
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_feedback.py                 4      0   100%
roadmapData\migrations\0003_auto_20200430_0001.py       6      0   100%
roadmapData\migrations\0004_roadmapshareid.py           5      0   100%
roadmapData\migrations\0005_auto_20200501_1357.py       4      0   100%
roadmapData\migrations\0006_tags.py                     6      0   100%
roadmapData\migrations\0007_auto_20200504_0914.py       6      0   100%
roadmapData\migrations\0008_auto_20200504_0925.py       4      0   100%
roadmapData\migrations\0009_auto_20200504_0928.py       6      0   100%
roadmapData\migrations\__init__.py                      0      0   100%
roadmapData\models.py                                  41      0   100%
roadmapData\serializers.py                             36      0   100%
roadmapData\tests.py                                  197      0   100%
roadmapData\urls.py                                    15      0   100%
roadmapData\utils.py                                   56      5    91%
roadmapData\views.py                                   90      9    90%
-----------------------------------------------------------------------
TOTAL                                                 518     14    97%

代码规范

对于前端代码，咱们使用eslint进行自动化的代码质量检查

对于后端代码，咱们要求全部提交的代码必须经过ide自带的格式化（基于pep8）

此外在review时会进行必定程度的代码质量复审，如命名等。原则上，不影响理解的代码都能经过，咱们只追求自注释的清晰代码，不但愿把大部分时间花费在维护commit与注释上。

文档

不齐全，但够用。咱们的宗旨是避免一切低效的文档工做

两个代码仓库分别有基本的部署文档，同时，

前端：页面即文档/注释即文档。api调用封装为一个总的函数入口，借助restful api设计使得全局的数据请求逻辑类似。每一个view拆分红一个vue组件，使得页面逻辑内聚，可读易懂

后端：自动化文档。借助django restful framework与coreapi生成的自动api文档，便利先后端协做的同时解放后端同窗双手

燃尽图与功能发布

角色与贡献

贡献量化表

姓名	任务	按时(-5~1)	质量(-2~2)	任务量(1~5)x10
hdl	初始化CI/CD	-1	1	3	30
hdl	路书编辑中自动添加引用关系	0	1	3	31
hdl	将author和note绑定在表单中	1	2	1	13
hdl	hdl: fix bugs: editor; reader; router; package.json	0	1	3	31
hdl	Hdl add markdown preview and style	0	1	3	31
hdl	博客撰写/PM工做/汇报展现	0	0	50	500
					636
ljy	错误处理模态框封装	1	1	1	12
ljy	为文献管理列表添加按钮栏	0	1	1	11
ljy	添加文献CU表单面板	0	2	4	42
ljy	添加路书管理table view	0	1	5	51
ljy	文献CU抽屉绑定form data	1	0	4	41
ljy	文献表单数据项中增长[引用关系]	0	1	2	21
ljy	用户反馈收集	0	2	4	42
ljy	退出按钮	0	1	3	31
ljy	BibTex import in article table	0	1	4	41
ljy	添加文献笔记markdown编辑器	0	1	3	31
ljy	Change the description in README	0	1	1	11
					334
ym	引入table view组件	0	2	4	42
ym	MindTable组件添加data属性并接入	0	2	2	22
ym	文献管理页接入数据加载api	0	2	1.5	17
ym	文献管理页增删查对接后端数据api	0	1	3	31
					112
yzn	配置并封装axios	1	1	2	22
yzn	为axios配置拦截器	0	1	3	31
yzn	合并req函数的param与data参数	-1	1	1	10
yzn	文献管理页接入数据加载api	0	1	1.5	16
yzn	登录界面与缓存	0	1	4	41
yzn	具备权限认证的Request接口	1	1	3	32
yzn	注册界面	0	1	5	51
yzn	增长卡片式的登陆欢迎界面	1	1	5	52
					255
zwx	接入vue-mindmap	0	1	1	11
zwx	配置vuex	0	1	1	11
zwx	添加“新建结点”与“新建链接”按钮控件	0	1	4	41
zwx	mindmap编辑器加强	0	1	4	41
zwx	路书编辑接入api：获取文献列表	1	1	3	32
zwx	路书编辑：接入路书加载api	0	1	3	31
zwx	路书编辑：接入路书上传API	0	2	3	32
zwx	路书管理页面接入API	0	0	3	30
zwx	路书添加title CUR	0	1	3	31
zwx	建立reader view	0	1	3	31
zwx	路书接入描述	0	0	2	20
zwx	路书添加结点id-title映射	0	1	4	41
zwx	路书样式：文献节点颜色；线形加箭头；拖拽节点去抖动	0	1	4	41
zwx	add share button in editor and reader; fix share cannot get article bug	0	1	1	11
zwx	login-error-modal-fix	0	1	3	31
zwx	路书编辑器加强：点击事件编辑路书	0	1	5	51
zwx	为编辑器添加快捷键	0	2	4	42
zwx	添加Icon 添加帮助	0	1	2	21
zwx	路书阅览和编辑界面展现note	0	1	3	31
					580
zxz	添加requirements.txt	0	1	1	11
zxz	添加素材实体序列化器	0	1	3	31
zxz	完善API接口	0	1	2	21
zxz	增长路书名称字段	1	1	3	32
zxz	文献双向引用	0	1	3	31
zxz	fix bug: modify article_references symmetrical from true to false	0	1	3	31
zxz	容许空的URL	0	1	1	11
zxz	添加JWT登陆认证	0	1	4	41
zxz	添加用户反馈接口	1	1	2	22
zxz	remove feedback permission	0	1	3	31
zxz	change user-article relationship to 'one2one'	0	1	2	21
zxz	添加Permission测试和Auth测试	0	1	4	41
总					324
zzy	根据ER图添加Models	0	2	1	12
zzy	添加用户与路书实体序列化器	1	1	2	22
zzy	生成简易接口文档	0	2	2	22
zzy	添加单元测试	0	1	3	31
zzy	完善API接口	0	1	1	11
zzy	ignore venv; setting allow all host	0	2	1	12
zzy	fix bug: add id for roadmaplist	0	1	1	11
zzy	Add jwt	0	1	2	21
zzy	后端支持tags	0	2	3	32
zzy	随笔curd	0	1	3	31
zzy	添加models的CURD测试	1	1	4	42
总					247

最终分配

根据[知识路书]团队贡献分数分配方案获得最终分配：

总分	636	334	112	255	580	324	247	2488
比例	0.25562701	0.13424437	0.04501608	0.10249196	0.23311897	0.13022508	0.09927653	1
实际量化分	8.94694534	4.69855305	1.5755627	3.58721865	8.15916399	4.55787781	3.47467846	35
去重量化分	8	6	2	4	7	5	3	35
总分	53	51	47	49	52	50	48	——

特点功能总结

文献管理
- 批量bibtxt导入
- 支持markdown的文献笔记编辑
- 能够自定义的文献引用关系
路书编辑
- 定制的路书编辑器，支持快捷键、符合思惟直觉的高效编辑方式
- 自动链接文献引用关系，一次定义，处处链接，直观呈现文献发展脉络
路书阅览
- 支持生成站外分享连接，分享给亲朋好友，无需登录便可一览你精心编辑的知识路书

beta开发计划

外观与显示
- 增长用户引导
- 优化文案，消除中英文混杂与歧义
- 整理通知与模态框提示
文献管理
- 引入条件搜索与分页，更快更精准定位知识
- 引入自定义标签，让文献找到组织
- 复选与文献批量导出
路书编辑
- 容许连接添加弧度，编辑出更有人情味的路书
路书阅读与分享
- 为分享页面添加笔记查看

收获与启示

hdl：PM初体验。感受本身不少地方作的不是很好，好比开完会后老是不能即便完成博客记录、给你们分配的任务常常乱七八糟。好在队友各个都很能打，你们一块儿写出本身（和用户）须要的、喜欢的产品，一点一点打磨，这个过程很开心。软工的敏捷开发实践带给我良多收获，好比如何向其余人清楚表述个人想法，如何向他人请教问题更能节省双方时间，如何更快让别人理解个人思路云云。以前一直对PM这个岗位有一些偏见与误解，实际上手干起来发现PM这个岗位是软件团队中的掌舵者，责任重大，一点也没必要开发轻松，不只要对项目、对技术、对功能需求足够熟悉，还要学习一些管理技巧，确保团队的开发进度与方向正常。这再一次启发我，软件工程是一门十分深奥的管理哲学。