软件案例分析
项目 | 内容 |
---|---|
这个作业属于哪个课程 | 2023年北航敏捷软件工程 |
这个作业的要求在哪里 | https://bbs.csdn.net/topics/613598122 |
我在这个课程的目标是 | 学习软件开发方法论,并在实践中训练开发技能和总结过程经验 |
这个作业在哪个具体方面帮助我实现目标 | 实践课程所讲授的软件分析方法论,积累对软件分析的经验 |
一、调研与评测
1.1 个人体验
首先明确我们的目标用户为中国高校大学生
与此相对应的典型使用场景有以下几种
- 搜索代码仓库,查找往届参考资料、开源组件等
- 对自己的课程作业、笔记、文档等进行版本管理
- 作为团队作业代码协作平台
根据以上三种场景,对这一网站进行使用体验
1. 资料搜索与搜集
首先进入Github首页和Gitee首页
搜索功能并不需要登录,我们可以直接通过右上角的文本框进行搜索,引导入口还是比较直观的,但是相比而言,下方的注册框更为显眼,一定程度上会引导新用户进行注册。相对而言,Gitee平台的重心更像是在toB平台,意在引导企业进行部署。
在输入框中输入BUAA并按下Enter键进行搜索, 可以搜索到相关的内容,默认展示搜索到的仓库,但是可以在左侧边栏对所希望搜索到的内容进行选择,同时在仓库搜索下,还支持筛选仓库的主要语言。在我们的应用场景下,主要是对于仓库的搜索。相比之下,Gitee的功能就较为单一,仅支持搜索仓库、Issue和博客
进入搜索到的第一个仓库,默认进入的页面是仓库的代码目录页面,两个平台的功能相差不大,目录下方会展示仓库根目录下的README.MD
文件渲染后的内容,这一功能是十分友好的,便于第一次进入仓库的人了解仓库开发者希望用户知晓的信息。
通过右上角绿色的Code按钮,我们可以下载代码到本地以供使用,也可以在登录后通过右上角的Star按钮收藏这一仓库。
在这一页面中,对下载这一常用功能的按钮使用啦不同的颜色,让用户可以一眼定位到这一功能。但是其文本描述并不那么直观,对于新用户而言不能一眼看出其所实现的功能。
相比之下,在Gitee的页面上,这一按钮的文本就能清晰体现出其功能
2. 对学习内容进行版本管理
对资料进行版本管理以及团队协作均需要登录账户,我们从创建一个用户开始体验,点击首页右上角Sign Up按钮,进入注册页面
Github注册页面使用了类terminal的UI设计,不错不错(Gitee的没有在我的审美点上)
注册功能需要逐一填写邮箱、密码、用户名、是否接受邮件广告等内容,并通过一个机器人测验
其中对密码、用户名有校验,密码强度不能过低(8位以上字母+数字或15位以上的数字)同时不能出现在网页常用密码列表中,用户名不能与原有的用户重复(大小写不敏感)
完成上述步骤后,需要进行使用邮箱验证码验证,填写团队规模、是否有教育身份、兴趣方面后即完成了注册。
相比之下,Gitee的校验就没有那么多了,但是Gitee支持自定义个人空间地址,具有更高的自由度
注册后会进入默认的Dashboard,顶栏有搜索功能以及一些Github提供的功能,左侧会展示个人的项目仓库列表,中间页面和右侧边栏则是一些资讯信息,点击左侧的Create repository按钮即可创建仓库,同样这里的创建仓库作为常用功能也使用绿色对按钮进行了高亮。
进入仓库设置,可以对仓库进行一些设置,包括仓库名称、描述、公开情况以及仓库模板和开源许可证类型,值得注意的是,仓库名称中在包含非[a-zA-Z0-9_-]
的字符时,会提示生成的对应链接中不能显示的字符串部分会用-
代替。
创建完成仓库后,会有如何与本地仓库进行绑定的教程,在完成这些工作之后,即可使用正常的git操作流程来使github作为自己的一个远程git仓库了,但是需要注意的是,因为github在2021年八月关闭了http的认证方式(悲),仅能通过ssh连接方式来进行操作,这意味着需要对ssh连接额外配置科学上网的代理。
3. 作为团队作业的协作工具
对于中国高校大学生来说,Github也会被选做一个代码协作平台,在建立了一个仓库之后,可以在Settings -> Collaborators选择向仓库中添加协作者。对于基础款来说功能较为有限,并没有区分协作者开发权限的功能(也可能是免费版没有,没有信用卡无法体验这个功能),同时免费版并没有分支保护的功能,也就是说可以随意push到master/main分支,对于学生团队开发来说很容易产生事故,虽然这样的事故并不会产生很大的经济损失。
但Github网站具有Pipeline和Webhooks能力,可以对代码仓库的变更触发自动化流程。
相比之下,Gitee的免费版就有分支保护的功能,同时支持Webhooks,但是并不具有内置的Pipeline,这一点上两者各有利弊。
个人体验总结
体验了Github网站对于中国高校大学生的三个典型场景,
总结出来其具有以下优点
- 引导与提示功能完善
- 功能入口明显,一目了然
- 常用功能通过按钮颜色进行高亮
- 不符合预期的仓库链接进行特别提示
- 仓库默认渲染README.MD文件,提供可阅读的仓库指引
- 新仓库默认显示配置方法
- 对于账户安全用心:
- 密码安全除了强度外,还额外进行了常用密码检查,提高用户密钥安全性
- 功能强大
- Github除了基本的代码仓库功能外,还具有一定的自动化能力,能有效提高自动化程度进而提高效率
- 内置成熟的WebIDE,可以省略本地环境配置等繁琐步骤
- 搜索类别更多样化,甚至支持代码的搜索
但同时也具有以下的缺点
- 功能定级划分不友好
- 对于Github免费版,并不含有设置分支保护以及合入标准的功能,个人认为这些功能相对于WebIDE空间来说更应该放入免费版中
- 对于中国访问不友好
- Github实际上并不在受限的软件之中,虽然是可以访问的,但是并不稳定
- 自从2021年关闭https的认证方式之后,只剩下了ssh访问方式,对于科学上网的配置也并不友好
用户调研
采访对象:室友,北航20级6系本科生,软件工程尚利宏老师班同学
产品栏目:搜索代码,下载代码,上传代码
总价下来对这两个软件的评价都是e.非常推荐
BUG分析
首先定义BUG严重程度
BUG等级 | 影响 |
---|---|
P0 | 严重事故,可能造成服务大规模不可用或是用户信息、财产损失 |
P1 | 事故,造成服务响应时延增加,部分边缘功能失效等影响体验的问题 |
P2 | 缺陷,边缘服务响应时延增加,或普通服务使用体验不良的问题 |
BUG1(必然发生): 在分支名中存在引号情况下,针对分支创建Codespace的防注入机制会导致镜像拉取失败
测试环境:
设备: Macbook air M1(8+7) 芯片 16G+512G版本
系统版本: MacOS 13.1 (22C65)
浏览器: Google Chrome 版本 110.0.5481.177(正式版本) (arm64)
操作步骤
- 访问个人页面下public仓库
- 在仓库中新建名称带有双引号
"
的分支 - 进入新建的分支,基于此分支建立Codespace空间
- 等待初始化
- 初始化失败,日志文件提示仓库不存在目标分支,此时显示的分支名称不含有新建分支时名称中的双引号
操作流程可见如下视频
双引号
为这一BUG定级为P2级别,原因
- 触发场景很狭窄,双引号作为分支名称的行为一般不会出现
- 造成后果并不严重,受影响的功能仅为Codespace环境无法拉取对于分支镜像,但是手动进行转移处理仍然可以操作分支
分析这一BUG的成因,其为对Codespace自动化脚本进行防注入保护的副作用
根据多组样例的测试,猜测起自动化部署脚本的防注入规则如下
在分支命名层面防止空格、反斜杠、上箭头等特殊字符的出现
删除所有的双引号
对$
、'
、反引号等特殊字符进行转义处理
因此所有的带有双引号的分支在拉取仓库时都会被实质性地修改,导致了这一BUG
这一BUG的出现原因可能有以下几点
- 测试把关不严,仅对注入进行了测试,未对防注入带来的影响进行测试
- 开发人员图便利,采用了简单的方法处理防注入,忽略了双引号的问题
- BUG实际上已经被发现,但是由于修复性价比不高,为确保安全性不进行修复
改进建议:可以将删除分支名称中双引号的操作修改为进行转义,但是修改风险较高且价值较低,需要谨慎修复
BUG2(必然发生): 在退出Github账户后仍能通过链接直接进入账户所属的Codespace
测试环境:
设备: Macbook air M1(8+7) 芯片 16G+512G版本
系统版本: MacOS 13.1 (22C65)
浏览器: Google Chrome 版本 110.0.5481.177(正式版本) (arm64)
操作步骤
- 进入已建好的Codespace页面,记录下浏览器顶部栏中的URL
- 进入Github中仓库页面,点击右上角头像下拉框中的登出按钮,此时关闭页面再次进入Github.com,发现已经不再有登录状态
- 关闭Codespace页面,关闭浏览器但并不退出
- 重新进入浏览器,输入之前记录的Codespace页面的链接,发现仍然可以进入Codespace
操作流程可见如下视频
BUG2复现
为这一BUG定级为P0级别,原因
- 这一BUG涉及到用户的代码资产,在CodeSpace中可能存有用户的私有仓库Token,获取到这一信息后可以对用户的私有代码进行拉取
分析BUG的成因,可能是由于Codespace和Github域名差异过大,Github无法管理Codespace的Cookie和缓存,导致两个站点缓存不同步,登录信息在Codespace的部分仍然保留。
这一BUG的出现原因可能有以下几点
- 开发人员粗心大意
- 测试把关不严,敷衍了事
修复建议:增加对于Codespace鉴权与Github鉴权的绑定,当进入Codespace时需要验证Github的鉴权是否还有效
二、分析
2.1 工作量分析
Github 的功能繁多,其中主要包括
- 功能完备的Git Server,能够提供代码仓库、权限管理、issue、Fork、PR等功能
- Pipeline、CI/CD支持,同时还需要提供支持这些功能的云计算算力
- Copilot代码智能联想功能,包括算法设计、训练、部署
- Code Search代码搜索
- Codespace在线IDE
由于Copilot与Code Search功能属于科技突破性的功能,我们不将其实现算入开发中,假设其已经具备可靠完善的API或SDK
同时假设1,2,5三个功能模块串行进行
则三个模块分别,预计需要16周的时间
- 市场调查、竞品分析 2周
- 需求文档撰写与评审 2周
- 系统测试样例编写与评审 1周
- 技术选型与架构设计 1周
- 详细设计 1周
- 编码开发 5周
- 测试实施与反馈修复 2周
- 验收测试与上线监控 2周
一共需要48周的时间
2.2 软件质量分析
这一软件目前处于行业领头羊地位,其久经用户的考验,在基础功能上是十分稳定的,可以说在同类产品中排第一。
但是由于其在加入了一些新的实验性功能,对于这些新的功能的质量还有待时间的检验。同时,新加入的实验性功能是否会对之前的功能产生影响也有待考量。
所以这一软件质量整体上来说可能略逊色于Gitlab和Gitee,估计排在第三位
三、建议和规划
3.1 市场概况
代码托管平台的主要用户群体为程序员群体
依据GitHub的数据,放眼全球,程序员数量已经超过7300万,比2020年增长了1700万。
直接的用户即为当今的程序员群体 + 部分需要借助代码进行科研工作的其他行业人员。
相对来说后者要远小于前者,所以暂且忽略不计。
潜在用户即在工作中需要借助代码,但是还没有接触代码版本管理平台的人员。
随着编程越来越普及,这一市场也会不断地增长
3.2 市场现状
当今市场上的用户占有量较大的产品有以下几种
- Github: 全球最流行的代码托管平台,其生态完善、认可度高,但是Copilot训练爆出的丑闻对相关其舆论评价有一定影响
- Gitee: 主要面向国内用户的代码托管平台,国内使用率高,在国内访问便捷,在国内的平台中认可度最强
- GitLab:功能齐全的Git托管平台,还兼顾私有化部署产品出售,在toB私有部署上地位较高,toC业务较为普通
- BitBucket:较为流行的代码托管平台,比较中规中矩
上述产品之间存在竞争关系,但是并不具有很强的竞争关系。
Github对于国内市场的兴趣并不是很浓厚,与之相对应的Gitee的主要市场则是在国内,两者的目标用户交集并不大,呈现一种弱竞争的关系
而Gitlab与Github之间则存在较强的竞争关系,其目标用户有较大程度上的重合,但是对Gitlab而言,其目标还有toB端的私有化部署,两者虽为竞品,但并没有到你死我活的程度
Gitlab与Gitee执教由于上述的原因,竞争关系就更小了
BitBucket与上述三者均互相未竞品,但是由于目标用的的地理显,与Gitee竞争较小。
3.3 市场与产品生态
这一软件的典型用户有
程序员群体
- 学历: 大专~博士
- 年龄:16~30岁
- 专业:常为计算机、软件工程相关专业的
- 收入: 主要在18k*16左右
- 表面需求:找到合适的代码托管分享平台,搜索合适的论子、学习他人的项目技术
- 潜在需求:通过组件复用提高效率,早点下班,通过知识仓库提升能力,避免被裁
需要编写软件的科研工作从事者
- 学历:本科~博士
- 年龄: 18~50
- 专业:主要为理工科专业,人文社科类专业也有部分
- 收入: 主要在20*12左右
- 表面需求:找到合适的计算方法,应用到实验中
- 潜在需求:被推荐所需要的算法
产品的用户群体之间是否存在一定的关系,存在一定的关联,使用软件的科学工作者往往会依赖程序员群体开发他们所需要的工具,而程序员则需要这些工作者探索出新的能与计算的领域
产品和子产品之间也有一定的关系,利于Github的存在,就为之前处于实验室的Copilot等项目提供了落地实践的机会。
3.4 产品规划
- Need:当前Github在程序员中的用户增长已经接近饱和,需要发掘非专业的编程人士的市场,由于代码在生产生活中的其他领域应用也在不断增加,这部分用户的份额也在不断加大。但与此同时,这一人群对于技术并不深入,传统的需要关键字、技术栈名词进行搜索的形式对他们来说有较高的门槛,是阻碍他们转变为直接用户的重要阻力之一
- Approach:引入GPT API进行自然语言处理,使对于代码的搜索能够接受口语化、目标化的输入。
- Benfix:这将加速对潜在用户市场的占领,同时吸引非技术领域的企业为服务付费
- Competitors:涉及到自然语言,语种的类型很重要,不同语种区域的企业在发现商机后也会开始发展自己语种的类似服务。
- Delivery:首先是借助ChatGPT应用近日的热度进行造势,同时发挥平台大用户量的优势进行推广,增大学生优惠的力度,让技术领域的平台通过学科交流密切的学校传播到别的领域。
考虑本次迭代开发增量并不大,但是由于引入了高计算量的服务,可能会对系统的稳定性和可靠性进行冲击,所以本次跌代的开发任务主要集中在架构设计与测试上。
人力安排如下
- 后端研发: 2.5个人力
- 前端研发: 0.5个人力 (由一个全栈分摊前端和后端各0.5人力)
- 美工: 1个人力 (这个确实是没办法分了)
- 测试: 2个人力 (稳定性测试和性能测试各1个人力)
时间安排如下
时间 | 研发 | 测试(性能) | 测试(稳定性) | 美工 |
---|---|---|---|---|
第1~4周 | 阅读历史版本文档与代码,评审需求、敲定新功能架构和实现细节 | 阅读历史性能测试文档,同时再次进行性能测试,确定性能基准 | 阅读历史测试报告,理解系统测试要点和规范,与PM对齐需求,确定测试样例 | 与PM对其需求,绘制原型图 |
第4~9周 | 开发 | 集成过程中对模块进行性能测试 | 集成过程中对模块进行集成测试 | 绘制提供UI素材 |
第10~12周 | 整理开发文档 | 对集成后的系统进行性能测试,对比基准的性能,评估影响 | 进行系统测试 | 归档UI素材 |
第12~15周 | 根据测试反馈对代码进行修改,不再引入新功能 | 对性能问题进行归因,辅助研发优化 | 对正确性问题进行归因,辅助研发修改 | 针对UI界面问题辅助修改 |
第16周 | 上线运行,观察监控指标 | 上线运行,观察性能指标,整理性能测试报告 | 整理本版本报告 |