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

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

项目	内容
这个作业属于哪个课程	北航2026年春季软件工程
这个作业的要求在哪里	[I.2] 个人作业：软件案例分析
我在这个课程的目标是	接触理解应用现代软件工程常用的开发方式，锻炼自己编写代码以及团队协作的能力
这个作业在哪个具体方面帮助我实现目标	通过分析真实软件样例，结合教材中的理论知识与实际经验，掌握现代软工的真实需求

• 选题类别：代码仓库管理系统
• 分析软件：github
• 对比软件：gitee

第一部分 调研，评测

软件评测

软件使用

登录的界面做的很好看

登录进去之后就能看到自己的主页，包括copilot的交互界面、自己follow过的用户的近期活动，左边还可以看到自己拥有的仓库

这里是创建仓库的页面，可以创建仓库，配置一些基础设置

仓库建好了就是这样

点击到issue栏，可以看到已经对这个仓库发布过的issue。这里我们是新建仓库所以没有，我们new一个issue

把issue内容填写好，右边可以把issue指派给团队中的某个人，并设定好这个issue的类别

issue内容填写好并发布，大家就都可以在这个界面查阅issue了

日常工作的时候，通常都不会直接修改main分支中的代码，而是新建一个分支再merge。这里我们新建分支并切换到其上去

点击add file，就可以看到这个界面，然后就可以在线编辑代码。github可以自动识别文件后缀名，然后在文件编辑的时候给予代码高亮，整体体验还是不错的

如法炮制测试文件和CI/CD文件，实现github action

如此就可以实现自动化部署测试，github action已经为我们测试好了

之后就是发起pull request，申请合并分支了，这一步一般是由仓库管理员审核通过后才可以进行

这里分支就被合并了，我们去观察一下main分支里是什么状态

可以看到main分支里就出现了这些文件，合并成功了！

最后一步就是删库跑路，需要严谨确认之后才可以删除仓库

软件分析

GitHub 提供了一套从需求提出到代码上线的完整流程。其基本标准工作流可拆解为以下五个阶段：

1. 项目初始化：
   • 流程： 用户通过表单化的界面创建代码仓库施。
   • 价值： 确立了项目的代码边界和协作规则规范。
2. 需求与缺陷管理：
   • 流程： 产品经理或开发者通过提出 Issue，描述需求，并通过右侧边栏分配责任人和设定标签。
   • 价值： 实现了任务的结构化和可视化追踪。
3. 分支开发与版本控制：
   • 流程： 开发者基于主干拉取特性分支，在独立环境中编写业务代码和测试用例，并提交修改。
   • 价值： 保证了主干代码的稳定性，实现了多人并行开发。
4. 持续集成与自动化测试：
   • 流程： 开发者提交 .github/workflows/ci.yml 脚本。触发器感应代码推送后，云端 Runner 自动拉取环境、执行 pytest 单元测试，并在控制台实时输出日志。
   • 价值： 极大地降低了人工测试成本，防止缺陷代码流入主干。
5. 代码审查与自动化闭环：
   • 流程： 发起合并请求。当自动化测试通过后，执行合并操作，系统自动关闭对应的 Issue。
   • 价值： 完成了代码审查-测试-需求验收的闭环。

能够解决用户需求。 GitHub 解决了软件开发团队面临的代码版本混乱、测试环境不一致、需求追踪断层的痛点。它将 Git 的底层命令行操作，包装成了一套流畅、可视化的产品工程流水线。

基于本次体验，我们从以下五个维度对 GitHub 进行深度评测：

1. 数据量与性能

• 优点：极高的吞吐量与云端算力。
  • 作为全球最大的代码托管平台，其拉取/推送代码的速度非常稳定。
  • GitHub Actions 的秒级调度：在触发自动化流水线时，云端分配一台全新的 Ubuntu 虚拟服务器几乎在几秒内完成，无需用户排队等待，展现了其强大的底层资源池调度能力。
• 缺点：大文件存储成本高。
  • 对于包含大量非文本资源的项目，Git 原生的机制并不友好，需要额外配置 Git LFS，增加了学习成本。

2. 界面设计

• 优点：信息层级清晰，强调内容即界面。
  • 仓库首页上方是清晰的导航，下方直接渲染 README 文件，使得项目文档一目了然。
  • 代码变更对比界面采用经典的红绿底色区分增删代码，对代码审查极其友好。
• 缺点：移动端体验局限。
  • 虽然 GitHub 提供了移动端 App，但复杂的分支合并、长篇代码的审查和 YAML 文件的编辑，在手机小屏幕上依然显得捉襟见肘，它本质上仍是一个重度依赖桌面的工具。

3. 功能完备度

• 优点：高度集成的生态闭环。
  • 最大的亮点是 Issue 自动化闭环。这种将代码层面和项目管理层面打通的设计非常简明。
  • 内置的 Web IDE 让轻量级的代码修改和文件创建无需依赖本地环境。
• 缺点：高级项目管理的缺失。
  • 对于极大型的企业级敏捷开发团队，GitHub 原生的 Issues 和 Projects 功能可能显得过于轻量。

4. 准确度与安全性

• 优点：严密的防呆设计与质量门禁。
  • 强制状态检查：只有当 Actions 的测试全部通过，合并按钮才允许点击，这从根本上杜绝了带 Bug 的代码被合并。
  • 破坏性操作的安全验证：在体验删库操作时，系统不仅将区域标红，还强制要求用户手动拼写全称，极大地降低了误操作的概率。
• 缺点：依赖链的安全隐患。
  • CI/CD 极其依赖第三方库和 Action 插件。如果开发者不慎引用了恶意的第三方包，自动化流水线反而会成为黑客入侵的捷径。

5. 用户体验

• 优点：将开发转化为社区互动。
  • GitHub 巧妙地将软件开发社交化了。Watch、Star、Fork等机制，极大地降低了开源参与的门槛。
  • 对于新手而言，系统随处可见的 Empty State 做得非常出色。
• 缺点：CI/CD YAML 语法的隐性门槛。
  • 虽然声明式的 YAML 相对直观，但由于缺乏极其完善的网页端所见即所得拖拽生成器。对于完全不懂运维的新手来说，理解 on, jobs, steps 的层级关系，以及处理缩进错误，依然存在一定的上手痛点。
  • 此外，github的分支操作具有一定的门槛，本地的图形化工具也做的十分简陋，对初学者的要求比较高，具有操作门槛。

改进意见

目前，我觉得 github 的改进方向有以下几点：

1. CI/CD 操作的简单化
   可以简化 CI/CD 操作的门槛，引入节点拖拽的编辑器，用户不用自己写代码，只用理解整个运行逻辑即可。
2. 优化新手指导，降低操作门槛
   在新用户创建账号后，可以提供一个教程，主要讲解分支管理、issue、pull request、merge分支等知识点，这样可以降低操作门槛，让更多的人学会使用 github 来团队协作

用户调研

采访的用户是笔者的高中同学，目前就读于清华大学计算机系，是 github 的资深用户，使用 github 已有较长时间，多次进行团队协作管理项目

评测结论

github 可以说是目前最好用的代码仓库管理系统了，应该给到夯。
我的评价是 e) 非常推荐

Bug分析与提交

Bug1 Github issue创建bug

1. 测试环境

• 操作系统： Windows 11 (23H2)
• 浏览器： Google Chrome 123.0.x
• 发生场景： 在全新的仓库中进行首次 Issue 创建操作。
• 前因后果： 连续点击“Create”按钮，系统后端返回错误响应，但前端并未同步回滚计数器状态。

2. 可复现性及具体复现步骤

• 可复现性：满足特定条件下必然发生。
• 发生条件： 在网络请求延迟或后端鉴权失败触发 Error 状态时。
• 复现步骤：
  1. 在一个没有任何 Issue 的空仓库中，点击 Issues 导航页。
  2. 点击 New issue。
  3. 填写标题与内容后，点击 Create。
  4. 若后端 API 因某种触发机制返回 4xx 或 5xx 错误码。
  5. 观察现象： 页面弹出红色 Error 提示，但顶部 Issues 计数器从 0 自动变为了 1；重复操作一次，计数器变为 2，反复提交还会导致计数器持续增加，但下方列表依然为空。

3. Bug 具体情况描述

• 具体现象： 前端 UI 的计数器与实际数据源发生状态分离。
• 为何是 Bug 而非 Feature： 这是典型的状态不一致问题。UI 计数器是用户对仓库状态的直接反馈，若计数与实际列表不匹配，会导致用户产生Issue 已创建但在列表中丢失的错觉，降低了用户对系统一致性的信任。

可以看到明明没有issue，但是左上角计数器显示有6个。

4. Bug 分析

• Bug 的可能成因：
  • GitHub 采用了“乐观更新”设计。即前端在 Promise 的 Pending 阶段就执行了 count++ 操作。
  • 失败的回滚缺失： 在 catch 或 reject 分支中，前端逻辑缺失了 count-- 的反向操作。
• Bug 的严重性：⭐⭐ (2星 - 轻度缺陷)
  • 功能维度： 仅影响视觉计数，不影响数据库核心逻辑。
  • 用户体验： 严重的 UI 不一致感，使用户困惑。
• 为何团队在发布前未修复：
  • ☑️ 具体的设计质量不高： 前端在处理并发异步请求时，缺乏严谨的状态机管理。
  • ☑️ 测试把关不严： 自动化测试覆盖了“成功创建”的逻辑，但忽略了“高并发点击失败”下的 UI 状态自愈测试。

5. Bug 改进建议

• 正常运行期望： 无论 API 返回成功还是失败，计数器应仅在确认 201 Created 响应后进行更新。
• 改进实现：
  1. 修改逻辑： 改为“悲观更新”，即等待 API 返回成功后再 count++。
  2. 增强逻辑： 若坚持使用乐观更新，必须在 catch 异常分支中显式调用 revertState()，确保 UI 永远与后端真实状态保持一致。

Bug 2：GitHub Actions set-env 环境变量注入系统级漏洞（CVE-2020-15228）

1. 测试环境

• 发生时间段及前因后果： 发生在流水线执行 run 步骤打印日志的阶段。因系统解析机制缺陷，导致普通的日志输出被升格为系统指令，造成环境被劫持。

2. 可复现性及具体复现步骤

• 可复现性：满足特定条件下必然发生。
• 发生条件： 当工作流脚本中包含了对不可信外部输入的直接打印 echo 操作时。
• 复现步骤：
  1. 开发者写了一个自动回复的 CI 脚本，包含逻辑：echo "收到了新 Issue: ${{ github.event.issue.title }}"。
  2. 攻击者创建一个新的 Issue，标题故意写为：::set-env name=LD_PRELOAD::/tmp/malicious.so。
  3. 流水线触发，Runner 终端执行并打印了这句话。
  4. Runner 监控程序捕获到 ::set-env 魔法字符串，误以为是开发者下达的命令。
  5. 系统在全局环境变量中注入了黑客指定的动态链接库，接管了后续所有命令的执行权限，进而窃取仓库的权限密钥（GITHUB_TOKEN）。

3. Bug 具体情况描述

• 具体现象： 终端正常的日志打印行为，导致了虚拟机的全局环境变量被篡改。攻击者通过数据通道下达了控制指令。
• 为何是 Bug 而非 Feature： 这是致命的带内信令注入缺陷。系统未能将数据与指令进行物理隔离，证明这确实是一个致命的安全漏洞，而非业务乌龙。

4. Bug 分析

• Bug 的可能成因： GitHub 为了降低开发者学习成本，设计了基于 stdout 解析特定格式来执行工作流命令的便捷机制。但忽略了如果 stdout 中混合了不受控的外部输入参数，解析器无法分辨这行字是开发者写的还是黑客注入的。
• Bug 的严重性：⭐⭐⭐⭐⭐ (5星 - 致命性安全漏洞)
  • 安全性： 这是最高级别的代码执行与提权漏洞。黑客不仅能破坏当前流水线，还能窃取密码去修改仓库的主干代码，导致严重的供应链污染。
• 为何团队在发布前未修复：
  • ☑️ 具体的设计质量不高： 架构师在设计数据流向时，严重违反了安全工程中经典的数据与控制平面隔离原则。
  • ☑️ 开发人员粗心大意： 在设计 Workflow Command 语法时，优先考虑了易用性，而完全忽视了注入攻击的风险。

5. Bug 改进建议

• 正常运行期望： 打印带有 ::set-env 的字符串仅仅作为纯文本显示在日志中，绝对不能修改系统底层的环境变量。
• 改进实现： 废弃所有基于 stdout 解析环境变量的魔法命令。改用带外数据传递的方式：系统提供一个特定的随机加密文件路径，强制要求开发者通过写入该文件来修改变量，彻底斩断通过日志注入指令的路径。

第二部分 分析

1. 工作量分析 (Workload Estimation)

估算前提：

• 团队构成： 6 名全职工程师，专业 UI/UX 设计师团队。
• 目标： 达到 GitHub 目前的基础核心功能（Repository 代码托管、Issue 系统、Pull Request 代码审查、GitHub Actions 自动化流水线、个人主页与社交化关注机制）。

估算方法： 采用COCOMO 模型的思维方式进行拆解。

• 核心模块拆解：
  1. 代码托管核心： 需封装 Git 底层命令，确保分布式版本控制的稳定性。约 6-7 个月。
  2. Issue 与协作系统： 涉及复杂的关联、标签、Assignee 逻辑。约 4-6 个月。
  3. GitHub Actions： 涉及调度系统、云端虚拟环境管理、YAML 解析。这是最难的部分，约 8-10 个月。
  4. UI/UX 与前端工程： 涉及复杂的 WebSocket 通讯与状态管理。约 5-6 个月。
  5. 安全、权限与商业化模块： OAuth 验证、组织权限管理。约 5-5 个月。

最终估算：

• 总工时： 约 28-34 月（如果是基础功能集）。考虑到前期架构设计、后期测试与性能优化，再加上团队间的沟通成本，6 人团队完成 GitHub 核心功能的初步 MVP 版本，大约需要 2.5 - 3 年的时间。
• 注意： GitHub 发展了十几年，我们这里估算的是“核心功能集合”，若是 GitHub 现在的全量规模，6 人团队可能需要数十年，因为它涉及极其复杂的服务器运维与全球 CDN 分发。

2. 软件质量分析

2.1 同类产品中的排名与优劣分析

• 排名：第一。
• 对比对象： GitLab, Bitbucket, Gitea。
• 优势：
  • 极致的社交粘性： GitHub 成功地将代码托管转变为开发者社区，Star 和 Follow 机制形成了网络效应。
  • Actions 生态： GitHub Actions 带来的一键复用能力，让其生态丰富度远超 GitLab。
  • 开发者的习惯： 已成为全球开发者的简历，这种先发优势和社区惯性几乎无法被超越。
• 劣势：
  • 极客化门槛： 相比 GitLab，GitHub 对企业级私有化部署和复杂权限管控的支持较弱（GitLab 在这方面更强）。
  • 重度依赖： 开发者在代码安全与隐私方面对 GitHub 存在“鸡蛋放在同一个篮子”的依赖焦虑。

2.2 团队软件工程方面可提高的一个重要方面
重要建议：强化防御性工程与边界状态管理

• 推理依据：
  虽然 GitHub 核心功能强大，但我们在测试中发现，即便是这样的顶级产品，在面对边界场景时，依然表现出对状态逻辑管理不够严谨。
• 具体建议：
  GitHub 团队应引入形式化验证或更严格的状态机模型来重构前端交互与 CI/CD 调度系统。
  • 操作建议： 在提交高频交互时，禁止盲目的乐观 UI 更新，必须强制执行预检查-同步处理-反馈的原子化事务模型。
  • 安全建议： 在 CI/CD 流水线层面，应建立更细的行为分析，不仅要检测恶意脚本，还要根据用户行为模式自动触发二阶段验证，从而从工程架构层面彻底解决权限滥用和状态漂移的问题。

第三部分 建议和规划

一、 市场现状与定位

1. 市场概况： GitHub 目前拥有超过 1 亿开发者，几乎覆盖了全球 90% 以上的活跃开源项目。潜在用户为所有数字化转型中的企业和教育机构。
2. 竞争产品： GitLab、Bitbucket、Gitee。
3. 产品定位： GitHub 定位为全球开发者的开源社区与代码托管中心。其核心竞争优势是强大的社交粘性与 Actions 生态，劣势在于对非技术用户的门槛较高。

二、 市场与产品生态

1. 核心用户： 典型的极客开发者，通常拥有计算机科学背景，受过高等教育，追求效率，反感冗余的界面。潜在需求是：从单纯的代码托管，进阶到更智能的研发全生命周期管理。
2. 用户关系与生态： GitHub 的用户通过 Fork、Star、Pull Request 形成了一个巨大的技术影响力图谱。利用这种关系，GitHub 已经构成了技术人才招聘与筛选的生态。

三、 产品规划：AI 驱动

1. 新功能设计 (基于 NABCD 模型)

• N (Need)： 目前开发者在处理 Pull Request时，手动编写变更摘要极其繁琐，且很难快速审阅复杂代码。
• A (Approach)： 设计 AI PR 深度摘要与质量预审 功能。利用 Copilot 的底层模型，在合并前自动分析代码 Diff，生成业务逻辑变更摘要，并自动运行静态分析和测试覆盖率预警。
• B (Benefit)： 节省开发者 50% 以上的 Review 时间，降低因手动编写描述不清导致的逻辑合并错误。
• C (Competition)： 虽然 GitLab 有类似 AI，但 GitHub 拥有更庞大的数据集支撑，其推理准确度远高于对手。
• D (Delivery)： 将此功能集成在 PR 页面顶部的显眼位置，作为一个一键生成/审批的入口。

2. 团队角色配置 (6 人小组)

• PM (1人)： 负责需求定义、AI 模型调优指标设定、用户体验反馈调研。
• 后端开发 (2人)： 负责接入 GitHub Copilot API，构建 AI 推理的缓存队列与 Webhook 逻辑。
• 前端开发 (2人)： 负责在 PR 详情页 UI 的嵌入，以及异步任务状态渲染。
• 测试/DevOps (1人)： 负责自动化压力测试，确保 AI 推理不造成页面卡顿，并进行安全审计。

3. 16 周详细路线图

周次	阶段	详细规划
W1-W2	需求与架构设计	确定 AI 推理接口规格，设计 UI 原型，完成技术选型。
W3-W5	后端逻辑开发	接入 Copilot API，编写 Hook 来监听 PR 的提交事件，完成逻辑摘要生成器。
W6-W9	前端与 UI 集成	开发 PR 页面的 AI 摘要组件，实现“一键填入”功能，优化交互体验。
W10-W12	质量门禁与性能优化	增加测试覆盖率分析预警，优化 AI 解析延迟。
W13-W14	测试与 Bug 修复	执行破坏性测试。
W15	Beta 灰度发布	在部分开源仓库内小范围灰度，搜集开发者对摘要准确性的反馈。
W16	总结与全网发布	编写发布说明文档，进行成果演示与迭代复盘。