[I.2] 个人作业：软件案例分析

项目 内容
这个作业属于哪个课程 https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR
这个作业的要求在哪里 https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR/homework/15609
我在这个课程的目标是 系统性的学习软件工程的知识，逐步成为一个成熟的软件开发者
这个作业在哪个具体方面帮助我实现目标 调研各领域的成品软件，了解实际的软件开发的流程

本次作业选取代码仓库管理系统进行分析，以 github 作为主要分析对象。

第一部分 调研，评测

软件评测

软件使用

这是 github 的主界面，侧边栏展示了用户最近工作的代码仓库，上边栏展示搜索框，copilot, issues, pull requests 等核心功能，主体界面有一个和智能体交谈的对话框，还有今日社区内活跃的项目推荐。

image

这是我个人觉得 github 最重要最有用的功能——新建代码仓库，可以通过主界面左边绿色的 New 按钮快捷进入。在这里可以设置仓库名称，仓库简介，仓库可见性（公共仓库或私有仓库）等。
image-1

这是我个人使用频率较高的一个功能：智能搜索。使用此功能可以在 github 上找到很多有用的项目。在主界面的搜索框输入关键字，就可以匹配上 github 中对应的代码仓库。可以按照关联性，星星数等属性进行排序，可以按照项目使用的语言进行过滤。
image-2

issues 栏目是项目的“论坛”和“任务管理板”，用于报告Bug、提出新功能建议、分配任务和进行讨论等。
image-3

软件分析

对于一般大学生使用 github 进行代码管理与合作开发的基本流程：

  • 点击主界面左边绿色的 New 按钮进入仓库创建界面，设置仓库名称与仓库简介，可以选择创建私有仓库还是公共仓库。
  • 仓库拥有者在 Settings 中邀请项目合作者，让他们拥有对于此仓库的 push 权限
  • 项目合作者对代码仓库进行初始化等操作，后续各自开发自己负责的那一部分，然后上传至仓库中。

总的来说，如果用户掌握了开发中常用的 git 指令，那么 github 可以很好的满足用户进行代码仓库管理的需求。

评测维度 优点 缺点
数据量 github 的开源社区很大，很成熟，数据量很多 海量数据中夹杂着大量废弃的、低质量的、甚至是 AI 生成的“垃圾”项目或贡献，增加了有效信息的筛选成本。
界面 界面简洁，核心功能（代码仓库管理）入口显眼 全英文界面，对于英文不好的人不太方便。此外，移动端体验明显打折。
功能 不仅提供代码仓库管理功能，而且还有智能搜索功能、copilot 等其它有用的功能。 强制推广 Copilot 引发对开源许可证的担忧，自托管运行器收费的运营模式引发用户争议
准确度 Git 的底层机制保证了代码历史的完整性和可追溯性，每一次提交、合并都准确记录。 无明显缺点
用户体验 核心流程顺畅，社区氛围浓厚，Copilot 等工具提升了用户写代码的体验 学习曲线陡峭，缺少新手引导，网络问题导致国内用户连接不能总是通畅

改进意见

增加对于开发中常用 git 指令的教学引导部分，并在新账号注册时将引导放到显眼的位置。

用户调研

本次用户调研采访的是欧阳元新班级的王琦。

  • 用户背景：北航计算机学院学生，具有非常大的代码仓库管理需求
  • 用户使用的栏目：github 的代码仓库管理功能与 copilot 功能
  • 用户遇到的问题：github 本地化程度低，用起来不太习惯；git 上手难度高
  • 用户遇到的亮点：github copilot 功能强大，对于提升编程有很大帮助
  • 用户认为需要的改进：总体来说不错，暂无改进意见。

image-5
image-6

评测结论

以下是对于 github 在某些方面的详细评分

类别 描述 评分（满分10分，良好6分，及格4分）
核心功能 对于代码仓库管理必要的功能 10
细节 为用户考虑的细节 3
用户体验 有没有不断弹出无关广告？ 8
上手难度 对新手是否友好？ 5

总体，我的 github 的评价是：好，不错。

bug 分析

以下是关于 bug 的星级所对应的意义：

  1. 一颗星：是一个功能性小 bug，触发条件苛刻或对用户的影响些微，不会对绝大多数用户带来难受的体验
  2. 两颗星：触发条件并不苛刻或对用户的影响显著，不算严重但会导致部分用户需要寻找变通方法以求正常体验
  3. 三颗星：对用户影响较严重，会拖慢工作流程但不会导致无法进行工作
  4. 四颗星：严重系统故障、服务器鉴权漏洞或重要数据泄露、用户体验较差
  5. 五颗星：致命性系统故障、致命性安全性漏洞、用户体验严重影响，可能造成大范围的服务瘫痪

bug1：移动端介绍界面显示错误

  • 操作系统环境：鸿蒙4.2.0
  • 浏览器：华为手机自带浏览器
  • 可复现性：必然发生
  • 具体情况描述：boom在移动端，介绍界面的播放组件没有给竖屏做适配，导致视频只能看到左半部分。
  • bug 分析：
    • 可能成因：前端工程师忘记了给移动端做视频播放组件的适配。开发人员大概率采用电脑进行开发，习惯了横屏的界面，而忘记了对于可能存在的使用移动端访问人员进行适配的需求。
    • 严重性：系统功能上有些微影响，安全性上无影响，用户体验上有一般影响。总体而言为一颗星。
    • bug 存留至今的原因：由于 github 是一个代码托管平台，而使用手机作为主要编程工具的人少之又少，使用移动端访问的大多数都是 github 的老用户——他们需要紧急登录完成工作；而不是新人。因此介绍界面的价值显著降低。加之移动端之间的屏幕比例差距也很大，专门为此去修改视频播放控件或录制不同比例的新视频需要耗费精力，与此界面在移动端的低价值不匹配，于是这个 bug 就保留至今了。
  • bug 改进建议：
    • 预期表现：视频应该完整的出现在手机屏幕上。
    • 改进实现：可以通过在移动端缩小视频播放界面的大小，使得其宽度可以匹配手机宽度。

bug2：CVE-2024-4985（GitHub Enterprise Server SAML 认证绕过）

此 bug 现已修复。当时如果 GitHub Enterprise Server 实例配置了 SAML SSO 并且启用了加密断言功能，在认证过程中，由于系统对 SAML 响应的验证机制存在缺陷，导致攻击者可伪造请求，绕过登录环节直接获取管理员权限。

  • 可复现性：满足特定配置条件下必然发生。

    • 发生条件：GHES 实例启用了 SAML SSO，并且开启了加密断言功能。
    • 复现步骤：
      1. 攻击者锁定一个使用 SAML SSO 且启用了加密断言的 GHES 目标。
      2. 攻击者精心构造一个恶意的 SAML 响应，其中包含伪造的断言，声称自己是一个拥有站点管理员权限的用户。
      3. 攻击者将伪造的 SAML 响应直接提交给 GHES 的认证端点。
      4. GHES 的认证处理器未能正确验证该响应的真实性和完整性，错误地将其接受为合法响应。
      5. 系统据此伪造的响应，授予攻击者站点管理员权限，攻击者由此完全控制了整个 GHES 实例，包括所有代码仓库、机密信息和 CI/CD 流水线。

  • 具体情况描述：一个未经任何身份验证的远程攻击者，通过发送特制的网络请求，就能伪装成任意用户（包括管理员）登录系统。该漏洞利用了 SAML 身份验证流程中的信任关系，通过伪造合法身份的断言来欺骗服务器。image-4

  • bug 分析

    • 可能成因：GitHub Enterprise Server 在实现 SAML 认证算法时存在缺陷。当启用了“加密断言”这一可选功能后，认证处理器未能正确验证 SAML 响应中某些元素的完整性和真实性。
    • 严重性：系统功能、安全性、用户体验上均有致命影响，毫无疑问的5星 - 致命性安全漏洞（这个漏洞曾一度被赋予 CVSS 10.0 的评分。）
    • 为何团队在发布前未修复：在功能测试中，可能只验证了标准 SAML 流程下的正常登录，而未充分覆盖攻击者视角的负面测试用例。

  • bug 改进建议

    • 预期表现：只有由可信赖的身份提供商签名和加密的、经过完整性和真实性验证的 SAML 断言，才能被系统接受并用于登录。任何来源不明、签名无效、或被篡改的认证请求，都应该被毫无例外地拒绝。
    • 改进实现：系统使用预先配置的、来自可信 IdP 的公钥，对 SAML 响应中的数字签名进行严格的密码学验证，确保其确实由受信的 IdP 签发且未被篡改。

第二部分 分析

工作量分析

模块 核心子功能 估算时间（人月）
基础代码托管 Git over HTTPS/SSH 协议实现、仓库创建/删除、分支管理、提交历史展示、文件浏览、Diff可视化 8-10
协作核心 Pull Request全流程、Issue跟踪系统、@提及通知、跨仓库引用 6-8
用户与权限 用户认证、组织管理、团队权限模型（仓库级/分支级）、SSH密钥管理 4-6
前端与UI 仓库首页、PR列表、代码浏览、Markdown渲染、移动端适配 5-7
基础设施 高可用架构设计、数据库分库分表、Git存储优化、监控告警系统 8-10
合计 - 31-41

考虑到团队 6 人之间的配合问题，最终实现 github 的基本功能大约要 8 到 10 个月。

软件质量分析

优劣分析与行业排名

优点

  1. 拥有超过1亿个仓库和4000万开发者，形成网络效应。任何开源项目首选GitHub。
  2. Pull Request + Issue的工作流已成为行业事实标准。开发者无需学习即可上手，大幅降低跨项目协作成本。
  3. 82%的大型企业采用GitHub Copilot Enterprise，因其与现有开发流程无缝集成。

缺点

  1. 对于国内开发者，GitHub的访问速度和稳定性存在不确定性，有时影响日常使用。
  2. 大量低质量AI生成的PR/Issue涌入，给开源项目维护者带来巨大审查负担。

综合来看，github 在代码仓库管理系统的各类产品中排名第一。

第三部分

市场现状

市场概况

  • 直接用户：平台拥有超过 1.8 亿注册开发者，超过 4.2 亿个代码仓库。GitHub 企业版服务了超过 10 万家组织，包括 90% 的财富 100 强公司。
  • 潜在用户：全球的专业开发者与编程爱好者皆为其潜在用户。东南亚、非洲的开发者数量正在快速增长，是未来用户增量来源。

竞争产品

产品 类型 主要市场 核心特点
GitHub 国际通用平台 全球 开源生态、Copilot AI、Actions 自动化、微软生态
Gitee 本土化平台 中国 国内访问快、符合中国法规、企业版功能
GitCode 本土化平台 中国 依托 CSDN 社区、AI 辅助功能、轻量级

产品定位

GitHub

  • 定位：全球开发者协作与创新中心，以开源为核心，为企业提供从代码托管到 DevOps 的全流程服务。
  • 优势：
    • 全球最大的开发者社区，形成网络效应，新项目首选 GitHub。
    • 丰富的生态系统：GitHub Actions、Copilot、Packages、Codespaces 等深度集成。
  • 劣势：
    • 国内访问速度不稳定，部分地区甚至无法访问。
    • 本地化支持不足。
    • 面对中国数据安全法规，部分国内企业使用受限。

Gitee

  • 定位：中国本土化的代码托管与协作平台，服务国内开发者和企业。
  • 优势：
    • 国内访问速度快，无网络障碍。
    • 符合中国网络安全法规，数据留在国内。
  • 劣势：
    • 国际影响力小，海外项目几乎不在 Gitee。
    • 社区规模和活跃度远低于 GitHub。
    • 部分功能模仿 GitHub，创新不足。

GitCode

  • 定位：CSDN 推出的代码托管平台，强调 AI 赋能和开发者社交。
  • 优势：
    • 依托 CSDN 庞大的中文开发者社区，引流能力强。
    • 国内访问速度快，无网络障碍。
    • 与 CSDN 博客、问答社区打通，形成内容+代码闭环。
  • 劣势：
    • 成立时间较短，用户规模尚小。
    • 缺乏大型开源项目入驻，生态积累不足。
    • 企业级服务案例较少。

竞争态势

维度 GitHub Gitee GitCode
全球市场 绝对主导 几乎无 几乎无
中国市场 受限，但仍有大量技术爱好者使用 占据本土企业及高校主流 依托 CSDN 快速渗透
企业客户 跨国公司、出海企业首选 国内大中型企业首选 CSDN 生态客户
开源项目 拥有全球所有顶级开源项目 国内部分项目同步到 Gitee 少
AI 能力 Copilot 领先，深度整合 基本无 基础 AI 辅助，仍在探索

市场与产品生态

核心用户群

  • 学历：本科及以上
  • 年龄：17 到 35 岁
  • 专业：计算机科学与技术、软件工程、网络安全、人工智能等
  • 爱好：编程
  • 表面需求：需要一个功能齐全的代码仓库管理系统，需要高效率的编程辅助软件。
  • 潜在需求：需要更加智能的代码审查功能，需要过滤掉 AI 生成的低质 PR

用户生态

核心用户群大多是计算机相关行业从业者或计算机相关专业学生。github 形成了全球最大的开发者社区，用户生态非常好。

产品生态

github 的子产品包括 github copilot，github codespaces，github actions 等。这些产品分别聚焦于编程辅助，开发环境模拟，工作流自动化，服务于软件工程的从开发到测试到部署的每一个步骤，具有是否强的产品生态。

产品规划

新功能设计

GitHub Maintainer Copilot（维护者助手），用于帮助开发者自动过滤由 AI 生成的低质 PR 与 Issue。

  • N（Need，需求）：开源项目维护者正面临日益严重的“低质量贡献洪峰”问题。随着 AI 生成代码的普及，大量自动生成的 PR和 Issue 涌入仓库，这些贡献往往缺乏说明、测试，甚至逻辑错误。维护者需要花费大量时间人工筛选和反馈，导致疲劳、效率下降，甚至弃坑。GitHub 社区中已有多起维护者呼吁平台提供官方工具来管理这一现象。
  • A（Approach，做法）： 在 GitHub 仓库设置中引入 Maintainer Copilot 功能，包含以下核心能力：
    1. 智能质量评分：当新 PR 或 Issue 创建时，自动调用基于海量历史数据训练的 AI 模型进行评分，评估其完整性、清晰度和潜在价值。评分维度包括：描述长度、是否包含测试、是否引用相关 Issue、代码风格等。
    2. 自动标记与建议：对低质量贡献自动添加标签（如 ai-generated、needs-improvement），并回复预设的改进建议模板，引导贡献者补充信息。
    3. 可配置规则：维护者可自定义规则，并选择 AI 模型的严格程度。
  • B（Benefit，好处）：
    1. 节省维护者时间：将人工筛选转化为自动化处理，让维护者专注于真正有价值的核心贡献。
    2. 提升项目健康度：减少垃圾信息在 Issue 和 PR 列表中的堆积，使讨论更聚焦。
    3. 引导社区规范：通过即时反馈，教育贡献者（包括 AI 使用者）如何提交高质量贡献，长期提升社区质量。
  • C（Competitors，竞争）： GitLab 目前没有原生 AI 贡献评估功能，但可通过第三方插件实现部分功能，集成度不高。 Gitee，GitCode 等国内平台暂无此功能。
  • D（Delivery，推广）：先以公开 Beta 形式邀请部分知名开源项目试用，收集反馈后逐步推向所有用户。

团队角色配置

角色 人数 主要职责
后端开发 2 负责 API 设计、数据库建模、AI 模型集成、评分服务开发、与 GitHub 现有系统对接。
前端开发 1 负责新功能交互界面的开发，与后端联调。
算法工程师 2 负责训练和维护 AI 评分模型。
测试工程师 1 负责编写测试用例，进行功能测试、性能测试、兼容性测试。

详细规划

周次 阶段 主要任务 产出/里程碑
1 需求与设计 产品经理调研开源维护者痛点，收集典型项目数据；团队共同讨论功能范围。 需求文档初稿，MVP 功能列表
2 需求与设计 产品经理编写详细用户故事和验收标准，技术团队评估技术可行性。 技术方案评审通过
3 开发准备 搭建开发环境，配置 CI/CD 流水线；算法团队开始清洗历史 PR/Issue 数据，构建训练集。 开发环境就绪，数据集初版
4 开发第 1 周 后端开发：实现仓库设置页面的 API。前端开发：搭建设置页面的基础 UI 框架。 设置页面可配置并保存
5 开发第 2 周 算法工程师完成基线模型训练，提供本地推理 demo。测试工程师编写功能测试用例，开始自动化测试搭建。 基线模型可用，自动化测试框架初步
6 开发第 3 周 后端开发：实现 PR/Issue 创建时的评分逻辑。 PR/Issue 创建时可触发评分
7 开发第 4 周 算法工程师优化模型，提升准确率；后端集成模型服务，完成评分存储。测试工程师进行集成测试。 评分模型集成到后端
8 开发第 5 周 后端开发：实现自动打标签功能。前端开发：完善交互界面。 自动打标签功能可用
9 开发第 6 周 前端开发实现批量操作交互；后端支持批量接口；测试工程师进行测试。 批量操作功能完成，测试通过
10 开发第 7 周 算法工程师根据反馈微调模型；开发团队优化性能。 模型 v2 版本上线，性能优化完成
11 内部测试 测试工程师进行安全测试、压力测试。前后端进行 bug 修复 内部测试报告，修复发现的 bug
12 公测准备 邀请 5-10 个知名开源项目参与封闭测试；准备文档和帮助中心内容。 公测计划，文档初稿
13 公测第 1 周 发布公开 Beta 版本，仅对受邀项目开放。产品经理收集用户反馈，团队快速响应 bug 修复。 公测反馈汇总，紧急修复版本
14 公测第 2 周 根据反馈调整功能；开始准备正式发布宣传材料。 功能调整完成，宣传材料初稿
15 正式发布准备 完成最终测试；发布博客和帮助文档。 发布就绪检查清单
16 正式发布 正式向所有 GitHub 用户推出 Maintainer Copilot 功能；同步发布博客、社交媒体宣传。 功能正式上线，首周数据监控
posted @ 2026-03-18 00:30  cwz2024  阅读(83)  评论(0)    收藏  举报