软件工程-案例分析作业 开源代码托管平台
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 案例分析作业 |
| 我在这个课程的目标是 | 掌握并实践利用软件工程方法构建大规模高质量应用的技术，提升自身工程能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过分析对比不同软件的设计，从用户角度理解一个软件产品的关注要点，更好地指导我们实践软件工程原则 |
我选择的分析对象是Code China，Gitee和Github三款产品，它们都属于基于代码仓库管理系统Git的开源社区。
第一部分 调研，评测
Code China
Code China是CSDN发布的开源代码托管平台，基于Gitlab CE 13.7版本搭建，并针对中国用户进行一定的本土化。
基本使用
Code China账号体系与CSDN互通，由于我之前没有注册CSDN账号，首先进行注册。但令人叹为观止的是，CSDN现在注册必须使用微信，扫码关注一个公众号，然后才能使用手机号注册。这里的用户体验自然是有一些不顺滑的。尽管考虑到CSDN作为一个商业公司，为了流量和存活率等KPI，使用一定的手段进行保活、引流也确实无法责备。
补充：在写本文的过程中我曾在不同操作系统上登录此账号，结果CSDN账号居然在登陆时要求我关注一个新的公众号，截至目前笔者已经关注4个不同的公众号了。我认为此处的用户体验非常差劲，用户可以忍受一次注册时的麻烦，但不应当每次登录都要被麻烦一遍。
下一步登陆后我们可以跳转回一开始的界面，在这里有整个社区关注度较高的项目、Topic等，每个Topic下都可以看到与之相关的项目，随意点开一个项目就可以进入到这个代码仓库的详情界面。代码仓库的详情页面是代码管理平台的重中之重，在下文中将以一个新创建的仓库详细描述。
点击右上角的加号，就可以创建群组和代码仓库、代码片段等，在创建仓库时，可以创建一个空的项目、也可以从外部（目前仅限Github）导入或模板导入。为了体验仓库内各种管理功能，笔者从Sample GitLab Project模板创建了一个测试项目，并进入项目的详情页面
在进一步介绍Code China的使用体验前，需要先说明类似的开源项目托管平台的核心工作流程。开发者首先创建一个仓库并且向相关开发人员分配权限。有开发权限的人们在不同分支（Branch）上开发不同功能，每次变动以一个提交（Commit）来体现。一个分支开发完成后，需要将其合并（Merge）到其他分支时，需要使用合并请求（Merge Request）功能。项目开发者外的人想对项目中的代码作出改动时，需要分叉（Fork）出一个属于自己的拷贝，在其中进行修改，修改完成后通过合并请求向项目所有者提交。任何人发现项目中的问题时，可以向项目提出事项（Issue），项目管理者可以分配这些事项，并在完成后关闭（Close）这些事项。
笔者曾经在过去的生活中用过类似的代码托管平台，因此对此界面非常熟悉，几乎所有的代码管理平台都采用了类似的结构。最上面是这个代码仓库的名称，相关通知选项和关注、分叉数目，这些都是评定一个项目流行度和重要性的重要指标。再向下是功能区，包括了在上文工作流程中提到的各种核心功能的选项，在鼠标移动到上方时也会有子菜单弹出。下面的界面就是对应功能区的图像。
值得一提的是，由于代码托管平台功能太过庞大，笔者只能通过体验其中最核心的部分，并据此进行分析。
首先是代码管理页面，打开一个项目后默认即进入此页面，可以看到代码仓库的分支，提交历史和每个文件及其更改时间。点击文件可以进行内容的预览，右侧则是项目的主要信息，主要供该仓库所保存软件的用户下载相关发行版（Release）。
Issue界面和合并请求界面都提供了对相关内容的管理，允许的操作主要是标记、分配以及进一步的互动
Wiki页面则是项目相关的百科说明，分析页面提供了项目所用语言和提交的分析（此处用开源项目举例）
项目成员和项目设置顾名思义，而Pages则是Code China提供给开发者的免费静态网页托管服务。由于政策原因，Pages App 目前仅针对认证组织开放使用，因此笔者未能进行体验。
在互动方面，Code China提供个人主页，可以进行Follow、查看个人相关项目和贡献历史
Bug描述
Bug描述量化指标
Bug的严重性按照1-5评级，详情见下表
| 严重性 | 描述 |
|---|---|
| 1 | 用户体验会受到略微影响，但用户的主要目标仍能完成 |
| 2 | 小规模Bug，用户请求的主要目标功能无法提供，但可以通过其他办法提供服务（刷新、其他入口等） |
| 3 | 一般系统故障，用户请求的功能无法提供，且不可通过任何方法绕过，或对用户体验产生极大影响 |
| 4 | 严重系统故障，一个或多个功能彻底不可用，用户非敏感信息可见 |
| 5 | 致命漏洞，用户关键信息泄露、主要服务大面积失效或次要服务完全失效 |
Bug1：项目贡献者页面，在数据量大时出现类卡死现象
此问题已在Code China官方Issue区反馈，地址：issue234
- Bug发生时的测试环境：Ubuntu 20.04, Chromium 89.0.4389.90 SNAP镜像版
- Bug的可复现性：特定条件下发生。
- Bug复现条件：项目拥有大量贡献者（15+）且在较长时间内有较多提交记录
- Bug复现步骤：
- 选择一个有着大量贡献者的仓库，如sonic-pi ，点击代码菜单下的贡献者选项，开始加载，加载过程中页面其他位置点击无效，鼠标指针变为手型。
- 加载完毕后，拖动时间轴并尝试用滚轮滚动页面，页面无响应，用鼠标拖动滑条滚动页面，则会出现空白。
-
Bug具体情况描述：在上述操作过程中，此页面工作不正常，用户浏览器响应缓慢，甚至会提示页面崩溃
-
Bug分析：
- 成因分析：加载大量数据并在页面上显示的过程阻塞了主线程，行为类似于在主线程阻塞等待数据导致的卡顿，可能可以通过按需加载、懒加载、异步加载（可能需要修改框架）等方式减少卡顿。
- Bug的严重性：3级
- 系统功能：功能能正常展现，但是耗时较长
- 安全性：用户数据不会遭到损坏
- 用户体验：极差，给定功能无法完成，同时导致用户的浏览器卡顿
- 对于Bug的预期及改进建议
- Bug预期：修复后，加载时不在卡顿，或者加载时展示动画，任何情况下页面均不可处于无响应状态
- 此Bug可能导致用户正在进行的其他工作受到影响，基于此给出严重性3星的评价
- 改进建议：通过改进加载方式减少卡顿，任何情况下页面均不可处于无响应状态，更不能影响用户的其他页面。
Bug2：在将Merge Request添加到待办后，同一页面标记为已完成时出现错误
此问题已向Code China官方Issue区反馈，地址：issue239
- Bug发生时的测试环境：Windows 10 19042.867, Firefox 87.0
- Bug的可复现性：特定条件下发生。
- Bug复现条件：由模板建立的私有仓库中可稳定复现。
- Bug复现步骤：
- 新建私有仓库，使用
Sample Gitlab Project模板 - 随意合并一个Merge Request
- 选择另一个Merge Request，将其添加到待办事项
- 标记为已完成
- Bug出现，提示错误并且无法添加待办事项
- 新建私有仓库，使用
- Bug分析：
-
成因分析：第一次添加待办后，前端并不知道待办的对应id，因此标记完成时路径中不存在正确参数导致出错，但为什么没有相关数据尚不清楚，可能是后端编码问题
-
Bug的严重性：2级
- 系统功能：用户功能不能正常完成
- 安全性：用户数据不会遭到损坏
- 用户体验：较差，给定功能无法完成
-
对于Bug的预期及改进建议
- Bug预期：修复后，能正常处理此种情况
-
Bug3：常见缩放率（125%）下Web IDE不能正常使用
此问题已向Code China官方Issue区反馈，地址：issue252
-
Bug发生时的测试环境：Windows 10 19042.867, Firefox 87.0，缩放率125%
-
Bug的可复现性：可稳定复现
-
Bug复现步骤：打开网站Web IDE直接可见
此外，在其他缩放率下，Web IDE也不能正常表现
-
Bug分析：
- 成因分析：CSS设置出错，导致部分项目被隐藏。
- Bug的严重性：4级
- 系统功能：功能完全不能正常使用
- 安全性：用户数据不会遭到损坏
- 用户体验：极差，给定功能无法完成，而且必须等到完成所有修改需要提交的时候才能发现
- 对于Bug的预期及改进建议
- Bug预期：修复后，Web IDE可以适应多种不同的分辨率
- 此Bug可能导致用户工作白费，无法通过除修改分辨率外的任何方式解决（用户并不一定具备这一知识），而且必须等到完成所有修改需要提交的时候才能发现，基于此给出严重性4星的评价
采访
被采访者C同学也是计算机学院的学生，使用过OO的GitLab平台和GitHub平台，以下是采访记录
上下文需显式指明的混沌对话可能性微存（x
综合评价
Code China可以明显看出，是一个还处于刚起步阶段、很不成熟的作品。发布于2020 年 9 月 10 日，毕竟还是太过年轻。但从另一方面看，其表现也不能让人满意。Code China基于Gitlab CE 13.7版本，基本不用做后端的复杂编码，简单的本土化也不能令人满意。除了上文的Bug 3严重影响用户体验，还有包括错误反馈不准确、中英文混杂等大量影响用户体验的问题，限于篇幅无法再次详述，放上两张图片作为展示。
此外，Code China在作为代码的托管平台上，也有不尽人意之处。对于开发者至关重要、GitLab内置的持续集成功能，却由于不明原因（可能是Runner的资源花销？）无法实装，这对开发者的留存体验大有影响。目前，在开源广场部分看到的大量项目，都是在与Github或其他托管平台同步，也就是作为镜像。在这种情况下，Code China没有原创的优质项目，在竞争中必将处于劣势。
对于在校大学生的学习平台，Code China并没有突出其独特优势。没有可以用于软件工程课程的代码质量评估、教师管、评分工具；也没有针对学生使用场景的优化。
综合以上，我对Code China的评分为30/100，不推荐。从软件用户的角度，Code China功能不完善，社区活跃度低；从商业角度看，Code China目前的知名度已经足以说明一切，我身边长期使用代码托管平台的同学对他无一知晓。如果Code China不能如《构建之法》所说发掘出其特色，尽快补上短板，并做出与同类软件差异化的服务（Killer Function），在我看来没有什么成功的希望。
GitHub
GitHub是世界上最大的代码托管平台，有数百万的开发者在其上分享自己的代码，大量企业公司也在上面分享自己的代码。可以说Github是开源界的一个重要标杆。
基本使用
笔者已经在Github上上传过一些代码，在之前的博客中，也使用过Github Actions作为持续集成的工具。由于某些原因，近日来国内与Github的连接已经恶化到了近乎无法正常使用的情况。下文的使用体验中，在不涉及到与其他同类比较时，会自动忽视所有的不稳定/加载延迟大，因为正常情况下不应出现这种问题。
注册页面较为简洁，只需提供信息即可快速开始工作
登陆后进入主页，Github有完善的深色主题支持（太棒啦）
主页上可以看到时间线，你关注的人的动态
打开项目，管理页面也大致相同
相比Code China（其实是Gitlab），GitHub的Issue区对记录功能和一些快捷指令的支持更少一些，但是对于编辑器的易用性做得更好。这可能是两者不同的定位导致的，Github作为大规模开源社区，会有大量非专业用户打交道提交Bug，因此在易用性上做得更出色，而Gitlab作为领先的开发和持续集成平台，自然更多面向专业人士。
Github的持续集成服务称为Github Actions，虽然显得略微繁琐，但是功能上同样能实现几乎所有Gitlab能做到的。且由于社区市场的存在，极大地简化了配置的上手难度。
更难能可贵的是GitHub的生态，GitHub支持许多第三方服务，均可以方便地接入，而放在其他代码托管平台上，却可能需要大量复杂配置，这也是GitHub的体量优势之一。
体验全程除了网络问题，没有遇到影响体验的Bug，难能可贵。
针对大学生使用方面，GitHub有推出学生计划和校园计划，但大多是一些资源的分配与联动。而真正对准学生学习方面的特色功能，几乎没有。
综合评价
综合以上，我对GitHub的评分为85/100，不错。GitHub强大的生态让其在开源领域成为毋庸置疑的首选。GitHub本身也没有辜负这份期待。通过不断向其他平台学习其长处（例如Actions的推出），不断优化用户的体验。扣分点主要是网络连接，以及没有对国人的使用习惯和大学教学做出优化。这当然不是GitHub做不到，而是其核心用户不在此，因此只是做到了一般应有的功能，这也是差异化策略的体现和我们国内软件的机遇。
Gitee
Gitee
基本使用
可以看到，Gitee并没有直接使用现成的Gitlab方案，而是自己创新了很大一部分内容（包括但不限于：更好的Markdown预览、更好的代码分析等）整体而言，Gitee对代码管理创新了很大一部分内容，从代码仓库的创建到Issue的分类，都可以快速引领开发者适应在线开源平台的使用，在我看来这是GitHub都没有做的太好的地方（家大业大，不做影响不大）。但是Gitee也有缺点，整个界面略显臃肿，而且间距较小，让用户有一种压迫感（？）。
考察Issue界面，Gitee的编辑器功能不太多，主要以Markdown为主，而且预览按钮藏得挺深有点影响用户体验。不支持嵌入快捷操作，但是在Issue分类的想法相对较为新颖。这一选项在其他代码仓库平台中多由标签功能提供，但Gitee将其下放给用户，可以一定程度减少开发者的负担。
个人认为，Pull Request（Merge Request）是Gitee做的非常出彩的一部分，此处直接集成了缺陷扫描、规范扫描和依赖项报告等第三方或内部支持（Gitee Scan），可以在Merge之前检测代码的质量并及时发现问题。其他代码仓库平台中也可以做到这一点，例如采用Merge Request前的自动CI进行检测，但Gitee的方法极大增加了直观性和用户体验。
Gitee有着一定的第三方支持，虽然数量上比不上GitHub，但是集成的简便性和紧密程度却更高，这也是Gitee的护城河和“杀手级应用”之一。
针对大学生的支持上，Gitee有专门的高校版，特别对高校的作业收集、作业批改提供了针对性的功能
（由于笔者无法申请相关权限，只能通过其宣传视频内容进行分析）
但是可以看到，Gitee的高校版是利用了传统的Fork-Pull Request机制来检查作业，还是在Git管理的那一套里面。虽然可以锻炼学生们使用开源平台的工作流程，但是这终归不是真正的开发流程，且还是会为教师平添麻烦，这只能说是Gitee的折中。考虑到市面上针对大学生的服务很少，可以认为Gitee这一策略有其道理。
Bug说明
Bug1：选项中仓库挂件功能直接跳至404页面
-
Bug发生时的测试环境：Windows 10 19042.867, Firefox 87.0，缩放率125%
-
Bug的可复现性：可稳定复现
-
Bug复现步骤：打开设置直接可见
- Bug分析
- 严重性：需要考虑此功能是否真的不可用，如果真的对用户不可用（可能很大），那么只有1星，影响用户体验，没有详细错误信息；但如果是用户可用，则可以算得上4星，某功能完全失效
- 可能原因：该功能错误提示未做好
- 预期：提示错误原因，如需要企业版才能访问等
综合评价
综合以上，我对Gitee的评分为90/100，推荐。之所以能比GitHub多5分，原因在于他的国内连接体验，和其针对大学生群体的优化措施。可以看出Gitee在自主创新方面做出的长足进步，在GitHub无法正常访问的情况下，对于通用目标的开源项目，Gitee应当是我们最好的选择。在各个层面上，Gitee也正在成为国内开源生态的领头羊，这与其针对国人习惯优化过的工作流程大有关系。对大学生来说，能有一个本土支持良好、有大量本土项目的学习平台作为入门，也是幸事。
第二部分 分析
由于三个平台底层的基础架构都比较相似，因此在这里统一分析问题一中需要的时间，给出完成基础功能的时间，再针对每个项目进行分析
直言不讳地说，想要从0开始做到和三个网站相同的程度，仅靠六名大学毕业生是几乎不可能做到的。但是假设我们有无限的时间，而且可以参考GitLab的设计，允许出现Bug（GitLab也不是一天搭起来的！[理直气壮脸]），可以使用云服务厂商提供的能力（云数据库、对象存储等），不计算集成和测试时间，按照北航计算机系大学生的平均水平，我们可以做出如下时间估计
- 用户账户管理以及权限、组、相关密钥的安全配置：16周
- Git仓库可视化及Web UI、在线文件查看：12周
- Git仓库权限管理与用户账户的结合：24周
- Web IDE：12周（借用已有开源代码）
- Issue区和Merge Request区、项目管理功能如看板、MileStone，以及与Git和上文功能的联动：28周
- Wiki、统计、Fork、Release、导入导出等功能：共计16周
- Watch、Star等项目通知功能：4周
- 基础持续集成功能：24周
- 第三方接入功能、WebHook：12周
- Group功能：8周
- 代码片段功能：8周
- 互动、个人主页：8周
- 搜索功能：4周
- 管理员功能：12周
- Web API：4周
- 高并发部署压力测试的研究：8周
- 高可用备份机制异地容灾：8周
因代码协作平台功能太过特殊，以上统计不一定能完全覆盖所有点，共计204周，大概三四年时间，同时应该也只能得到一个不是很完善的初代版本
Code China
-
使用此服务的所有功能，估计这个软件/网站/服务做到这个程度大约需要多少时间(团队人数6人左右，计算机大学毕业生，并有专业UI支持)。
如果允许使用GitLab CE作为基础，那么估计需要做到Code China的现有程度需要两个半月左右，半个月用来熟悉GitLab代码框架，半个月添加Pages功能，最后一个半月进行功能测试和压力测试、部署以及上线（我实在是没看出来有什么要改的点啊[溜]）
如果以上文的时间安排做基础，甚至还能省去持续集成的实践（溜
-
分析这个软件目前的优劣(和类似软件相比)，这个产品的质量在同类产品中估计名列第几？
上文中已经提到过，Code China的同质化（很少的特质）让他比起是一个大公司推出的平台，更像是几个人搭建的GitLab私有部署。当然，能够应付高并发部署的能力是私有部署不能做到的，因此在同类产品中可以排第四（ GitHub > Gitee > GitLab及其私有部署 > Code China）
-
从各方面的问题，推理出这个软件团队在软件工程方面可以提高的一个重要方面(具体建议)。
追短板，构建自己的长板
提升开发认真度，不要对开源代码太过相信，开源代码也有Bug，要做足自己的测试
-
你在第一部分发现的bug，为何软件团队不能在发布前修复？他们是不知道，还是有意不修复？你觉得是什么原因？
Bug内容 可能原因 Bug1：项目贡献者页面，在数据量大时出现类卡死现象 认为开源项目已处理好或者认为此功能不重要，没有考虑到对用户其他行为的影响 Bug2：在将Merge Request添加到待办后，同一页面标记为已完成时出现错误 测试把关不严，敷衍了事，没有注意在特殊的配置或环境下测试 Bug3：常见缩放率（125%）下Web IDE不能正常使用 测试把关不严，敷衍了事，在正常环境下也没有测试而是认为想当然的正确
GitHub
-
使用此服务的所有功能，估计这个软件/网站/服务做到这个程度大约需要多少时间(团队人数6人左右，计算机大学毕业生，并有专业UI支持)。
不考虑生态的搭建，在前文所述的基础上，还要加入
- 大量第三方服务的接入及社区市场：24周甚至更长，取决于人的因素
- Actions的社区市场：4周
- 客户端的开发：8周
- 安全性问题的特殊讨论区：4周
- 企业版需要的审计、二步验证、Single Sign On等：20周
-
分析这个软件目前的优劣(和类似软件相比)，这个产品的质量在同类产品中估计名列第几？
GitHub庞大的开源生态是他最大的优势，劣势在于为了迎合最大量的客户，必然牺牲一部分小众客户的体验，强行要求大而全只会带来繁杂的界面和糟糕的设计。因此，在细分市场、针对特定群体的功能、是GitHub最大的软肋。但是我们无法否认Github的质量，我认为他在同类产品中能排到第一。
-
从各方面的问题，推理出这个软件团队在软件工程方面可以提高的一个重要方面(具体建议)。
适当考虑非典型用户，增加例如新用户的使用指导等功能，将用户由依附生态转化为依附自己的独特功能
-
你在第一部分发现的bug，为何软件团队不能在发布前修复？他们是不知道，还是有意不修复？你觉得是什么原因？
我没能在GitHub中找到功能性Bug，只找到了一些鸡毛蒜皮的，极端情况下出现的影响不大的问题（什么超长输入的显示啊、窗口拉到最小啊，我自己都感觉实在是鸡蛋里挑骨头，所以就不写了）
Gitee
-
使用此服务的所有功能，估计这个软件/网站/服务做到这个程度大约需要多少时间(团队人数6人左右，计算机大学毕业生，并有专业UI支持)。
不考虑生态的搭建，在前文所述的基础上，还要加入
- 多种第三方服务的深度集成：16周
- 企业版需要的审计、二步验证、Single Sign On等：20周
- 私有化部署方案：6周
- 高校版的特殊功能和优化：12周
-
分析这个软件目前的优劣(和类似软件相比)，这个产品的质量在同类产品中估计名列第几？
Gitee可以说是中国开源行业的领头羊，有着自己独特的思考，功能和优化。在高度可定制的自动化方面做的较少，取而代之的是团队理解的属于Gitee的流程，和其他开源代码托管平台相比，生态稍显封闭。而且本土化居多，没能走向世界，再加上政策等原因带来的限制和商业上的考虑（干什么都要注册账号手机号实名），我认为他在同类产品中排名第三，还有一些细节需要优化。
-
从各方面的问题，推理出这个软件团队在软件工程方面可以提高的一个重要方面(具体建议)。
开放并包，想要成为更大的公司，就不能将用户限定在自己的流程里，广泛接纳第三方，才是走向流行的开始
-
你在第一部分发现的bug，为何软件团队不能在发布前修复？他们是不知道，还是有意不修复？你觉得是什么原因？
我认为团队并不知道，而且此功能隐藏较深，危害较小，且404页面一定程度上给出了提示，因此没有被发现。
GitLab
虽然上文没有写这一项，但是我认为，写开源代码托管平台，就绕不开GitLab这一尊大神。这也是我认为同类产品中排名第二的软件。以一个社区主导的开源项目来要求，GitLab满足了我心中几乎一切想法。丰富的自定义功能、强大的可拓展性、开放源代码可自行部署的灵活性都是其值得称道的点。只可惜，GitHub所属公司及用户体量远大于GitLab，因此在一些细节GitLab仍不及GitHub。再加上GitLab太过针对专业人员，因此流行度不及GitHub。尽管如此，在大公司内部等需要代码管理平台时，自建GitLab实例还是最常见的选择。
第三部分 建议和规划
市场概况
-
市场有多大：
可以认为每个软件从业人员都是开源代码托管服务的潜在使用者，但开源代码托管服务平台的使用者远不止于此，开源软件的用户会需要在相关平台上提供反馈，高校计算机师生需要在开源代码托管平台管理自己的项目，相关领域的科研人员需要共享自己的代码，这是一个无比庞大的数字。
对比2019和2020年GitHub发布的年度报告来看，GitHub仅去年一年就增加了约1000万用户，考虑到近年来计算机相关领域的热度，这个数字应当会不断增大。因此，未来市场上的潜在新增用户在2-3年内能保持约在1000-1200万的数量级。
-
直接用户：SlashData在2019年发布的软件从业者群体报告认为，截至2018年底全球有1900万活跃的软件开发者。
Evans Data在其Worldwide Developer Population and Demographics Study 2020报告中，认为全球开发者人数大约有2300万人。
-
间接用户：每年计算机专业大学生新增约10余万人，开源软件用户稳步增长
市场现状
市面上目前主流的开源代码托管平台就是Github、Gitlab、BitBucket和国内的Gitee、Code China了
无论在国际市场上还是国内市场上，GitHub显然都占据了最大的比例，据GitHub自己发布的报告，目前GitHub有5600万用户，这个数目可谓相当庞大。而Gitee在国内市场走势喜人，在百度指数上可以拿到第二的名次，但在国际市场上却没有那么响的名声。BitBucket是国外一个比较小众的平台，可以和其母公司提供的其他管理服务高效的协同，在国内并没有太多的用户。
至于Code China？
关键词Code China未被收录
——百度指数，2021/4/8，当添加code china关键词时
下面，将分析Github、Gitlab和国内的Gitee、Code China的优势和劣势，这几个软件功能都在一定程度上重叠，可以互为竞品。但是GitHub、Gitee和Code China之间竞争更激烈，而GitLab则与Gitee企业版在另一赛道争夺。
| 产品 | 优势 | 劣势 | 用户人数 |
|---|---|---|---|
| GitHub | 强大的生态环境，先发优势以及较高的软件质量 | 很难对市场的新潮流做出快速反应，国内网络原因难以使用 | 5600万+ |
| GitLab | 可独立部署，保证数据安全；专业的DevOps能力 | 不太适用于大范围开源分享，国内网络原因难以使用 | 100,000+公司 |
| Gitee | 访问速度；第三方深度嵌入；适合国内的生态；对国内企业和高校的优化 | 灵活性稍差，细节不如同类产品 | 600万+ |
| Code China | 访问速度快，依托CSDN | 服务还尚不完善 | 3100+* |
注意，Code China的3100+万用户其实是CSDN账号下的3100+万用户，这些用户里很大一部分人甚至没有听说过Code China。
市场与产品生态
- 典型用户
- 扬梓铭，男，25岁，大学毕业。兼职程序员，同时是一名自由软件开发者，发布并维护多个开源项目，收入主要来源于用户对软件的赞助和个人的兼职工作。对开源代码托管平台的需求主要是能高效管理、发布代码，同时可以与软件用户和其他开发者互动，共同维护开源项目。潜在需求是相关的变现能力。
- 丁诗语，女，21岁，大学学生，在学校指定的开源代码托管平台上完成软工作业，与同学结对编程，并在平台上提交作业，接收老师的反馈。对开源代码托管平台的表面需求是快速上手，易于完成作业的提交等功能。潜在的需求是能有效学习代码管理的技术，可以快速上手其他代码平台。
- 李毅隆，男，32岁，大学毕业，芒代互联网公司高层主管，主管公司代码管理及安全。对开源代码托管平台的表面需求是在公司内部能高效管控代码，可以提供丰富的代码检查和拓展功能以适应公司的工作流程。潜在需求是对安全性和数据保密性方面的要求，高效的权限控制以及严格的访问审查（aduit）机制。同时也会考虑将公司部分业务代码在互联网的开源平台上开源。
- 枯瑟椿，女，26岁，大学毕业，专职程序员，使用公司内网的代码服务器提交业务代码，同时在下班后在互联网的开源平台上查找有趣的项目，学习其代码并在工作中适当运用。对开源代码托管平台的需求主要是能快速发现自己感兴趣的项目。
- Kris Cui，中文名崔隽兵，男，28岁，大学毕业，加拿大人，现在中国工作，经常在网上查找好玩的开源项目并抢先试用。表面需求是快速发现高质量的项目，潜在需求是有关项目的自动Release和与作者的互动。
- 产品的用户群体之间是否存在一定的关系？是否有利用其相互作用二次构成特定用户生态的可能性？
- 典型用户1和典型用户4是有重合的，但在单位工作时表现为典型用户4，而在自由时间则表现为典型用户1.在工作时间对开源代码托管平台的体验会极大影响在自由时间内的选择。
- 典型用户2可能会成长为典型用户1或3或4，学生时代使用的开源代码托管平台体验会极大影响未来的典型用户1或3的选择，典型用户4对内网的代码服务器没有选择权，但是在下班时间的选择也会受到学生时代体验的影响。
- 产品的子产品，以及其他相关产品之间是否存在一定的关系？是否有利用各个产品特性之间的相互关系二次构成产品生态的可能性？
- 正如上文所说，这几种产品可以分为三个赛道
- 面向大众的，主要用户是典型用户1、典型用户4（下班后）和典型用户5的代码管理平台，代表产品为GitHub、Gitee和Code China
- 面向企业的，主要用户是典型用户3、典型用户4（上班时）的代码管理平台，代表产品为GitLab、Gitee 企业版
- 面向学生的，主要用户是典型用户2的代码管理平台，代表产品为Gitee高校版，以及学校课程组自建的GitLab平台
- 这三个赛道中，面向学生的产品会有效为其他两种产品引流
- 正如上文所说，这几种产品可以分为三个赛道
产品规划
-
你要在当前软件的基础上设计什么样的新功能？为何要做这个功能，而不是其他功能？为什么用户会用你的产品/功能？你的创新在哪里？可以用NABCD分析。
我计划在Code China中加入高校老师对学生作业的一键收取、统计、评价和返还功能
项目 内容 Need 高校计算机专业有许多大作业项目需要协作完成，老师收发作业存在版本混乱、下发困难等问题 Approach 通过在代码管理平台层面加入对高校教学的支持，一键收取作业，发布作业，统计进度，评价返还 Benefit 减少教师教学负担，便于过程性检查和教学管理 Competitors Gitee高校版是目前唯一对高校教学提供特殊模式的代码托管平台，但是收作业操作复杂，我们可以以更方便的操作加快进入市场 Delivery 借助CSDN的在高校师生中的流行，可以有效 -
如果你是项目经理，可以招聘6个人，并且有4个月的时间，你认为应该如何配置角色(开发，测试，美工等等) 才能在第16周如期发布软件的改进版本，并取得预想中的成绩。
- 架构&后端开发：1人
- 后端开发&测试：2人
- 前端开发&测试：1人
- 测试及QA：1人
- 美工&前端开发：1人
-
请为你的团队设计16个周期每周的详细规划。
周数 任务 1 需求分析，开发规范确定 2 学习Git结构，设计后端架构和前端UI 3 后端：班级成员管理模块、权限管理及单元测试 4 后端：一键收取作业、批改作业及发放功能及单元测试；前端：班级管理模块及单元测试 5 后端：统计功能；前端：作业相关前端功能及单元测试 6 后端：安全性测试；前端：教师统计信息查看页面 7 后端：高并发调试；前端：适配多种设备 8 集成测试，修复Bug 9 Alpha测试并修复Bug 10 Beta测试，修复Bug并听取反馈 11 根据反馈添加新内容并测试 12 再次开展Beta测试，修复Bug并听取反馈 13 根据反馈选定功能，Frozen需求，并完成需求和单元测试等 14 集成测试、压力测试 15 灰度部署 16 全面上线
