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

[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.com）进行分析，在第三部分与Gitlab进行对比分析。

第一部分 调研，评测

一、软件评测

1. 软件使用

GitHub是全球最大的代码托管平台，作为全球开发者的社交网络，它主要用于代码版本控制和协同工作。软件提供了web端和客户端种操作方式，本文主要基于web端进行介绍（笔者多使用web端）。下面介绍GIthub的基本功能界面。

Github的Dashboard主页可以新建/管理个人仓库，集成了简单的大模型对话功能，以及一些平台推荐和最新消息。

GitHub的仓库管理界面有着强大的功能。首先，在这个界面可以浏览项目文件，集成了markdown渲染方便。对于自己的仓库，还可以直接使用内置的网页端vscode来进行简单的代码修改和推送。此外，诸如仓库的一些基本信息，比如语言组成，作者描述，软件发布都可以在仓库主页找到。

GitHub提供了很多除了代码托管以外的便捷功能，这里展示的是GitHub Action的界面。用户可以设计一些工作流来执行简单的任务，比如推送消息。还可以结合Github Pages的网站托管功能来实现一键部署，即时修改。（图示即笔者利用GitHub Pages和Actions功能进行简单的个人博客网站搭建的Actions执行历史）

GitHub最大的价值莫过于其令人惊叹的社区生态，数以万计的开发者在GitHub上分享自己的代码。使用搜索功能（图示搜索关键词“vite”）就可以查询到某一领域的开源项目代码。可以fork到自己仓库进行部署体验，也可以向其他开源项目发出pull request请求贡献自己的智慧。

GitHub的功能是如此的强大，笔者在此不便展示其完整的功能生态。

2.软件分析

在此介绍一下GitHub的基本使用流程。

• 创建仓库：在Dashboard点击new repository进行空仓库创建，可以设置git主分支、仓库描述、访客可见性等等。可以使用命令git remote来把本地的git仓库关联到创建的远程仓库。
• 上传代码：可以通过web端直接修改代码并上传。也可以在本地仓库修改后，通过git push命令来推送已提交的修改到远程仓库
• 克隆仓库：通过fork功能可以复制一份别人的仓库到自己的仓库。通过git clone可以克隆代码到本地。
• 拉取更新：通过git fetch可以将远程仓库的更新合并到本地的仓库。
• PR（pull request）：先fork别人的仓库，然后创建新的分支，修改代码，提交到fork的仓库后，创建合并请求，等待维护者审核。
• Github Action：在仓库界面Actions栏目里可以添加新action的配置文件，实现自动化功能，可以设置如代码推送之类的触发节点。
• GIthub Pages：在仓库界面Settings栏目里可以对仓库进行网页托管部署。之后使用[用户名].github.io/[仓库]即可访问。

是否满足用户需求？

• Github平台几乎涵盖了git版本控制软件所需的一切，用户可以轻易实现代码托管、版本控制与回溯、团队协作、开源分享。

• 随着新技术的不断出现，GitHub平台也与时俱进，集成了大语言模型、Vibe Coding、网站托管等众多功能，已经成为了开发者不可或缺的工具。

• GitHub的跨平台支持非常优秀，方便linux/macos/windows的不同用户进行技术交流。

• Github是比较受认可且方便的开源软件发布平台，release功能可以有效降低用户不知道去哪下载开源软件或下载到有害软件的可能性，到作者仓库下载更加安心。

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

• 数据量：平台提供了免费的托管服务，有着比较充裕的仓库容量，对学生群体的学习很友好。但对于超过百兆的二进制文件的存储较为麻烦，容易上传失败，需要进行而外处理。
• 界面：界面简洁美观，但随着功能与日俱增，对于初学者来说容易眼花缭乱。且只有英语界面，对于非英语母语开发者来说需要有较强的阅读能力或者搭配翻译软件使用。
• 功能：功能强大，无需多言。但一些高级功能需要付费，比如部署多个网站。
• 准确度：代码检索与管理都很稳定，但搜索功能还有欠缺，有时难以找到自己想要的资源（而且只支持英语，对有些内容翻译出现偏差导致难以检索）。
• 用户体验：web端提供了直白的操作界面，但与本地结合需要用户熟悉git命令。国内用户连接较慢，体验较差。

3.改进意见

• 都2026年了，居然还不支持其他语言！！建议赶紧支持中文。
• 浏览界面建议增加更多格式支持，比如支持查看.pdf文件

4.用户调研

笔者调研了同为2023级6系的王梓琛同学（欧阳元新、王德庆老师的软工班；属于其他教学班）

• 对象背景：同系计算机学生，参加过一些比赛，使用git进行代码管理
• 对象使用产品栏目：主要使用代码管理功能
• 使用体验和改进：见以下截图

---

5.评测结论

• a) 非常不推荐
• b) 不推荐
• c) 一般
• d) 好，不错
• e) 非常推荐

综合以上因素，我的结论是：e，非常推荐。

以下是一些评测细节

角度	权重	得分	加权得分	描述
功能	50%	10/10	5.0	功能是最重要的，没有功能的话就是纸上谈兵
体验	20%	6/10	1.2	不支持中文和网络连接比较难受
生态	20%	10/10	2.0	没得选，最强了
价格	10%	8/10	0.8	对于学生群体完全够用
			9.0	总体给到夯

二、Bug分析和提交

1.测试环境

操作系统：macOS 15.6.1、windows 11

浏览器：edge

时间段：2023-11开始使用至2026-3

2.Bug严重性定义

星级	系统功能影响	安全性影响	用户体验影响
致命★★★★★	仓库无法访问、代码推送/拉取完全失败、GitHub Actions服务不可用，导致开发流程瘫痪	未授权访问私有仓库、远程代码执行、恶意代码注入、敏感凭证泄露	用户完全无法完成代码提交、PR合并等关键操作，或代码历史永久丢失
严重★★★★☆	Pull Request核心功能部分失效（如无法合并、冲突检测失败），但可通过本地Git临时修复	私有仓库数据泄露、鉴权绕过访问受限仓库、恶意PR代码执行风险	关键操作流程中断（如PR创建卡死、代码审查无法进行），用户需复杂回退操作
一般★★★☆☆	非核心功能失效（如Wiki、Projects看板异常），不影响代码托管主流程	CSRF攻击风险、低权限用户信息泄露、敏感日志暴露	功能可用但体验差（如仓库加载超时、文件浏览卡顿、搜索结果延迟）
次要★★☆☆☆	轻微功能异常（如Markdown渲染错误、徽章显示不正确），不影响核心逻辑	低风险漏洞（如公开仓库元数据泄露、非敏感配置信息暴露）	轻微体验问题（如UI按钮对齐错误、提示文案不准确、图标显示异常）
轻微★☆☆☆☆	不影响功能的代码格式问题、控制台警告信息	无直接风险（如冗余API权限声明、非敏感日志格式不规范）	无感知问题（如页面加载动画不流畅、代码高亮延迟）

3.发现的Bug1

• 描述：由于GitHub是外国网络的平台，尽管它没有完全被国内网络隔离，大多数情况可以直接访问，但少数情况下难以访问，需要结合vpn使用。然而，对于特殊的时间段，可能出现以下问题：可以正常访问github链接，打开仓库界面，但使用命令行无法push代码到远程仓库，报access fatal错误。
• 可复现性：容易复现。北京时间20:00-2:00的疑似高峰时间段内，经常出现无法push的情况。（可以访问网站和仓库，在web端修改，但无法推送）。
• bug分析：
  • 严重性：致命★★★★★。很多时候不知道什么时候才能购恢复正常
  • 可能原因：本身对于中国地区的网络连接比较脆弱，在高峰时间段内容易堵塞
  • 建议：平台应该在中国地区建立分服务器，或提高网络服务质量。
  • 为何有这个bug：可能是Github的用户早期较少中国用户，平台方忽略了这部分地区的高并发需求。

4.发现的Bug2

• 描述：浏览markdown文件时格式错误。对于比较复杂的markdown文件，比如嵌套列表、代码块、内链公式等嵌套组合的情况下，会发生如下问题：表格内容错误换行、latex公式无法正常渲染、格式的错误覆盖。
• 可复现性：复杂的markdowm文件浏览时偶尔复现，笔者还没有找到具体逻辑。
• bug分析：
  • 严重性：次要★★☆☆☆。
  • 可能原因：web端内置的markdown到html的渲染比较轻量，功能不足。
  • 建议：尽可能丰富其markdown显示，可以参考typora等更全面的渲染
  • 为何有这个bug：设计之初可能没有考虑到所以markdown格式的嵌套显示逻辑。

5.Bug反馈

根据提示，对第二个问题在社区发起了bug讨论。考虑到网络问题目前github已经正在解决（github多次声明这是bug，便不再提出）

第二部分 分析

一、工作量分析

基于6人团队开发一个GitHub核心功能版本（代码托管、PR协作、Issues、基础CI/CD）：

1.工作量估算

阶段	时间	关键任务
项目规划与需求分析	2 周	技术栈选型、Git架构设计、数据库模型设计
后端核心开发	14 周	Git仓库托管、版本控制逻辑、API设计、数据库优化
前端界面开发	12 周	仓库浏览、PR/Issue界面、代码对比、响应式设计
协作功能开发	8 周	Pull Request流程、Code Review、Issues系统、通知机制
安全与权限管理	5 周	SSH/HTTPS认证、OAuth、仓库权限控制、安全审计
CI/CD基础功能	6 周	GitHub Actions工作流引擎、日志展示、运行器调度
测试与修复	8 周	单元测试、集成测试、压力测试、Bug修复
文档与发布	2 周	API文档、用户手册、部署上线
总计	57 周	约 14 个月

2.团队分工

角色	人数	主要职责
后端开发	2 人	Git核心逻辑、API开发、数据库设计、性能优化
前端开发	2 人	界面实现、交互逻辑、代码编辑器集成
UI/UX设计师	1 人	界面设计、交互原型、视觉规范制定
测试与文档	1 人	测试用例编写、自动化测试、文档撰写

3.关键难点说明

技术难点	复杂度	说明
Git底层实现	★★★★★	需要深入理解Git对象模型、分支管理、合并算法
大规模仓库性能	★★★★★	处理大型仓库的加载、差异对比需要高效的算法和缓存策略
并发协作冲突	★★★★☆	多人同时编辑、PR冲突检测与自动合并逻辑复杂
CI/CD调度系统	★★★★☆	任务队列、资源隔离、日志流式传输需要精心设计

二、软件质量分析

1.优势与劣势

• 优势：

  • 强大的功能：该有的都有，还在不断添加新技术新功能
  • 跨平台支持：基于git，支持大部分操作系统，命令行、web端、客户端都可使用
  • 丰富的开源社区：最主流的平台，适合开发与学习

• 劣势：

  • 国内连接较慢，需要代理，有时甚至断连
  • 对非英语母语者有一定学习成本；对非计算机/不熟悉命令行或git的用户有一定学习成本
  • 企业价格昂贵，个体不支持大文件存储

• 在同类产品中可以排到第一：一家独大

2.可以提高的方面

• web端阅读代码体验较差，要多次跳转，建议加入缓存机制，可以免去已阅读过页面的加载
• 增加更多语言的支持和自定义界面功能。

第三部分 建议和规划

这个软件/网站/服务有很多可以提高的部分，如果你是新上任的项目经理，如何提高从而在竞争中胜出？

一、市场现状

1. 市场概况

全球代码托管市场规模巨大且持续增长，开发者群体已从专业程序员扩展至数据科学家、学生及科研人员。随着开源文化的普及，代码托管平台已成为软件研发的基础设施。目前市场趋于成熟，用户对平台的稳定性、协作流畅度及扩展性提出了更高要求。

2. 竞争产品

• GitLab：最强有力竞争者，提供开源版本和强大的内置CI/CD及DevOps一体化解决方案，深受企业级用户青睐。
• Gitee（码云）：国内主要竞争对手，依托本地化服务和网络速度优势，在国内企业和高校市场占据一定份额。

3. 产品定位

GitHub定位为“全球最大的代码协作平台与开源社区”。它不仅仅是代码仓库，更是开发者的社交网络。其核心竞争力在于庞大的开源生态、便捷的Pull Request协作流程以及丰富的第三方应用市场。

二、市场与产品生态

1. 用户画像与潜在需求

• 核心用户：职业开发者。需求：高效的代码审查、稳定的Git服务、自动化CI/CD。
• 学生群体：如我一般的大学生。需求：简单易用的版本控制、作业提交便利、建立个人技术档案。
• 潜在需求：随着项目复杂度增加，用户需要更直观的项目管理工具，以及更低门槛的文档协作功能（目前Markdown门槛对非技术人员仍较高）。

2. 用户之间的联系和构建生态

GitHub通过“Fork -> Pull Request -> Merge”的工作流建立了独特的协作生态。用户通过Star表达认可，通过Watch关注动态，形成了一种基于代码的社交关系。开源项目的贡献者网络构建了庞大的技术生态，使得任何开发者都能轻松参与到全球项目中。

3. 子产品以及相关产品的联系与生态

• GitHub Actions：自动化引擎，连接代码与部署。
• GitHub Copilot：AI编程助手，嵌入编辑器，形成“编码-托管-辅助”闭环。
• GitHub Pages：静态站点托管，为开源项目提供展示窗口。
  这些子产品相互引流，构建了从开发、测试到部署的完整DevOps闭环。

三、产品规划

1. 新功能设计及理由（NABCD分析）

针对现有Markdown渲染在复杂文档下的不足，建议开发 “交互式项目看板视图”。

• N (Need 需求)：目前的GitHub Projects功能强大但上手较陡峭，Issues列表视图在管理大量任务时不够直观。用户需要一个能自动解析TODO注释、支持拖拽排序的轻量级看板，与代码深度绑定，能够有效规划管理。
• A (Approach 做法)：
  1. 开发前端拖拽组件。
  2. 后端解析代码中的// TODO、// FIXME注释，自动生成卡片。
  3. 支持将卡片拖拽至不同列（To Do, In Progress, Done）自动同步标签状态。
• B (Benefit 好处)：降低了项目管理的门槛，让开发者不用离开代码就能管理任务，提高了任务追踪的实时性。对于学生团队或小型项目非常友好。
• C (Competition 竞争)：GitLab有Issue Board，但配置繁琐。我们的优势是“自动化”和“轻量级”，直接从代码生成任务，无需手动创建。
• D (Delivery 推广)：在各大IDE如vscode的Marketplace提供相关操作插件，也可以在网页端使用，与github服务深度结合，针对学生群体进行推广，主打“写代码即写计划”。

2. 项目经理规划

团队配置（6人）：

• 后端开发 (2人)：负责API设计、数据库、代码注释解析逻辑。
• 前端开发 (2人)：负责看板UI交互、拖拽功能、数据渲染。
• UI设计 (1人)：负责界面原型设计、交互体验优化。
• 测试/文档 (1人)：负责测试用例编写、Bug管理、用户手册。
  16周详细规划：

阶段	时间	详细规划	交付物
第一阶段：需求与设计	第 1 周	需求研讨，确定技术栈，制定接口文档	需求规格说明书、API接口文档
	第 2 周	UI原型设计，数据库建模，环境搭建	UI原型图、数据库ER图
第二阶段：核心开发	第 3-4 周	后端：实现用户认证、仓库数据同步接口	基础API接口
	第 5-6 周	前端：实现看板基础布局、卡片组件开发	静态看板页面
	第 7-8 周	后端：开发代码解析器，提取TODO/FIXME注释	代码解析模块
	第 9-10 周	前后端联调：实现数据同步，卡片自动生成功能	看板核心功能Alpha版
第三阶段：功能完善	第 11 周	实现“拖拽更新状态”功能，实时同步数据库	拖拽交互功能
	第 12 周	集成GitHub API，实现权限控制与私有仓库支持	权限管理模块
第四阶段：测试与优化	第 13 周	单元测试、集成测试，修复已知Bug	测试报告
	第 14 周	UI/UX优化，性能优化（大列表渲染）	优化后的版本
第五阶段：发布准备	第 15 周	编写用户文档、部署上线、内测反馈	用户手册、Beta版
	第 16 周	Bug扫尾，正式发布，编写项目总结报告	正式发布版 v1.0