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

作业要求

项目	内容
这个作业属于哪个课程	北京航空航天大学2025年春季软件工程
这个作业的要求在哪里	[I.2]个人作业：软件案例分析
我在这个课程的目标是	掌握软件工程的基本技能，分析其他软件的成败， 从间接经验中学习
这个作业在哪个具体方面帮助我实现目标	通过软件案例分析，从开发者的角度对软件进行评测，思辨，总结，学习软件工程在具体实践中的基本原则与注意事项

一、选题

从中国高校大学生的身份角度出发，你认为这些系统有什么缺陷和需要改进的地方，并且该如何改进？ 请你从下述的选项中选择 至少两个 常见的代码仓库管理系统进行使用与分析。

可供参考的分析重点：用户体验和学习曲线、版本控制机制、安全性和权限控制、可扩展性等。

• 选题类型：代码仓库管理系统
• 选定软件：Github、Gitee、Gitcode

二、调研测评

选定软件：Github

软件测评

基本介绍

GitHub是一项基于云的服务，为软件开发和 Git 版本控制提供 Internet 托管。这有助于开发人员存储和管理他们的代码，同时跟踪和控制对其代码的更改。支持网页版和客户端版

软件使用

以下为网页版首页

以下为客户端版,支持一键git clone, git fetch,分支切换和调用本地外编辑器进行代码书写

软件分析

基本使用流程

所有代码仓库管理系统可以说是通用的，网页端或者客户端用于新建仓库，fork或者star他人仓库和新建组织等。

1. 创建仓库
   • 用户通过页面右上角的 + 按钮创建新仓库，设置仓库名称、描述、公开/私有权限等。
2. 克隆仓库
   • 使用 git clone 命令将远程仓库克隆到本地，或通过镜像站点（如 github.com.cnpmjs.org）加速访问。
3. 代码提交与推送
   • 本地修改后，通过 git add、git commit、git push 等命令提交并推送代码到远程仓库。
4. 协作与贡献
   • Fork：复制他人仓库到个人账户进行独立修改。
   • Pull Request（PR）：将修改提交至原仓库，等待维护者审查合并。
   • Star：收藏他人开源代码
5. 问题追踪与讨论
   • 通过Issues报告问题或讨论功能改进，利用 Projects 管理任务看板

是否满足用户需求

GitHub 能够满足以下核心需求：

• 版本控制：完整支持 Git 功能，记录代码变更历史，查看历史提交记录。
• 协作开发：通过 Fork、PR、代码审查等功能实现团队协作。
• 开源生态：托管海量开源项目，支持开发者参与贡献。
• 自动化工具：集成 CI/CD、代码审查机器人等提升开发效率

软件在数据量/界面/功能/准确度/用户体验上各有什么优缺点？

1. 数据量

   • 优点：托管了全球最多的开源项目（截至 2025 年超过 4 亿仓库），支持大规模代码存储和检索
   • 缺点：对于中国用户而言，部分用户可能因网络限制访问缓慢需要代理。

2. 界面

   • 优点：网页端和客户端界面简洁直观，导航栏功能分类清晰
   • 缺点：页面切换时偶有加载延迟（如项目页标签切换刷新整个页面）

3. 功能

   • 优点：
     • AI 增强工具：GitHub Copilot 的 Agent 模式支持自动生成代码、修复 BUG，显著提升开发效率。
     • 生态整合：支持与第三方工具（如 VS Code、Replit）深度集成，提供 CI/CD、项目管理等全流程服务
   • 网页端无法处理并发修改冲突需要依赖于本地的提交，这时可以用过客户端进行操作，但是客户端大部分操作可以通过JetBrain公司的IDE解决，客户端显得较为冗余。

4. 准确度

   • 优点：代码搜索支持高级过滤（如按语言、文件名、代码片段），结果精准
   • 缺点：对国内和新手用户不太友好，不支持中文搜索

5. 用户体验

   • 优点：协作功能（如 PR 和 Issues）设计成熟，支持多人高效协作。社区生态活跃，开发者可通过 Trending、Topics 发现优质项目。
   • 缺点：新用户学习曲线较陡，需熟悉 Git 命令和协作流程

Gitee相比Github唯一的优点就是对国内用户较为友好

改进意见

Github作为世界各国多人开发必定使用的代码管理仓库，从一个中国用户的角度上，我的建议如下

1. 网页端是否可以增加代码编辑功能，使得在PR出现冲突无法合并时，可以由管理者手动在网页端就能进行处理并合并，而无需在本地处理完再提交推送
2. 个性化界面定制：允许用户自定义导航栏布局、主题配色（如深色模式的更多变体）
3. 动态页面加载优化：采用更轻量的前端框架（如 Svelte）减少页面切换时的刷新延迟
4. 推出“科研版 GitHub”，支持论文数据集托管、实验代码复现环境（如 Jupyter Notebook 集成）

用户调研

我选择了一位谭鑫王德庆老师班的同学gpf，他经常使用Github上为各种开源项目做贡献和用部分论文的开源代码做科研，有较为丰富的使用经验，他偶尔也会使用gitee。

我的问题如下：

1. 你觉得Github和Gitee的使用体验感有什么区别？你为什么选择Github？

   • Github开源项目多，汇集全球，有一定的社交属性，Gitee的用户主要面向中国用户，针对有使用代理能力的中国用户而言，Github不管从项目数目、还是个性化推荐上都要更优，况且目前主流论文项目界面都采用的github的静态页面托管。此外GitHub Actions 和丰富的第三方工具链（CI/CD、项目管理等）无缝集成，大幅提升开发效率。GitHub 是“技术领域的社交网络”，而 Gitee 更偏向“企业级代码仓库”，定位差异明显。若追求技术前沿和全球协作，GitHub 仍是首选；若侧重本地化部署和合规需求，Gitee 有一定价值。

2. 你认为Github使用最大的亮点是什么？

   • 全球最大的开源代码托管平台，开发者可以快速参与或借鉴项目，形成“代码即社交”的生态。

3. 从用户体验来讲你认为Github需要做什么改进？

   • 降低新手门槛：提供更直观的交互引导（如可视化 Git 操作），避免非技术用户因命令行恐惧而流失。
   • 增强代码搜索能力：当前代码全局搜索效率较低，可引入语义分析或 AI 辅助（类似 ChatGPT 的代码理解）。

4. 满分100分，你会给这两个打多少分？并说明各自的优缺点

   • GitHub：95/100

     • 优势：生态完善、工具链成熟、全球化社区。
     • 扣分点：对非英语用户支持弱、企业级功能收费较高。

   • Gitee：75/100

     • 优势：本土化体验（中文支持、访问速度）、符合国内合规要求。
     • 扣分点：社区活跃度低、功能迭代慢（如 Actions 能力弱）、内容审核机制影响开发体验。

评测结论

根据以上结论我们得出对于全球用户，Github我们是e) 非常推荐

Bug 分析和提交

软件版本

Github-DeskTop-3.4.6

Bug严重性定义

• 致命（Critical/Blocker）：导致系统崩溃、数据丢失、核心功能完全失效或重大安全漏洞的缺陷。
• 严重（Major）：核心功能未按预期工作，但系统仍可部分运行。
• 一般（Moderate/Medium）：次要功能异常或非核心流程的问题，存在替代解决方案。
• 次要（Minor）：界面显示问题、拼写错误或轻微交互缺陷。
• 建议性（Trivial/Enhancement）：优化建议或非缺陷类改进。

Bug1

• 可复现性：稳定触发
• 描述：在 GitHub Desktop 中创建新分支时，不仅仅是主分支和当前分支，当分支很多时，增加用户工作量
• bug分析
  • 严重性：建议性。在 GitHub Desktop 中创建新分支时，最好有一个所有现有分支的列表，而不仅仅是主分支和当前分支，作为“基于...创建分支”的选项。建议一个组合框，其中包含 GitHub 上存储库的所有现有分支的列表。GitHub Desktop 及其用户的好处是显而易见的。在创建新分支之前，无需将当前分支更改为所需分支。
  • 可能成因：问题不是很严重，加上使用场景较少
  • 建议：这类功能需求加上还是可以提升用户体验的

Bug2

• 可复现性：条件触发
• 描述：当文件被重命名和修改时，尽管进行了修改，GitHub Desktop 仍会显示“该文件已重命名但未更改。
• 复现步骤：
  • 重命名存储库中由 git 跟踪的文件。
  • 对该文件进行修改。
  • 在终端中输入，git add *以便 git 将其注册为重命名的文件而不是删除的文件和添加的文件。
  • 在 GitHub Desktop 中，查看文件差异并注意未显示修改。相反，它仅显示“文件已重命名但未更改”
• bug分析
  • 严重性：次要。
  • 可能成因：问题不是很严重，开发者忽略了这里的更新
  • 建议：这里较为影响某些用户的使用，而且可能是代码层面的问题，建议修复

Bug反馈

GithubDeskTop在Github上已经开源，在下面发issue会得到及时回应

三、分析

工作量分析

1. 基础功能开发（核心代码托管与协作）

• 代码仓库管理：支持 Git 版本控制、分支管理、代码提交/拉取（1-2 个月）。
• Pull Request（PR）与 Issue 跟踪：实现代码审查流程、讨论线程、标签分类（2-3 个月）。
• 基础权限控制：团队/组织权限分级（1 个月）。
• UI 设计：简洁的仓库页面、代码浏览与对比工具（需专业 UI 支持，2 个月）。
• 总耗时：约 6-8 个月

2. 扩展功能（DevOps 与项目管理）

• 持续集成/部署（CI/CD）：集成 GitHub Actions 类似功能，支持自动化测试与部署（3-4 个月）。
• 项目管理工具：看板（类似 Projects）、里程碑跟踪（2 个月）。
• 企业级支持：审计日志、合规性配置（如 SOC 2）（2 个月）。
• 总耗时：约 7-8 个月

总工作量估算

• 最低要求（实现核心功能）：约1.5年。
• 完整功能：约3-4年。

当前优劣对比

优势：

• 生态系统完善：全球最大开源社区，集成 CI/CD、项目管理、AI 编程助手（Copilot）。
• AI 功能领先：Copilot Agent 模式支持自动化迭代与错误修复，远超竞品如 GitLab 的基础代码生成。
• 企业级支持：SOC 2 合规、自托管选项，优于 Cursor 等工具27。

劣势：

• 界面复杂度：功能冗余导致新用户学习成本高，部分用户认为早期简洁性丧失。
• 移动端体验差：移动应用功能残缺，网页版适配不足。

综合排名：稳居前 2（与 GitLab 并列，但 AI 功能领先）

软件工程改进建议

核心问题：Github界面复杂性与用户体验割裂，功能堆叠导致导航混乱，移动端与桌面端体验不一致。是否可以考虑将核心功能（代码托管、PR）与扩展功能（Projects、Copilot）解耦，支持用户按需启用，从而降低新用户上手难度，提升专业开发者效率，巩固市场地位。

四、建议和规划

市场现状

市场概况

2024 年 GitHub 贡献量同比增长 15.6%，生成式 AI 项目总数增长 95.7%，平台托管项目超 3000 万个，覆盖 97% 的软件开发者和 99% 的企业。GitHub拥有约1亿全球开发者用户，其中印度是该平台上最大的开发者社区，拥有超过900万用户。此外，2022年有2050万新开发者加入GitHub，中国、巴西和印度的用户数量显著增加。超过90%的《财富》100强公司使用GitHub，这表明GitHub在企业级开发中具有很高的认可度和应用价值。

竞品分析与产品定位

对比维度	GitHub	Gitee（码云）	GitCode
所属公司/平台	Microsoft（美国）	开源中国（中国）	CSDN（中国）
定位与目标用户	全球开发者社区，开源协作标杆	国内开发者首选，适配中文环境	面向国内开发者，集成技术社区与代码托管
服务器与访问	全球服务器，国内访问受限（需代理或镜像加速）	国内服务器，访问速度快且稳定	国内服务器，访问流畅，与 CSDN 生态深度绑定
核心功能	代码托管、CI/CD（GitHub Actions）、AI 编程（Copilot）、项目管理、社交功能	代码托管、CI/CD、文档协作（Wiki）、团队管理，支持中文界面	代码托管、文档管理、社区问答联动（依赖 CSDN 生态）
开源支持	公开仓库免费	公开仓库免费，私有仓库免费（基础版）	公开仓库免费，私有仓库需付费或绑定社区权益
企业级服务	GitHub Enterprise（自托管、合规性支持）	Gitee 企业版（支持私有化部署、国内合规）	企业服务较少，侧重社区化协作
AI 集成	GitHub Copilot（代码补全、Agent 模式）	无独立 AI 功能，依赖第三方工具	无公开 AI 功能，可能集成 CSDN 技术问答
社区与生态	全球最大开源社区，国际化项目多	国内活跃社区，中文项目丰富，适合本土协作	依托 CSDN 开发者社区，资源集中于技术博客与问答
劣势	界面复杂度高，学习成本高；国内访问延迟	国际影响力有限，AI 功能落后	功能相对单一，生态依赖 CSDN，缺乏独立竞争力

市场与产品生态

GitHub的核心用户群主要是从事计算机相关工作的人员，包括软件开发者、IT行业从业者、计算机专业的学生等。典型用户通常是具有一定学历水平的中青年群体，他们对编程和开发有浓厚的兴趣，乐于尝试新技术和新工具。

• 学历：核心用户群多为计算机科学、软件工程等相关专业的本科生、研究生以及博士生，也有部分通过自学成才的开发者。
• 年龄：用户年龄主要集中在18至35岁之间，其中25至35岁是主要的用户群体。
• 专业：以计算机科学与技术、软件工程等相关专业为主。
• 爱好：喜欢编程、开发新技术和工具，对开源项目有浓厚兴趣。
• 收入：学生群体收入有限，而专业开发者通常收入水平较高。
• 表面需求：需要一个稳定可靠的代码托管平台，以实现版本控制、协作开发、问题跟踪、CI/CD等基础功能。
• 潜在需求：实现更好的团队协作、更高效的代码管理、更多的自动化和集成工具、更好的社交网络功能，以及更丰富的学习资源等

GitHub的用户群体之间存在着紧密的联系。例如，学生在毕业后可能会成为IT从业人员，而企业中的开发者又会与开源社区的用户进行交流和协作。这种联系形成了一个以共享和开放为主题的用户生态，促进了开源软件的流行和发展。在这个生态中，用户不仅能够获取和学习他人的代码，还能通过贡献自己的项目来提升个人能力和影响力。

GitHub的子产品之间以及与其他相关产品之间也存在着一定的关联性。例如，GitHub的代码托管功能与CI/CD工具的结合，可以为开发者提供更完整的开发流程支持。此外，GitHub还与一些学习资源平台、社区平台等相结合，为用户提供更丰富的学习和交流机会。这些相互关联的产品共同构成了一个能够满足用户多种需求的产品生态，进一步提升了GitHub的用户粘性和市场竞争力。

产品规划

新功能设计

基于用户当前任务自动简化界面，仅展示必要功能模块，并集成轻量级 AI 助手辅助代码审查，降低复杂度同时提升效率。

NABCD 分析

维度	详细说明
N（需求）	1. 界面杂乱：开发者常被冗余功能干扰（如项目管理、社交功能）。 2. 代码审查耗时：手动检查代码风格、重复代码等问题效率低。
A（做法）	1. 一键切换专注模式：根据用户当前操作（如编码、审查、部署）自动隐藏非核心功能（如 Issues、Projects），仅保留代码编辑、Pull Request 等必要模块。 2. AI 辅助审查：自动检测代码风格问题、重复代码块，并生成修复建议（非自动修复）。
B（好处）	1. 专注度提升：减少界面干扰，提升核心任务效率。 2. 审查效率提升 30%：AI 快速定位代码问题。
C（竞争）	1. GitLab：无界面简化模式，功能堆叠更严重。 2. VS Code：虽支持扩展，但需手动配置，缺乏场景化适配。
D（推广）	1. 免费基础版：向所有 GitHub 用户开放专注模式。 2. 教育市场：集成到 GitHub Classroom，帮助学生聚焦编码任务。

团队分工

角色	人数	职责	技术栈要求
前端开发	2	专注模式界面开发（基于 React）、与 GitHub 现有页面集成	React、GitHub UI 组件库（Primer）、状态管理（Redux）
后端开发	2	用户行为分析接口、文档同步 API、权限控制	Node.js、GitHub API、MongoDB
AI 工程师	1	代码审查模型优化（基于现有开源模型如 CodeBERT）、文档生成逻辑（基于代码注释）	Python、Hugging Face 模型微调、正则表达式
测试工程师	1	功能测试（界面切换、AI 建议准确性）、兼容性测试（浏览器/设备）	Cypress、Jest、Postman

任务详细规划

阶段 1：需求与设计（Week 1-3）

周	目标	交付物
1	用户调研（10+ 开发者访谈）、竞品功能对比	核心场景列表（编码、审查、部署）、界面干扰痛点报告
2	确定 MVP 功能：专注模式开关、代码审查建议、文档同步	功能优先级清单、技术选型（复用现有模型）
3	低保真原型设计（Figma）、AI 审查规则逻辑（如重复代码检测）	交互原型、AI 审查规则文档

阶段 2：核心开发（Week 4-12）

周	目标	关键任务
4-9	分离式敏捷开发，前端：实现专注模式界面切换逻辑（隐藏/展示模块），后端：用户行为分析接口（记录操作类型）、文档同步 API后端：用户行为分析接口（记录操作类型）、文档同步 API	集成 GitHub 页面组件、状态管理开发，行为数据存储设计
10-12	联调与基础测试：界面切换 + AI 建议	修复联调问题、完成 70% 测试用例

阶段 3：测试与优化（Week 13-15）

周	目标	关键任务
13	功能测试：覆盖编码、审查、部署场景	修复界面显示异常、AI 建议误报
14	性能测试：界面切换响应 <0.5s、AI 建议延迟 <1s	优化前端渲染、模型推理轻量化（ONNX 转换）
15	用户验收测试（邀请 5-10 名外部开发者试用）	收集反馈并调整交互细节

阶段 4：发布准备（Week 16）

目标	关键动作
灰度发布与监控	向 1% 的活跃用户开放功能，监控崩溃率与使用时长
文档与宣传	更新帮助文档、发布功能介绍博客（案例：如何用专注模式快速完成代码审查）
社区运营	在 GitHub Discussions 发起话题，鼓励用户分享使用体验