软件案例分析

hua0x522

已于 2023-03-05 16:31:48 修改

阅读量173

点赞数

文章标签：软件工程

于 2023-03-05 14:52:15 首次发布

本文链接：https://blog.csdn.net/qq_43150198/article/details/129346060

版权

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程
这个作业的要求在哪里	软件案例分析
我在这个课程的目标是	学习软件工程的理论并应用于实践
这个作业在哪个具体方面帮助我实现目标	通过分析市场上流行的软件汲取前人的经验

第一部分调研，评测

我选择的分析对象是 GitCode 和 GitHub 两款产品，它们都属于代码仓库管理系统。其中，GitCode 是 CSDN 为开发者提供的开源项目创新服务平台，是中文代码仓库管理系统的后起之秀。而 GitHub 是国际知名的代码托管平台，上线已经十余年之久，2018年被微软收购，资金充足。

1.1 软件评测

我们对软件进行评测需要遵循一定的指标，根据《构建之法》第8章需求分析中提出的功能分析四象限，将用户的需求分为 必须需求 和 辅助需求，将产品的功能分为 杀手功能 和 外围功能 。

产品功能我将在体验后总结，首先列出我认为的代码仓库管理系统应该满足的用户需求：

必须需求：

安全可靠的代码仓库
支持版本管理和协作开发（commit, fork, pull request, merge, …）
支持本地与远程仓库的连接（push, clone, …）
更方便地测试、部署（CI / CD）

辅助需求：

简约美观的UI设计
Web IDE 作为应急
社交功能

GitCode

GitCode 与 CSDN 共享一套账号，如果已经在 CSDN 中登录了，打开 GitCode 网页后即可直接同步登录。与之前需要关注公众号相比，更加方便简洁，但是 CSDN 的账号中的问题也随之带到了 GitCode 之中。

CSDN 的账号中有 用户昵称 和 用户ID 两个名字，其中用户ID 是没法修改的，早期注册的用户会一直顶着 wx_xxxx，qq_xxxx 这样的 ID，让用户产生负面情绪。而且用户昵称和用户ID 在前端会出现混用。

相关问题：https://blog.csdn.net/sculpta/article/details/104157312

登陆后跳转到 GitCode 的首页，看到网上有对导航栏配色的吐槽，但我个人认为可以接受，而且 GitCode 的 logo 中 “G” 的猫耳，设计得很有意思，算是对 GitHub 的致敬。看完UI设计后，我创建一个仓库为例，测试 GitCode 的必需功能。

创建项目，添加项目描述，设置可见性级别。 GitCode 免费提供私有仓库，好评！

我在本地创建了一个 Vue 框架的 demo 项目，利用 ssh 连接到 GitCode 的远程仓库上，将本地的内容 push 到仓库中，一切正常。下一步我尝试在本地模拟团队开发过程：创建新的分支、修改内容、提交 commit 并 push 到远程仓库、提出 merge request、merge branch。

远程仓库看到新的分支，可以看到右上角 GitCode 检测到新分支后自动给出了 创建合并请求 的建议。

创建合并请求时，可以指定审核者，这里选定为我自己。之后，我就可以审核这个 merge request。此外，审核者会收到系统消息提示有了新的任务。

审核合并请求时可以通过 GitCode 自带的 IDE 来审核代码，审核通过后即可合并。除了这个Web IDE，我发现 GitCode 还提供了一个 Cloud IDE。

Cloud IDE 的样式与 VS Code 完全一致，猜测是对 Web版的 VS Code 的移植。个人体验了一下，连接速度还行，虽然操作会有延迟，但不易察觉，影响不大。代码补全和函数跳转速度都较快。

我们可以在终端输入命令来查看配置：

$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="20.04.4 LTS (Focal Fossa)"

$ lscpu
Thread(s) per core:              2
Core(s) per socket:              8
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           106
Model name:                      Intel(R) Xeon(R) Platinum 8338C CPU @ 2.60GHz

Web IDE 在一些特殊情况下有很大作用，如出差、电脑损坏、开发平台不适配、学生初学Linux等等。

而且，服务器竟然对普通用户开放 sudo权限

相比于其他代码托管平台，GitCode 有一个很新颖的独创之处——代码片段。它就像一个帖子一样，可以把随手写的代码粘贴上去，再配上几行文字说明，就能发布出去。这个功能很有 CSDN 的风格，因为 CSDN 的博客往往就是程序员们在与各种各样的bug大战之后，随手记下来的代码和文字。这些碎片一样的帖子供后人学习，让后来者少走了许多弯路。

目前这个功能的用户并不多，但是已经有很多人用来当作题解或者算法模板了。我个人很看好这一用途，建议 GitCode 可以考虑跟各大OJ网站合作，把代码片段开发成最大的题解平台，这样能起到很好的引流效果（毕竟绝大多数程序员都刷过算法题呀）。

最后，我还尝试了DevOps功能，但是在配置 CI/CD 的yml文件时出现了问题，这一部分放到 Bug分析 去讨论。

GitHub

GitHub 是我最早接触的平台，也是名气最大、用户最多的代码托管平台。由于许多计算机领域开源的最新研究成果都会选择在GitHub平台展示自己的项目，所以大学的老师、学生们也往往对其青睐有加。

但是对于中国大陆的用户来说，使用 GitHub 还存在着安全隐患。一是目前中国大陆地区连接 GitHub 经常出现的网络问题，日后 GitHub 是否会被墙不好判断；二是俄乌战争爆发后 GitHub 及其背后的微软的站队行为让我们意识到技术和开源也是有国界的，中美冲突是否会影响 GitHub 的使用我们不得而知。

抛开政治问题不谈，我们还是按照上述 GitCode 的思路来体验 GitHub，由于之前已经使用过，且一些部分和 GitCode 相似，我会选择性忽略一些冗余的步骤。

在我原来的项目中新建一个分支，修改内容，提交代码，push到远程仓库，GitHub 上同样会显示 PR 的建议。

与 GitCode 不同的是，GitHub 不允许指定自己为 Code Reviewer，默认你在提交之前已经自己给自己做过代码复审和测试了。

在代码审核这一步骤中，GitHub 并没有提供Web IDE，只是简单地把 diff 结果显示出来。

如果这个项目配置了 GitHub Actions 的话，每个 PR 都会自动触发 Actions，通过自动测试后，按钮会变成绿色，reviewer 就可以把分支合并了。我之前从未接触过 CI/CD 的脚本配置，所以想尝试一下 GitHub Actions，看看它的 CI/CD 生态是否强大到开箱即用。

我直接选择了推荐的第一个 CI 模板，根据其内容可以知道测试了 nodejs 环境和项目能否成功 build。

顺利通过测试。

GitHub Actions 的强大之处体现在它的生态之上。作为代码托管平台的老大哥，它能够提供各式各样的 Actions 模板供开发者选择，方便开发者尽快地测试和部署。相较而言，GitCode 还只能提供一个空白的yml文件，要求开发者自己去编写。

受到 GitCode 的 Cloud IDE 的启发，我在 GitHub 上找到了类似的功能，Codespaces。但是效果不尽人意。由于服务器在国外， Codespaces 的延迟较高，而且 CPU 配置比 GitCode 的 Cloud IDE 低很多。此外，我没有在代码仓库中找到 Codespaces 的接口，可能每次使用还需要 clone 下来才能操作。

用户采访（其他软工班级学生）

采访对象背景：我采访了一位欧阳老师班的同学，该同学经常使用 GitHub 来完成项目开发和科研学习工作。

软件评价

GitCode 的杀手功能：代码片段，Cloud IDE

GitHub 的杀手功能：GitHub Actions，庞大的用户量和社区

功能	GitCode	GitHub	GitCode得分	GitHub得分
安全可靠的代码仓库	源码级别的安全分析 & 协议分析平台	代码仓库足够安全，但是中国地区的服务可能受政治影响	20/20	16/20
版本管理和协作开发	满足正常需求	满足正常需求	15/15	15/15
支持本地与远程仓库的连接	满足正常需求	满足正常需求	15/15	15/15
更方便地测试、部署	出现了严重的Bug	GitHub Actions 生态丰富	12/20	20/20
简约美观的UI设计	商业气息很重	简约美观	8/10	10/10
Web IDE 作为应急	功能强大，服务器配置高	网络延迟高,服务器配置低	10/10	6/10
社交功能	与 CSDN 的结合有待探索	最庞大的社区和最多的开源明星	7/10	10/10

GitCode 最终得分：87 评价：d）好，不错

GitHub 最终得分：90 评价： e）非常推荐

1.2 Bug分析和提交

Bug分析这一部分，我选择的是前文分析的 GitCode 代码仓库管理系统。

Bug 量化标准

星级	描述
5	严重影响用户代码安全，泄露公司商业机密
4	导致系统部分功能无法使用，严重影响用户体验
3	不涉及核心功能，但对用户体验有严重影响
2	用户能够通过自行操作恢复，不影响正常使用
1	UI设计或前端显示有问题

测试环境

使用设备：MateBook 14

处理器：Intel® Core™ i5-10210U CPU
内存：16 GB
操作系统：Windows 10 家庭中文版 21H2
浏览器：Chrome 110.0.5481.178

Bug1：没有中文用户引导，前端内容错误

Bug可复现性： 必然发生

Bug具体情况描述： GitCode 支持从 GitHub 导入项目，但是 GitCode 作为面向中文用户的代码托管平台，在引导用户连接 GitHub 时竟然没有中文，具体的步骤都是英文描述。此外，前端内容 “需要授权 GitLab 访问你的 GitHub 仓库列表” 中出现 “GitLab”字样，就像 Harmony OS 中有 Android 字样一样有争议。

Bug分析：

可能成因： GitLab 是一个开源的代码托管平台，主要面向企业使用。猜测 GitCode 的某些实现参考了 GitLab 的公开代码，但是一些英文界面还没完善成中文界面。
严重性： ⭐ GitHub 用户自然懂英语，只是这会使得用户质疑 GitCode 的专业性和可靠性
未被修复原因： 开发人员粗心大意，没有考虑用户的实际体验和对公司形象造成的影响。

Bug改进建议： 将原来的英文引导全部改成中文，去掉 GitLab 字样。

Bug2：代码仓库标签没有限制长度

在这里插入图片描述

Bug可复现性： 必然发生

Bug具体情况描述： GitCode 支持为代码仓库添加标签，添加标签的方式是输入一个字符串，按回车，然后就能生成标签。但是开发者没有考虑输入的字符串可能很长，会导致显示的标签也很长，而这个标签是所有用户都能看到的，进而降低用户的使用体验。这里虽然是故意使用长字符串攻击，但是日常使用不排除剪切板异常等问题导致的长标签错误。

Bug分析：

可能成因： 前端人员在实现此功能的时候没有限制输入字符串的长度，更大的问题是功能设计的缺陷。
严重性： ⭐⭐ 影响网页美观，同时也不利于提高按标签检索的质量
未被修复原因： 测试人员未进行充分的前端测试

Bug改进建议： 这种输入字符串来添加标签的方式本身就不合理。标签与其他文本不同，本身就有一个固定的集合，应该做成一个标签集合让用户选择添加，而不是让用户自己编辑标签。这样既可以节省服务器存储成本（只需要存一个标签下标），又方便数据库查询操作。毕竟标签的本质就是为了快速分类。

Bug3：查看 CI 文件导致系统崩溃

Bug可复现性： 必然发生

Bug具体情况描述： 我尝试用 GitCode 提供的 DevOps 工具，由于 GitCode 不提供 CI 模板，于是我直接复制了上文提到的 GitHub Actions 中的 CI 脚本，生成了 .codechina-ci.yml 文件。然而，当我在代码仓库中点击此文件试图浏览它的具体内容时，网页竟然直接崩溃了。这个代码仓库链接如下：

https://gitcode.net/qq_43150198/funny-vue

yaml file 内容如下：

name: Node.js CI

on:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [14.x]
        # See supported Node.js release schedule at https://nodejs.org/en/about/releases/

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

Bug分析：

可能成因： 完全没有头绪，不理解为什么只是查看文件就能够稳定地导致网页崩溃
严重性： ⭐⭐⭐⭐ 可能会导致 DevOps 完全无法使用，甚至代码仓库无法访问和使用
未被修复原因： 也许是我上传的 yml 文件内容的特殊性才引发的Bug（上传空文件不会发生此Bug），所以测试人员才没有测出来。

Bug改进建议： 希望开发人员和测试人员能够认真对待这个Bug，因为无论文件内容的正确与否，查看文件内容都不应该影响网页。

Bug4：无法识别本地开发用户

在这里插入图片描述

Bug可复现性： 必然发生

Bug具体情况描述： 在试用 GitCode 时，这个仓库只有我一个人在维护，但是利用 GitCode 的统计工具发现作者人数竟然有两个。我对此感到不解，于是翻找了 commit 记录，发现了一个 GitCode 的Bug。可以看到commit 记录中确实有两位作者，hua0x522 是我的 GitCode 用户名，而 wxz 是我本地 Git 的用户名。GitCode 居然把本地和网页的操作算作两位开发者。而且点击 hua0x522 的头像能够跳转到我的用户信息，但是 wxz 的头像点击后没反应。这说明 GitCode 并没有认出本地开发者是谁。

Bug分析：

可能成因： 我使用 ssh 远程仓库进行开发，猜测 GitCode 没有根据 ssh 密钥来把本地开发者和 GitCode 用户进行匹配。经过测试，GitHub 是支持这一功能的，因此，技术上并不存在问题。
严重性： ⭐⭐ 不影响个人或小团体的正常使用，但是对于开源公司的数据统计会有影响
未被修复原因： 测试人员没有检查 commit 记录

Bug改进建议： 向 GitHub 学习，具体技术应该就是 ssh 密钥的匹配，将本地开发者和 GitCode 用户对应起来。

Bug5：Issue 附件图片无法加载

Bug可复现性： 必然发生

Bug具体情况描述： 在我整理了一下 GitCode 的Bug 准备提 issue 的时候，戏剧性的一幕出现了，issue 的上传图片功能也有 Bug。具体表现为：点击上图中 “拖放或者上传设计附件” 后，图片无法加载出来，而且issue 发布后也看不到图片。

Bug分析：

可能成因： 可能是并没有实现图床功能，而是直接引用了url，这样本地的图片自然无法显示。
严重性： ⭐⭐⭐ 图片是重要的交流方式，不支持本地图片会严重影响用户体验，尤其是当你的UI显示支持的时候，这种心理落差会进一步降低用户的好感。
未被修复原因： 很明显的Bug，不理解为什么没有修复，也许是图床功能不好做

Bug改进建议： 增加图床功能

虽然不支持本地图片，但是markdown天然支持网络上的图片，我个人的做法是先在 GitCode 上开一个仓库，把图片全部传上去，然后就可以直接引用链接了。本文的所有图片也存储在 GitCode 仓库中。

Bug反馈

已经将相关 Bug 反馈到 GitCode 相关 issue。

第二部分分析

继续选择 GitCode 作为分析对象

工作量分析

体验了 GitCode 的所有功能，大致如下：

版本控制功能
合作开发功能
Web IDE功能
问题跟踪功能
代码片段功能
仓库检索功能
消息通知功能

GitCode 作为成熟企业开发的大型网站，功能齐全，内容量大，预计学生团队需要 47周才能完成。而且由于硬件资源受限，很多功能会大打折扣。

时间表：

需求分析、产品调研：3 周
对产品功能进行细分，设置milestone，撰写文档：2周
后端开发基础功能，前端设计和开发UI和交互：10周
前后端协同开发，在小集群上交付 alpha版本：20周
后端部署到大规模服务器上，前端测试功能：5周
前后端协同测试，交付Beta版本：5周
小范围用户试用：2周
交付最终版本

软件质量分析

分析这个软件目前的优劣(和类似软件相比)，这个产品的质量在同类产品中估计名列第几？

根据前文比较 GitHub 和 GitCode 的量化标准，经过对比，GitCode 的质量在同类产品中估计排名第 3

GitHub > GitLab > GitCode > Gitee > GitLink

从各方面的问题，推理出这个软件团队在软件工程方面可以提高的一个重要方面(具体建议)。

从之前的 Bug分析环节可以发现，目前 GitCode 存在的 Bug 还有很多，开发团队并不是很成熟。建议团队可以采用《构建之法》中提到的 “eat dog food” 方式，将公司的大部分代码都托管到自己的平台上，开发人员也都在自己的平台上进行开发，用自己的DevOps进行测试和部署。这样对于软件的测试更加全面高效。

第三部分建议和规划

市场概况

首先市场有多大？

根据 GitHub Octoverse 统计数据，全球共有 9400万开发者在 GitHub 上注册账号，而且去年一年时间增长就达到了 2050 万位开发者，年增幅高达 27%。可以看到，随着计算机技术的发展，代码仓库管理系统的市场空前巨大，而且还在上升期。

其次直接的用户有多少？潜在的用户又有多少？

根据 GitCode 给出的数据，其用户量达到了 120万，然而，作为面向中国用户的代码仓库管理系统，其潜在的用户远不止这些。

根据 GitHub 的数据，其2022年新增的中国用户就达到了 120万，根据其他渠道数据，其中国用户总量在 775万左右，说明中国用户使用代码仓库管理系统的人很多，如果 GitCode 能把面向中国开发者的代码仓库系统做大做好，就能够获得数倍于现在的用户。

市场现状

目前市场上有什么样的产品了？

国外成熟产品：GitHub，GitLab

国内竞品：GitCode，Gitee，GitLink

上述产品的定位、优势与劣势在哪里？

GitHub：上线时间最早，用户最广泛，社区众多，适合个人开发者和小型团队
GitLab：更注重安全性，CI / CD 更强大，适合大型企业
GitCode：面向中国开发者的产品，定位对标 GitHub
Gitee：面向中国开发者的产品，定位对标 GitLab
GitLink：由CCF牵头创办，主要用于高校的教学活动

上述产品之间呈现什么样的关系，哪些为竞品关系？以及竞争中的各方态势如何？

国际大环境下：GitHub 和 GitLab 为竞品关系，一方依靠庞大的社区成为用户量最多的代码仓库管理系统，一方依靠为企业特殊定制服务成为很多大型企业的选择。

国内小环境下：GitCode 和 Gitee 为竞品关系，双方都希望做成面向中国用户的代码仓库管理系统。而 GitLink 由于有 CCF 坐镇，并不急需实现商业上的成功，与前两者的没有直接的竞争关系。

市场与产品生态

这个产品的核心用户群是什么样的人？典型用户是什么样的？学历，年龄，专业，爱好，收入，表面需求，潜在需求都是什么？

GitCode 的核心用户群是中国的开发者。

典型用户特征：

学历：初高中竞赛生、大学生
年龄：18 ~ 25
专业：计算机科学与技术、软件工程
爱好：写代码，开发小型项目并分享
收入：较低，具体数据难以统计
表面需求：中文界面，正常的Git功能
潜在需求：社交功能

产品的用户群体之间是否存在一定的关系？是否有利用其相互作用二次构成特定用户生态的可能性？

程序员天然的会形成一定的社区，因为这个行业推崇经验分享，提倡开源精神。这一点 CSDN 就做得不错，已经成为国内最知名的开发者社区了。但是 CSDN 的经济压力是很大的，如何才能平衡开源精神和企业营收，是个值得思考的问题。作为 CSDN 寄予厚望的新产品， GitCode 能否像 GitHub 那样建立起庞大的社区，一要看 CSDN 做开源的决心，二也要看国内资本是否会向微软学习，为开源的发展投入资金。

产品的子产品，以及其他相关产品之间是否存在一定的关系？是否有利用各个产品特性之间的相互关系二次构成产品生态的可能性？

CSDN 和 GitCode 账号互联，功能上也有很强的相关性。一个是活跃的中文开发者社区，一个是中文的代码仓库管理系统，如果未来能开发出更多相辅相成的功能，不仅能打造产品生态，还会增加用户粘性。

产品规划

你要在当前软件的基础上设计什么样的新功能？为何要做这个功能，而不是其他功能？为什么用户会用你的产品/功能？你的创新在哪里？可以用NABCD分析。

新增 DevOps 模板功能。

原因：而且有 GitHub 珠玉在前，可以进行一些参考。其他功能相对来说没有 DevOps 这么核心。

NABCD分析：

Need： DevOps 是团队开发大型项目中不可或缺的工具。

Approach： 在 DevOps 功能中通过分析仓库的语言类型，自动推荐一些 DevOps 模板，同时提供关键字检索功能，让开发者按需挑选。

Benefit： 能够很大程度节约团队的测试、部署时间。

Competitor： 有 GitHub 珠玉在前，可以参考借鉴，减小和 GitHub 的差距。

Delivery： 借住 CSDN 平台推广新功能，同时也要利用好微信、QQ、知乎等宣传渠道。

如果你是项目经理，可以招聘6个人，并且有4个月的时间，你认为应该如何配置角色(开发，测试，美工等等) 才能在第16周如期发布软件的改进版本，并取得预想中的成绩。

我认为应该招聘1名美工，1名前端开发人员，4名后端开发人员。由于6名成员人数较少，且时间还算充裕，我认为可以让开发人员兼任测试。

请为你的团队设计16个周期每周的详细规划。

时间	规划
第 1 周	调研 GitHub 等现有功能的实现
第 2 周	调研 GitHub 等现有功能的实现
第 3 周	美工与前端沟通UI设计，后端开始开发 DevOps脚本
第 4 周	美工与前端沟通UI设计，后端开始开发 DevOps脚本
第 5 周	美工与前端沟通UI设计，后端开始开发 DevOps脚本
第 6 周	美工与前端沟通UI设计，后端开始开发 DevOps脚本
第 7 周	美工与前端沟通UI设计，后端开始开发 DevOps脚本
第 8 周	美工与前端沟通UI设计，后端开始开发 DevOps脚本
第 9 周	前端测试，后端开发推荐系统
第 10 周	前端测试，后端开发推荐系统
第 11 周	前端测试，后端开发推荐系统
第 12 周	前端测试，后端开发推荐系统
第 13 周	前后端协同测试
第 14 周	前后端协同测试
第 15 周	前后端协同测试
第 16 周	前后端协同测试