【观隅】Beta项目展示
一、项目与团队亮点
1.1 团队成员分工简介
「观隅」在Beta阶段整体上仍采用模块式开发,即由每位团队成员分别负责不同的模块,分工简介如下,详细任务完成情况请参见后文的 工作量 一节。
成员 | 分工 | 模块 | 备注 |
---|---|---|---|
LYL | 前端 | 首页模块 | 负责首页的设计与实现 |
DSY | 前端 | 后台管理模块 | 负责管理页面的设计与实现,负责调通管理接口 |
LXY | 前端 | 登录模块 | 负责登录页面的设计与实现,负责调通登录接口 |
WPB | 前端 后端 解析引擎 |
文本和音频数据集可视化模块 用户模块 |
负责文本和音频类型数据集的解析以及对应的前端展示页面的实现 负责实现用户系统以及相关接口 |
YZM | 解析引擎 | 图片数据集的可视化模块 | 负责增加图片数据集的数量 |
GTC | PM 后端 |
后台管理模块 | 负责与数据库相关的各管理接口的实现 |
MR | 后端 | 部分其他模块 | 参与单元测试的编写 |
注:单元测试由后端成员同步完成。
1.2 项目管理
-
进度管理
在Beta的计划阶段中,我们建立了数个 Milestone 和数十个对应的 Issue 对全部任务进行了分解,并为不同的 Milestone 设置了不同的 deadline ,以期对任务量进行合理的量化。在开发过程中,我们以燃尽图的形式对现有进度进行实时跟踪,并以此为基础动态调整下一阶段的开发速率,或是对部分功能进行一定的取舍。整体而言,Beta全过程的进度是有序而健康的。
-
分支管理
我们建立了完善的复审和 merge 机制,即每位开发人员在自己的 dev 分支上编写和测试自己模块的代码,并在适当的时机提交 Merge Request,其通过CI的检查并由前端或后端的另外一名开发人员亦或是WPB复审后方可并入 develop 分支。这样的工作流程和复审机制在很大程度上保障了代码质量,也保证了当问题出现时能够及时找到对应的负责人进行修复。
1.3 典型用户场景
「观隅」的典型用户为刚入门机器学习的高校学生、模型设计与模型优化等相关从业者、深度学习相关研究者、深度学习方面课程教师四大类,下面我们分类介绍「观隅」如何满足其相应的典型场景。
-
典型用户一:刚入门机器学习的高校学生
- 典型场景:A同学在大二选修了一门叫“计算机导论”的课程,其大作业要求在某一经典数据集上实现某神经网络模型的训练,然而A同学不太理解所下发的数据集中的标注信息的含义,于是他首先在「观隅」的网页端中搜索公开数据集,无果后通过 pip 安装并部署了「观隅」的本地版本,根据”帮助“的引导正确导入了所下发的已完成标注的数据集,借助于「观隅」所提供的的标注信息可视化功能,A同学直观快速地理解了标注的意义,同时还和其他同学一起查看与讨论,对课程内容和大作业要求有了更深入的理解。此外,他还根据所下发数据集的标注类型和应用场景在「观隅」网页端中筛选并查看了同一类型的其他数据集,达到触类旁通的效果。
- 网页端相关功能:数据集筛选与搜索,数据集信息介绍,数据集条目可视化总览,数据集条目与标注信息详细可视化,数据集条目交互
- 本地端相关功能:帮助文档,数据集管理,数据集条目可视化总览,数据集条目与标注信息详细可视化,数据集条目交互
-
典型用户二:模型设计与模型优化等相关从业者
- 典型场景:B工程师正在进行某一内部模型的调参工作,但目前该模型在某一数据集上表现不佳且难以找出原因。该工程师在已部署到公司内网上的「观隅」本地端上添加了该数据集,并为数位研究人员准备了账号,借助于「观隅」所提供的服务,B工程师可以和其他数位研究人员一同查看数据集中的标注情况,并对可能存在的问题和思路进行交流。同时,得益于「观隅」完善的鉴权机制和本地部署版本的特性,他也无需对内部数据集的数据安全性有所担忧。
- 本地端相关功能:帮助文档,数据集管理,配置文件管理,成员管理,数据集条目可视化总览,数据集条目与标注信息详细可视化,数据集条目交互
-
典型用户三:深度学习领域的研究者
- 典型场景:C研究员刚读完顶会的最新paper,准备复现一下实验,于是先下载了数据集,在本地部署的「观隅」上添加了该数据集并查看了数据集中的标注情况,借助于「观隅」提供的可视化功能,他可以很容易地获取一些展示用图片,大大提高了准备组会和论文插图的工作效率,「观隅」使他更轻松的完成科研任务。此外,他还在「观隅」的网页版上筛选了其他同类数据集,开拓了思路。
- 网页端相关功能:数据集筛选与搜索,数据集信息介绍,数据集条目可视化总览,数据集条目与标注信息详细可视化,数据集条目交互
-
本地端相关功能:帮助文档,数据集管理,数据集条目可视化总览,数据集条目与标注信息详细可视化,数据集条目交互
-
典型用户四:教授机器学习相关课程的教师
- D讲师本学期正在教授某机器学习方面的专业课程,他为了在课堂上展示数据集的标注工作,使用「观隅」向同学们展示标注好的可视化数据集。借助「观隅」提供的多种类型数据集的可视化功能和数据集条目可视化交互功能,同学们更容易地理解了数据集的标注工作,拉近了师生距离,「观隅」使得教师们更轻松地完成了教学任务。
- 网页端相关功能:数据集筛选与搜索,数据集信息介绍,数据集条目可视化总览,数据集条目与标注信息详细可视化,数据集条目交互,信息反馈
1.4 特色功能
杀手级功能
我们的杀手级功能是:数据集可视化、数据集可视化交互、搜索与筛选、数据集本地管理。
分别指的是对数据集的各个条目进行可视化、和在这个基础上,可以选择性显示如蒙版(mask),标签(label),物体(object)等标注情况的可视化结果、对数据集进行关键词匹配的搜索和按标签筛选以及依赖于本地端的数据集管理。
竞品比较
✔:完全实现相关功能,可以满足用户需求
✖:未实现相关功能,不能满足用户需求
⭕:部分实现相关功能,部分满足用户需求
功能 | 观隅(Ours) | 格物钛 | 各数据集简介界面 |
---|---|---|---|
数据集概述 | ✔ | ✔ | ✔ |
数据集条目详细可视化 | ✔ | ⭕(部分数据集缺少可视化) | ⭕(只对一部分做了可视化) |
数据集条目交互 | ✔ | ✔ | ✖ |
数据集浏览 | ✔ | ✔ | ✖ |
数据集条目总览 | ✔ | ✖ | ✖ |
数据集搜索 | ✔ | ✔ | ✖ |
数据集管理 | ✔ | ⭕ | ✖ |
可以看出,我们相比于各数据集简介界面,提供了聚合且丰富的可视化方案。而相比较于比较成熟的数据集可视化平台格物钛,我们做到了覆盖了常见的数据集种类,并且对于每一类数据集都存在着良好的可视化效果。并且存在差异化的数据集条目总览功能,这是格物钛没有的。
我们还提供了根据关键词进行搜索和按标签进行筛选的功能,以方便用户在多个数据集中根据需求准确查找到对应数据集。
并且我们提供更具安全性的数据集本地管理功能,可以在本地端进行私有数据集的管理和可视化,避免了不必要的学术风险和商业风险。
1.5 项目发布
- 项目推广
我们将开发环境服务器的配置部署到生产环境,做针对性的配置优化,添加了首页以促进推广。
同时,我们还在朋友圈、QQ空间、机器学习交流群等渠道分享项目引流。
- 帮助文档
可以查看快速上手以了解本地端使用方式
- 活跃用户数据
2021/6/16 | 2021/6/17 | 2021/6/18 | 总计 | 日均 | |
---|---|---|---|---|---|
日访问量 | 37 | 29 | 43 | 109 | 36 |
日活跃用户量 | 26 | 21 | 29 | 76 | 25 |
日下载量(本地端) | 13 | 10 | 14 | 37 | 12 |
- 用户反馈
功能反馈 | Bug反馈 | 是否预期 |
---|---|---|
缺少下载数据集的地方 | 标签栏标签过多时会超过边框 | 预料之外 原因:单元测试覆盖不够全面 |
1.6 软件工程质量
- 详细的内部文档
- 后端建立了数据库设计文档以详细描述实体定义和实体之间的关系,有助于后端开发人员厘清概念,提高开发效率。
- 前端配备有详实的开始文档,展示了前端的基本工作流程,对前端开发人员的开发工作起到一定的指导作用。
- 数据集解析引擎以及配置文件等相关内容也配备了详细的说明文档,有助于后端开发人员与数据集解析模块进行对接。
- 使用成熟的 swagger editor 编写接口文档,并对各个接口和模型均进行了详细定义,这有助于前后端成员理解接口和模型含义,提高相关对接工作效率。此外,我们还将该接口文档部署到 develop 服务器上,使其能够对我们的真实后端接口发送请求,这一工作大大缩减了调通前后端接口上所花费的时间,也让修改接口带来的影响趋于最小,更加符合“敏捷”的理念。
-
严谨的代码规范
- 后端使用
PyLint
进行严格的代码检查,并规定当且仅当代码得分达到 8 分时才能够通过CI。在必要的时候,后端开发人员会暂停现有进度,并对一些不符合代码规范的 warning 进行集体修复,最终PyLint
分数为 \(9.97/10\) 。
- 后端使用
-
前端使用
eslint
工具对代码规范进行检查并在CI中进行配置,拒绝不通过检查的代码并入 develop 分支,在此基础上使用prettier工具对代码风格进行检查,并配置相关命令进行自动修复,此外还采用husky设置GitHook,每次commit时都将触发进行代码格式的自动修复和Ts检查 -
清晰的帮助文档
为了帮助用户快速上手部署和使用「观隅」的本地端服务,我们编写了简约而清晰的帮助文档和如何拓展,其中由浅及深地记录了何如对「观隅」本地端的基础功能进行使用,以及如何获得更高的可定制性。
-
完整的单元测试
我们使用
django
自带的库对后端代码进行单元测试,并规定当且仅当覆盖率达到 90% 才能并入 develop 分支。在此基础上,后端开发人员构建了完整的单元测试,整体覆盖率达到了96%。此外,「观隅」期望在多平台都提供良好的本地服务,因此单元测试均分别在Windows和Linux下运行通过。
-
优秀的CI/CD流程
我们整体采用CI/CD加速工作流程,及时发现问题并持续集成。
后端项目采用CI/CD对每次提交进行代码规范检查和单元测试,及时发现基础问题。同时检查是否有没提交的migration,保证部署的正常进行。在master和develop分支上的提交会,项目会在服务器上自动构建,并推送方便部署的镜像形式至腾讯云镜像服务仓库,master分支和develop分支使用不同的镜像。此外我们还配置了自动部署功能,develop分支的改动都会在开发服务器上实时显示供大家实验,master分支的改动则发布至生产服务器,只有在开发环境验证过的内容才会移动至生产服务器上。
前端项目也在develop和master分支上配置了类似的自动构建/部署功能。同时前端CI/CD会对语法和单元测试进行检查并尝试编译,如果都没有问题才会进入构建部署。
CI/CD的使用极大提高了项目整体的开发效率,前后端均可以在不掌握彼此部署方式的情况下完成开发和测试工作。
二、项目与团队总结
2.1 项目管理
- 成员简介
- 「观隅」团队成员简介如下:https://www.cnblogs.com/RiddleMan/p/14655399.html
- 个人博客地址:
-
项目管理的改进
在Alpha阶段开始之前,我们预采用了轮值PM的方式,即每周由不同的成员担任PM,这样能够使得团队所有成员都有从整体上对项目进行观察的和具体投身开发工作的机会。但是,在具体实践中这样的方式出现了一些问题,造成了其效果与预期的偏离。这一偏离主要体现在,首周PM使用Swagger完成了接口API,这一工具有一定的上手难度,造成第二周开发过程中对API文档进行修改的工作也大多是由第一周PM完成的。从结果上来看,第二周PM的工作仅是例会的组织与例会报告的编写,而一些接口上的同步工作则由其他成员承担,造成了PM名实不符的现状。
在Beta阶段中,我们直接指定了一名成员作为PM,负责所有的接口制定、文档编写、进度保证等工作,这样的做法与Alpha阶段相比无疑提高了工作效率,也在无形之中提高了最终的项目质量。
-
分工协作的改进
在Alpha阶段中我们先后采用了任务分发制和任务池机制,并对任务分发制的不足进行了反思,肯定了任务池机制对提高项目开发效率的正面意义。因此,在Beta版本中,我们继续使用类似的任务池机制,即每隔一个较长的时间段(例如两到三次的例会间隔),时间段开始时团队成员一起思考还有哪些工作尚未完成,取最近最迫切的一个大的任务板块进行任务细分工作,说明每一条工作要实现的东西,并放进在
gitlab
的一个帖子中去(即一个任务池)。成员自己去任务池中领取相应的任务,并且标注loading...
的字段与签署个人名称,表示自己会承担这一部分的任务。将这样的方式同整体上模块式开发的思路相结合,有助于提高团队成员的内部驱动力,是分工协作方面的一大改善。 -
沟通对接的改进
与Alpha版本类似,我们仍为前端和后端各指定一名
leader
,负责确立本部分的整体框架,因此,开发过程中前后端各自的开发人员仅和对应的leader
进行沟通,而前后端之间的接口规范等由两位leader
和PM一起进行沟通,这样的分层沟通方式提高了沟通效率,从而节省了宝贵的开发时间。此外,我们两天一次的例会上更多采用漫谈式的沟通,大家都会对下一步的目标发表自己的看法,详情可见 谜语人队 Scrum Meeting 博客汇总。 -
项目实际进展
观察以上两个燃尽图,我们很容易发现以下结论:
- 在5.28~5.31这段时间内由于计网考试临近,其项目进展为零,这严重影响了整体项目进度,即虽然后面的实际开发进度与预期进度相接近,但这段时间的零进度使得整体进度显著落后于预期,同时也在客观上导致了测试和发布阶段时间上的局促。
- 整体而言燃尽图表现出来的情况与我们实际的开发体验比较相符,这说明在Alpha阶段中出现的任务规划潦草的问题在Beta阶段有了很大的改善,我们充分吸取了Alpha阶段中Issue粒度过大造成燃尽图无法体现真实进度的经验,对每一个任务都进行了更加具体的Issue分割,从结果上来看也是有益的。
- 各成员实际工作量与贡献分
人员 | 岗位 | 工作量 | 贡献分 |
---|---|---|---|
GTC | PM 后端 |
完成了后端大部分的单元测试 完成了后端除可视化部分的大部分接口 完成了每周例会博客的撰写 |
51 |
MR | 后端 | 参与了部分后端的单元测试撰写 参与了部分后端接口的撰写 |
47 |
YZM | 后端 引擎 |
完成了音频类型数据集的解析接口 完成了统计模块的单元测试 完成了首页内容的编写 代码部分约700行 完成了Beta阶段大部分博客的撰写 博客部分约8000字 |
52 |
WPB | 前端 后端 引擎 |
后端:对开源hugging-face工具所支持数据集的适配,CI的配置,下载数据的记录以及本地端pip包的制作 前端:添加文本和音频类型数据集的可视化,完成数据集筛选内容,修复一些小bug后端:对开源hugging-face工具所支持数据集的适配,CI的配置,下载数据的记录以及本地端pip包的制作 前端:添加文本和音频类型数据集的可视化,完成数据集筛选内容,修复一些小bug |
53 |
LYL | 前端 | 完善前端JWT鉴权全局封装、状态管理等基础组件 负责首页模块的设计与实现 项目整体风格统一与CSS样式美化 |
49 |
LXY | 前端 | 修复画廊栏bug 完成登录模块 完成文本可视化子组件 完成反馈页面字数统计与警告 |
48 |
DSY | 前端 | 实现了管理页面的布局设计 实现了数据集、配置文件、人员、标签四个部分的增添、修改、删除、查看、排序的管理功能 增加了主页到管理页面的跳转入口 |
50 |
2.2 用户场景
- 开发前目标
总访问量达到1000人次,日访问量达到20人次,本地端下载量达到30人次
- 预期功能
模块 | 功能 |
---|---|
主页 | 提供引导、功能入口 |
管理数据集 | 查看,管理数据集 |
设置页面 | 控制个性化选项 |
反馈界面 | 用户提供反馈 |
数据集内容查看 | 查看数据集具体内容 |
数据集格式解析 | 形象解析数据集格式 |
- 发布功能
功能 | 具体描述 |
---|---|
数据集浏览 | 用户可以在主页画廊中浏览已经预支持的多种类型的多个数据集的概要信息 |
数据集搜索 | 用户可以根据关键字查找所需的数据集 |
数据集概述 | 用户可以在数据集的详情页中查看数据集的概要信息 |
数据集条目总览 | 用户可以在数据集的详情页中查看数据集条目可视化的总览 |
数据集条目详细可视化 | 目前共支持图片、文本、音频三类数据集,应用场景包括了常见的 |
数据集条目交互 | 用户可以显式控制数据集条目内可视化图层的具体显示情况 |
信息反馈 | 用户可以对现有功能和可能出现的Bug进行反馈 |
数据集筛选 | 用户可以根据标签筛选所需的数据集 |
本地端安装 | 用户可以根据需要选择安装本地端 |
数据集管理 | 用户可以添加、删除、修改本地端的数据集及数据集相关内容(包括标签等),通过观隅查看其可视化效果 |
用户管理与鉴权 | 添加了用户系统,以控制用户所拥有的权限 |
- 用户评价