软工2023个人作业二——软件案例分析
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2023年北航敏捷软件工程 |
| 这个作业的要求在哪里 | 个人作业-软件案例分析 |
| 我在这个课程的目标是 | 学习并掌握现代软件开发和项目管理技术，体验敏捷开发工作流程 |
| 这个作业在哪个具体方面帮助我实现目标 | 从软件工程角度分析比较我们所熟悉的软件，以指导后续的软工项目实践 |
代码仓库管理系统有很多，他们对于你熟悉的目标用户 （中国高校大学生）有什么缺陷和需要改进的地方，并且该如何改进？
本文上手使用并分析了两个常见的代码仓库：Github 和 Gitee。
第一部分 调研，评测
Github
使用记录
Github 首页：
在个人主页可以看到自己的所有仓库：
可以在搜索栏使用过滤器语法搜索开源项目：
可以查看一个仓库：
可以对某个仓库提 issue（社区版 issue 界面）：
可以回复和 close issue：
综合评价
优缺点
首先从数据量/界面/功能/准确度多个维度，分析 Github 的优缺点。
优点：
- 用户基数大！！！
开发者可以在 Github 平台上搜索到极为丰富的开源项目，单凭这一点就值得国内程序员即使需要通过一些特殊手段上网也更青睐 Github。比如我最近的实习项目需要集成 remesh 功能到我司软件，我在 Github 上搜索 remesh，从成百上千的仓库中找到了正合我需要的几何处理库，而在 Gitee 上搜索该关键词却得到 0 条记录。 - 搜索功能强大便捷
搜索是 Github 核心功能之一，而 Github 的搜索栏支持过滤器语法，可按语言、仓库、用户、收藏数等条件过滤，我认为这是一件十分符合程序员直觉的事——我上一份实习就是在谷歌做支持过滤器和自动补全的搜索栏，谷歌自己内部的代码管理平台也有非常完善的搜索功能。 - UI 设计舒适
Github 的 UI 设计简洁大方，（熬夜大户程序员喜爱的）深色模式支持良好，能够给与使用者愉悦之感。 - 丰富的第三方支持
Github 有着良好的生态，支持丰富的第三方服务。
缺点：
- 国内访问不稳定
可能是对国内开发者最不友好的问题。我们一定都体会过明明挂上了 ladder，却还是 pull 不下来代码，骂骂咧咧又打开 host 文件更新的经历。 - issue 和 pr 功能简单
社区版 Github 的 issue 不支持分级（P1/2/3…;S1/2/3）（企业版也没支持这个），pr 不能开分支保护（企业版支持这个，对保护的分支合并必须要指定的 reviewer 审核）。WIKI 也是至少团队版才能使用。但对于高校学生团队来说，付费使用团队或企业版是不必要的开销。
改进建议
对于 Github 的改进建议，我作为个体用户希望他们可以在社区版也可以引入更健全的 issue 和 pr 功能。但正如《构建之法》所说，软件企业=软件+商业模式，这也是商业模式的一部分。企业大概率不考虑采纳这样的建议。
综合评价
总体而言，我对于 Github 给出 “e) 非常推荐” 的评价，鉴于它可以几乎完全满足个体开发者和中小型团队的需求。
Gitee
使用记录
进入 Gitee 首页：
可以使用搜索栏搜索开源项目和博客：
在个人主页可以看到自己的所有仓库：
Gitee 支持从 Github 导入仓库：
可以进入自己的仓库进行查看和各种操作：
创建一个 pr：
审核并合并 pr：
综合评价
优缺点
首先从数据量/界面/功能/准确度多个维度，分析 Gitee 的优缺点。
优点：
- 国内访问稳定
快速稳定的访问，对比 Github，无疑是 Gitee 对国内开发者最大的优势之一。特别是对于主要使用代码管理平台进行小组合作开发的高校大学生，Gitee 能够提供较大便利。 - 良好的 issue 和 pr 使用体验
issue 支持分级；pr 支持指派负责人和测试人员；支持 issue 和 pr 关联；区分只读/保护/普通分支。以上功能（还有 WIKI）全部在免费版本就支持使用，与 Github 对比具有优势，大幅提升了用户使用体验。 - 丰富的第三方支持
Gitee 也有比较丰富的第三方服务支持，主要来自国内各厂商。并且 Gitee 支持一键导入 Github 和 Gitlab 仓库。
缺点：
- 用户基数有限
即使 Gitee 将工作流实现得不错，但用户基数少是现实。能够搜索到心仪的开源项目应该是代码托管平台（面对个人开发者）的杀手功能之一。但我认为这是“面对个人开发者”的，国内中小企业和高校依然可以使用 Gitee 进行高效团队开发。 - 搜索栏不够便捷
我不学 CS 的朋友们看到搜索栏可能想不到有什么过滤器语法，但我在一个代码托管平台一定下意识会使用过滤器的。很遗憾我在 Gitee 里并没有体验到这个功能。 - 不必要的外围功能
Gitee 支持账号关联博客，在搜索界面可以搜索到博文，并且推荐系统也会推荐博客。本人认为博客和推荐系统对于一个代码管理平台而言或许有些冗余。 - UI 设计拥挤
部分源自上一条分析提到的原因，Gitee 的 UI 设计给我感觉有些拥挤。或许从一进首页看到侧边长长的推荐列表开始，我会有一瞬间的恍惚自己打开了 CSDN。 - CI/CD 收费
可能不能算“缺点”，但穷学生很遗憾 Gitee 的 CI/CD 服务貌似是收费的。而对比之下， Github 社区版每月也有一定的免费使用时长。
改进建议
对于 Gitee 的改进建议，希望 Gitee 首先优化一下搜索功能和 UI 设计吧。用户基数问题或许不好解决。
综合评价
总体而言，我对于 Gitee 给出 “d) 好，不错” 的评价，鉴于它可以很好地满足中小型团队（包括学生团队）合作开发的需求，但对个人开源爱好者可能略有不足。
用户调研
我采访了一位欧阳老师软工班级的同学。该同学有一定使用 Github 的经验，但从未使用过 Gitee。作为计算机学院大三学生，ta 对于开源代码管理平台的需求主要是和同学进行合作开发，完成作业。我请这位同学用 10 分钟快速体验了一下 Gitee 的基础功能，具体主要是浏览首页及个人主页、pull 一个开源仓库到本地、push 一个个人仓库到远程。下面是同学分享使用感受（应同学要求已匿名）：
Bug 分析和提交
“选择任意一个软件（鼓励大家选择开源软件），找出至少两个功能性 bug…” 有这种事？那自然要选择本人目前实习所在公司的产品 ZENO 了。
ZENO 是泽森科工创造的一个面向高性能物理计算而研发的可视化编程系统和平台，一款全流程 3D 内容生成开源工具。 用户可以从官网或 Github 上下载发行版本或自行构建。
作为开发组实习生我显然是使用自行构建版本，举两个最近发现的 bug。
依赖声明有误
测试环境
Ubuntu 20.04, gcc 9.4, CMake 3.18, CUDA 11.8，开发者自行构建版本。
bug 复现
在上述环境中稳定发生。
bug 具体情况描述
编译选项之一 -DZENO_WITH_CUDA，在满足官网所声明的依赖 gcc 9+，CUDA 11.6 的环境中编译无法通过。（当时在视频会议里展示的，没有保留截图。）
bug 分析
- 推测成因：CUDA 优化部分主要只由一个人负责，他自己的电脑应该配置了更高版本环境，无意中使用了新版本特性。
- 严重性：一星。（假设五星为致命性系统故障、致命性安全性漏洞、用户体验严重影响；一星为无实际影响）因为使用者以及美术组员工均使用构建好的程序，不会每次从头编译；开发组员工基本也不会开和自己工作部分无关的 CUDA 选项。
- 分析原因：没有严格审查修复，主要因为软件面向的用户群体不需要用到这个功能，没有必要。
bug 改进建议
应该调整代码，使其能够在官网声明的依赖要求下正常编译。
bug 反馈
跟大哥 1 on 1 时说了一下，大哥确实不知道，用了一分钟看了一下编译报错然后表示这里需要 gcc 10 ，而他自己的机器确实是 gcc 10，验证了我对于 bug 成因的猜想。
窗口点选崩溃
测试环境
Ubuntu 20.04, gcc 10.2, CMake 3.18, CUDA 11.8，开发者自行构建版本。
bug 复现
在上述环境中偶尔发生。频率为：我每天进行 5 小时左右的开发，在经常进行可引发 bug 的操作前提下，大概每两天遇到一次。
bug 具体情况描述
当节点图较复杂，窗口显示多个物体时，在进行一系列拖拽旋转视角操作后，再点选物体，可能引发程序崩溃。
比如这样的图：
bug 分析
- 推测成因：可能是显存泄露。考虑到之前其它同事报过类似 bug，后来查明原因就是显存泄露。
- 严重性：二星。目前公司内只有两三个人的环境可能出现该问题，在大多数环境下程序能正常运行，并且发生频率不高。
而且即使 Microsoft Word 这种大软件也不时崩溃呢，大家依然都喜欢用。 - 分析原因：由于只有特定环境可以复现该 bug，负责该部分的开发者可能并没有意识到存在问题。
bug 改进建议
应该排除代码问题，提高软件稳定性，尽量降低用户使用过程中软件崩溃的概率。
bug 反馈
跟同事们说了一下，得知有一个美术组同事在我之前已经提出了，相应开发组同事正在排除问题做修改。
题外话——欢迎使用 ZENO！
第二部分 分析
让我们回到开源代码管理平台的话题上来。
工作量分析
我认为就基础架构以及完善程度而言，两个代码管理平台在常用基础功能上应该是相近的，因此共同分析。
假如我们不考虑后续的第三方服务接入和软件生态建立过程，仅考虑基础功能的开发，并且假设我们拥有充足的资源支持……说个题外话，我觉得大学生的水平差异还是挺大的，我现任职公司的架构师是个双非学校本科大四在读生 geek 老哥，像一部行走的 cpp reference，其他语言也了解不少，能力不知道比我们这种忙忙碌碌卷毕业、去互联网大厂老实写几年并不比培训班出来的强多少的前后端、裁员首当其冲的 985 毕业生强到哪里去了。虽说我是搞图形的，并没打算去写前后端。
还是试图以北航比较优秀的同学的水平估算一下时间：
-
需求分析和设计（3 个月）：目前的需求比较清晰，也有现有的模型和解决方案作为标杆，但考虑到功能繁多，具体的架构设计还是需要一段时间的。
-
技术选型和开发（2 年）：说实话我难以想象，至少我不相信我可以做到。首先需要和 git 对接，并实现网页端的 git UI；需要实现网页端的编辑器；需要对接 ssh；需要实现 issue 和 pull request 功能；需要实现仓库数据的可视化；需要对接 WIKI；需要实现 fork ，release 功能，watch 和 star 就像是顺手完成的了；需要实现 sponsor 功能；需要实现关注和提示功能；需要实现个人代码仓库统计及可视化；需要实现 CI/CD 功能；需要实现搜索功能——我大二暑假一个搜索功能实习做了三个月啊；还有不同权限用户和不同收费标准版本……我觉得两年是按照线性进度估计的，实际操作起来未必保持效率为常数。
-
UI 设计和调整（3 个月）：鉴于已经有专业 UI 团队进行设计，我们这里只需要调整时间。但考虑到上述功能的复杂程度，我认为即使只是“执行命令”式的调整也需要一段时间。
-
测试和优化（6 个月）：考虑到上述功能的复杂度，我认为在测试过程中应该会发现很多问题，问题的解决与后续优化（加上解决优化产生的问题）需要一定时间。
综上，我估计 6 个北航本科优秀毕业生全职搞 3 年也许能完成一个基础代码管理平台的开发工作吧。在实际开发中上述四个过程应该不是依次而是循环出现的，以上估计数字大约是一个总数。
软件质量分析
-
Github 以其完善的软件质量和庞大的生态体系，兼有行业先手优势，无疑稳位居同类产品之首。Gitee 作为中国内地网络情况下诞生的 Github 竞品，也已经拥有较高的产品质量，在国内市场除去 Github 和 Gitlab 外，大概位居第一。
-
对 Github 整体给予比较高的评价，如果要提建议大概是可以更加完善一些细节功能，全方位占领绝对行业优势；对 Gitee 的建议是，想要在 Github、Gitlab 已经占据先手优势的市场中占据一席之地，不能仅做到模仿和跟随，更好是要找到自己的独特优势，打造产品亮点。
第三部分 建议和规划
市场概况
-
Github 和 Gitee 等代码管理平台的市场，主要由软件开发行业从业者和计算机及相关专业学生构成。
-
直接用户：软件开发行业从业者。
根据 Statista 在 2021 年 1 月发布的统计数据，截至 2020 年底，全球软件开发行业从业人数大约 2.45 千万人，预计该数字到 2024 年底将达到 2.87 千万。
-
间接用户：计算机及相关专业学生。
对于每年全球毕业生人数没有找到比较可信的数据，但根据一篇印度报道引用的统计数据，印度每年产生最多的计算机专业毕业生（21.5 万），紧随其后的是中国（18.5 万），其他大国还有美国（6.5 万）、俄罗斯（1.7 万）。估计全球每年 CS 专业毕业生至少 50 万人。
市场现状
-
目前市场上最主流的代码管理平台，大概全球范围内最流行的就是 Github 和 Gitlab，中国国内最流行的就是 Gitee 了。
-
Github 凭借其庞大的生态体系其位居同类平台中的全球第一。除了 Github 以外，还有 Gitlab 同样在全球范围内广受开发者和特别是企业欢迎，企业可使用 Gitlab 搭建自己的私有仓库，保障私有数据安全。但以上两者由于网络问题，在中国国内都会遇到使用上的麻烦。Gitee 在国内大约是除去 Github 和 Gitlab 之外最受欢迎的同类产品，但在国际范围内影响较小。
Github 注册数超 1 亿：
Gitlab 注册数超 3 千万：
Gitee 注册数超 1 千万：
-
他们三者部分主要功能重叠，互为竞品。但 Gitlab 一大特色应用场景为公司可独立搭建私有代码仓库。而 Gitee 作为国内产生的竞品，就我作为个人使用者的体验视角，其主要竞争者还是国际领头羊 Github。（Github 的企业版我是使用过的；但Gitee 的企业版没有尝试，不甚了解。）
-
目前三者均呈上涨趋势，对比往届学长博客中引用的统计数据可以对比得到这一结论。虽然 Github 已经较为成熟完善，难以做出改变适应新潮流，但凭借其强大的功能、庞大的生态，在短时间内其领域领头的位置不会改变。Gitlab 同理。Gitee 的主要赛道为国内市场，其也不断完善着对国内市场的特色支持，用户量上涨，但短期内还很难撼动 Github 在国内市场的地位。
市场与产品生态
-
核心用户群正如前文分析，由软件开发行业从业者和计算机及相关专业学生构成。
列举以下几类典型用户（以下人物在本人现实生活中均有原型）：- 成锋，30岁，国内 top 2 计算机专业本科毕业，某国际大型互联网公司 dev，爱好周末骑公路车，每月稳定收入 5 万左右，需求是休息时间在开源代码平台上寻找和工作内容相关的优秀的开源项目，吸收借鉴到日常开发工作之中。
- 王垒，31岁，国外名校计算机专业博士毕业，某创业公司核心员工，公司主业务为打造一款开源软件，爱好是看 c++ talk 和开发库，收入随公司项目拿奖金，
好消息是公司一直都有项目，主要需求是利用企业版开源软件管理平台和同事合作开发，潜在需求是使用完善的 issue 和 pr 机制审核并通过同事代码。 - 金众，35岁，国内某 985 计算机专业本科毕业，目前同时从事多份开发工作，爱好却是作为独立开发者贡献开源代码，收入成谜，
收入合法性成谜，反正从来不缺钱，表面需求是利用开源代码管理平台托管自己的产品，潜在需求是给他人的仓库提 issue 和开 pr，参与开源贡献。 - 姜竹，20岁，计算机专业本科在读学生，爱好是读书，月收入只有 4 位数实习工资，表面需求是利用开源代码管理平台和同学合作开发完成软工作业，以及学习他人的优秀软工项目，潜在需求是熟悉合作开发流程和代码管理技术，
为大四兼职更高薪实习做铺垫。
-
典型用户 2 和 3 也部分存在着典型用户 1 的需求，典型用户 4 可以成长为典型用户 1 或 2 或 3。
-
对于同一个开源代码管理平台可能有多个版本，社区版的主要用户可能是典型用户 1 和 3；企业版的主要用户可能是典型用户 2；学生版（如果有）的主要用户可能是典型用户 4。面向学生的子产品可能为企业版或团队版增加用户，因为学生毕业后可能加入企业或创业。
产品规划
-
我想加入书签功能。即用户可以通过点击某行代码左侧来将其加入用户在该仓库的书签。目前 Github 的浏览功能不是很友好，每切一个文件就要重新加载。但书签功能再结合 Github 新的 code view——代码左侧文件树，可以提高用户浏览代码的使用体验。
项目 内容 Need 目前 Github 的代码浏览用户体验不佳 Approach 加入书签功能，用户可以对重点代码行做标记 Benefit 改善用户的代码阅读体验，无需 clone 也可以快速理解仓库代码 Competitors 大概没有竞争者，相似功能的代替也只能是用户 clone 到本地然后使用编辑器打开并添加书签 Delivery 凭借 Github 本身的流行程度普及这项功能 -
6 人角色与分工如下
- 架构师 & 救火员： 1 人
- 美工 & 前端开发：1 人
- 前端开发 & 测试：1 人
- 后端开发 & 测试：2 人
- 测试 & QA：1 人
-
周数 任务 1 需求分析，工作流确认 2-3 技术栈确认，架构设计 4-5 前后端框架构建 6-8 具体开发，同时进行单元测试和每日构建测试，每个模块加入总架构时进行集成测试 9 alpha 测试，bug 修复 10 beta 测试，bug 修复，总结反馈意见 11-12 根据反馈意见修改产品，过程中做测试 13 beta 测试，bug 修复，总结反馈意见 14 根据反馈意见完善细节 15 部署至生产环境 16 产品上线