软件评测
| 这个作业属于哪个课程 | 课程班级 |
|---|---|
| 这个作业要求在哪里 | 作业要求 |
| 这个作业的目标 | 对我们正在使用的某类产品中的代表性产品进行分析、评测 |
| 其他参考文献 | 百度、知乎、简书、CODE.CHINA、GitHub、Gitee |
[toc]
调研，评测
注：代码托管平台系统是一个非常庞大的系统，里面包含了许多的功能。因为篇幅限制，我不能展示所有的功能，而是关注于该平台的主要功能和特色功能。
本篇博客的所有内容均为个人观点，并无恶意，欢迎大家共同探讨。
CODE.CHINA
体验
基本功能
- GitHub加速功能
这个功能是CODE.CHINA最吸引我的功能之一，也是它的特色功能。这个功能的使用是通过CSDN平台来使用的。CSDN作为业内常用的博客平台，我们常常会在上面阅读别人的博客或者自己发布博客，许多的博主也会在博文中贴出代码的GitHub地址，众所周知，GitHub在国内的网速不敢恭维，而CODE.CHINA的这个功能就是为了解决这个问题的。用户只需要点击GitHub代码地址就能显示是否要加速。原理是通过CODE.CHINA平台来观看GitHub上的代码。
- 使用模板来创建仓库
这也算是CODE.CHINA平台的一个特色功能。它可以在创建仓库的时候选择一个模板，简化开发者的使用。
- 基本的代码托管功能
CODE.CHINA支持基本的代码托管功能，包括仓库的管理、分支管理、issue管理、项目成员管理、代码合并、组织管理等功能。
优点
- 和CSDN平台的紧密结合
CODE.CHINA一面世就是一个和开发者社区CSDN紧密结合的平台。CSDN上发布的代码可以很方便地使用CODE.CHINA平台打开，两个平台的账号可以通用。对于用户来说，一边看着博主的博文，一边对照代码是一个方便的学习方式。
- 中国化的平台
CODE.CHINA平台是一个基于GitLab的代码托管平台，对GitHub进行了一些中国化的改进，更加方便国人的使用。
- GitHub加速
GitHub平台网速非常慢，经常连接超时，使用这个功能可以解决开发者观看代码的问题，且该功能和CSDN结合，更加方便用户使用。
- 便捷的用户体验
代码的创建可以使用多样的框架模板，可以简化用户的操作；CODE.CHINA具有代码片段的功能，可以方便用户记录自己的灵感和关键代码等。
缺点
- 界面内容复杂
不管是在主页上还是在仓库的界面，都可以看到这种推广、广告等信息，导致界面复杂，界面上无关的组件过多，对开发者不友好。
- 开发功能不充足
从主页面上可以很明显地看出，更多更加细致的功能不如GitHub。例如不能使用serverless、sonarQube等功能。
- 开源代码少
作为一个新出不久的代码托管平台，可以很明显地看出平台上大家开源的高质量代码不多。
改进意见
- 简化界面，尽可能把和开发无关的部分剔除
- 添加开发所需要的一些功能
- 拉拢著名的开源项目在平台上发布代码
BUG
bug等级
| bug等级 | 说明 |
|---|---|
| 一级（Minor） | 轻微bug。不影响用户达到目的，大多是界面、提示等问题。 |
| 二级（Major） | 一般bug。对用户达到目的产生阻碍，但仍然可以达到目的。大多是需要用户使用特定的方法达到目的，需要用户刷新页面等。 |
| 三级（Critical） | 严重bug。用户目的无法实现，出现安全性漏洞。 |
| 四级（Blocker） | 致命bug。内存泄露、报500错误、系统崩溃等。 |
bug1：分析界面切换分支，下方的路径会不断增长，且点击跳转404
测试环境：Google Chrome89.0
严重等级：三级，该功能跳转404使得用户功能无法实现。
可复现性：必然发生
复现步骤：在主页点击分析按钮，然后选择其它的分支（可以不断地切换分支），最后点击出现的charts按钮。
情况描述：在仓库的分析页面，不断地切换分支，下方的路径会不断增长，且点击路径按钮会跳转到404页面。
原因分析：用户切换路径后，显示的路径拼接逻辑有错，切该按钮的URL后端未实现。
预期及改进建议：这里的预期功能是要跳转到该分支的commit信息页面，所以路径不应该发生变动，且URL是查询该分支commit信息的URL。
bug1反馈
bug2：可以通过仓库令牌创建用户，且该用户多处按钮跳转404
测试环境：Google Chrome89.0
严重等级：二级，用户可以通过组织管理来达到同样的权限管理目的
可复现性：必然发生
复现步骤：首先在该仓库的项目设置中创建一个仓库的令牌，然后查看项目成员就会发现该令牌创建了一个新的成员，点击查看成员的详情页面，内部的关注、粉丝等按钮均跳转到404页面。
情况描述：可以通过仓库的令牌来创建用户，且该用户界面多处按钮跳转到404
原因分析：后端逻辑为通过该令牌创建一个用户作为登录的载体，但是没有对这种“特殊用户”进行一些接口访问的限制。
预期及改进建议：这里令牌的目的主要是为了对仓库进行更加细致的管理，可以改为使用和用户令牌一样的逻辑。或者限制由该令牌生成的用户不能查看详情页面。
bug2反馈
bug3：使用模板创建仓库会保留模板的相关信息
测试环境：Google Chrome89.0
严重等级：一级，不影响用户使用，但是影响用户分析和体验
可复现性：必然发生
复现步骤：使用模板创建一个仓库，然后可以在提交页面看到相关提交，也可以在贡献者页面看到信息。
情况描述：通过模板创建的仓库会保留模板的日期、开发者等等信息，不利于仓库数据的分析和管理。例如我5月份创建的仓库，显示出了2月份的提交信息，如下：
原因分析：模板其实也是一个仓库，使用模板其实类似于fork了这个模板仓库。
预期及改进建议：希望把模板的相关信息当成首次提交，提交的时间也改为仓库的创建时间。
结论
| 用户体验（10'） | 多个页面处有推广页面，首页过于复杂；多处可以翻译的地方还保留了英文，但总体上便于国人使用。 | 6 |
|---|---|---|
| 功能（20'） | 开发者可以使用常用的、基本的功能，但缺少一些DevOps等功能 | 15 |
| 特点（10'） | 与CSDN结合紧密，可以进行GitHub加速 | 8 |
| 总评 | 一般 | |
| 总分（40'） | 29 |
GitHub
体验
基本功能
- 方便部署项目
GitHub的Actions部分可以帮助我们非常方便地部署项目，即时使用，非常棒！甚至可以编写好需要执行的指令。
- 丰富的分析功能
可以明显看出，GitHub的分析部分更加丰富，贡献者、网络、编码频率等都有，内容更加详细清晰。
- 基本的代码托管功能
GitHub同样支持基本的代码托管功能，包括仓库的管理、分支管理、issue管理、项目成员管理、代码合并、组织管理等功能。但是和CODE.CHINA相比较，可以明显感觉出GitHub的各项功能更加丰富和细致。
优点
- 界面简洁清晰。不管是哪个界面，都能明显感觉出界面上的每一个组件都是为了程序员服务的（为黑色主体点个赞！），没有过多无用的信息，使用上较为舒适。
- 功能丰富。GitHub上的功能基本满足了大部分程序员的需求，不管是初级程序员还是骨灰级程序员。不仅如此，在很多方面也积极与其它产品（如阿里云）进行结合，更加方便用户的使用。
- 海量高质量开源代码。不得不说，作为历史悠久的代码托管平台，上面聚集了各个方面的行业大牛，打造了一个全球最大的开源社区。不仅能找到很多著名的项目，也能找到实现自己需求的开源代码。
缺点
- 网速慢。这个缺点非常致命，在国内使用GitHub比较慢，且经常性连接超时。
改进意见
- 国内使用网速慢的问题希望能得到解决。
- 希望能对一些庞大的开源群体做一些更加符合他们的设计，例如能否有面向中国开发者的版本。也可以有高校版、企业版之分。
BUG
正在发现bug中。。。
结论
| 用户体验（10'） | 网速慢；界面简洁清晰，使用舒适；很多功能都做了详细的使用说明，适合初学者 | 7 |
|---|---|---|
| 功能（20'） | 几乎满足大部分开发者的需求，甚至可以和很多开发工具、部署平台等结合，方便用户使用 | 18 |
| 特点（10'） | 具有海量的高质量代码，是目前全球最大的开源社区 | 8 |
| 总评 | 好，不错 | |
| 总分（40'） | 33 |
Gitee
体验
基本功能
- 针对不同人群有不同版本
这也是我建议助教使用Gitee来进行软工实践，而不是GitHub的原因之一。Gitee针对不同的人群有不同的版本，可以适应多种人群，目前支持企业版、高校版。
- 支持从GitHub和GitLab导入仓库
- 丰富的服务板块
这一部分是我认为Gitee最有特点，也是我个人认为最出色的部分。服务的板块内部具有非常丰富，高效利于开发的功能。包括JavaDoc文档生成、专业代码质量分析工具、扫描代码缺陷、代码规范、CVE漏洞等功能。这部分功能真是太棒了！
- 具有丰富的开源软件
相较于其它的平台，Gitee还有多种开源软件的功能。
- 基本的代码托管功能
Gitee同样支持基本的代码托管功能，包括仓库的管理、分支管理、issue管理、项目成员管理、代码合并、组织管理等功能。
优点
- 适合不同人群。既有高效版、又有企业版。
- 中国化的平台。相较于GitHub，Gitee更加适合国人的使用，也没有网速的问题。
- 在很多细节的部分贴近了程序员的要求，比如Gitee Scan等功能，这是GitHub、Code.China欠缺的部分。
- 开源软件部分对很多的开源代码做了比较细致的分类，利于程序员找代码。
缺点
- 相较于GitHub，开源代码量不足。
改进意见
- 推广、吸引更多的开发者在平台上开源代码。
- 定位在中国用户，进行一些更加符合中国习惯的改进。
- 功能上借鉴GitHub，丰富分析等功能。
- 希望可以和更多的开发工具进行结合。
BUG
bug1：私有仓库的仓库挂件功能跳转404页面
测试环境：Google Chrome89.0
严重等级：一级，不影响主要功能。
可复现性：必然发生
复现步骤：首先创建一个私有仓库，在管理的界面下点击仓库挂件，之后会跳转404界面。
情况描述：私有仓库的仓库挂件功能跳转404界面（公有仓库正常使用）。
预期及改进建议：将此项功能的权限开放给私有仓库，使其达到和公有仓库一样的效果。
采访
- 采访者背景，为什么选择这个人采访？TA 的需求是什么？
大三在校生，他平常有使用Gitee，需求主要是备份，或者团队开发项目。
- 实际使用的产品栏目
Gitee
结论
| 用户体验（10'） | 适合国人使用；界面简洁清晰 | 8 |
|---|---|---|
| 功能（20'） | 几乎满足大部分开发者的需求；虽然只能和部分开发工具结合，但是具有更加细致的代码分析等功能 | 17 |
| 特点（10'） | 针对不同人群有不同版本；好用的服务板块 | 9 |
| 总评 | 好，不错 | |
| 总分（40'） | 34 |
分析
开发时间估计
代码托管平台是一个非常庞大的平台，现实中也是由一个庞大的团队复杂开发维护的，仅由6名计算机毕业的大学生开发是非常困难的。CODE.CHINA、GitHub、Gitee三类产品较为相似，故一起做如下分析：
6人的开发团队，假设1人产品经理、1人测试、1人UI设计、1人前端开发、2人后端开发。
目前预计开发时间如下：
- 分析设计
这部分假设大部分参考GitHub，全员参与。包括界面设计、类图、数据库设计、安全性设计、功能需求分析等等方面。预计最初需要至少1个月，且由于毕业生缺乏经验，仅能得到一个半成品，后续可能还会修改。所以最终预估需要100天以上。
- 前端
假设完成一个界面需要的内容为界面结构、UI、前后端交互、安全性、测试、界面整合等。由大概4人参与，一个界面大概需要5天时间。初步估计大概至少有70个界面（包括后台界面）以上，所以纯开发时间至少350天以上。其中还需要算上休息日、节假日等，同时因为开头不完善的分析设计，可能需要修改，重构，则至少在700天以上的时间。毕业生的编码能力并不强，学习的时间至少150天左右。所以最终预估需要850天以上。
- 后端
首先是基础功能实现。一个功能接口的开发+单元测试由1人开发假设需要2-3天，5人参与的后端则每天能开发1-2个接口。预估每个界面的接口数量10-20个，则至少需要525天以上时间。
第二是安全性开发，包括权限管理等，保证能挡住一些攻击。这部分至少需要100天以上时间。
第三是并发性开发，保证能承受足够的并发。这部分至少需要100天以上时间。
综上，纯开发时间在725天以上。休息日、节假日大概200天，修改代码（需求的变动）、学习的时间大概350天以上，所以最终预估需要1275天以上。
- 前后端联调、测试
联调、测试一个界面由6人共同参与，至少需要2-3天时间，所以大概需要200天以上时间。算上休息、学习、甚至大范围修改代码，最终预估需要400天以上。
- 总结
综述所述，完成整个过程得到一个代码托管平台，6名毕业生，大概需要1775天以上的时间，大概是4-5年时间，而且这个系统还是一个不那么完善的系统。
CODE.CHINA
- 分析这个软件目前的优劣(和类似软件相比)，这个产品的质量在同类产品中估计名列第几？
CODE.CHINA在三个产品中出现的时间最晚，不管是在使用功能上，还是在开源代码的体量上，相较于其它两个产品都略显不足，故估计排在第三。
2. 从各方面的问题，推理出这个软件团队在软件工程方面可以提高的一个重要方面(具体建议)。
从用户使用上，建议先进行一遍细致的测试，将一些较为浅显的bug修复。
从功能上，建议参考Gitee和GitHub，提供更加完善且符合中国人的功能。
从市场的上，建议大力宣传，吸引高质量代码“入驻”。
3. 你在第一部分发现的bug，为何软件团队不能在发布前修复？
本人发现的bug均是一些较为浅显的bug，故其中存在开发人员粗心大意和测试把关不严的原因。不过，在本人进行反馈后，马上就有相关人员对我反馈的bug进行回复，并安排人解决，可见开发者还是较为上心的。
GitHub
- 分析这个软件目前的优劣(和类似软件相比)，这个产品的质量在同类产品中估计名列第几？
GitHub在市场中出现的最早，经受了长久的市场考研。各方面功能均较为完善，且可以满足各类程序员的要求。虽然无法像Gitee满足更细致人员的需求，但它的定位是面向全世界的开发者的，且目前在业内最为出名，具有大量高质量的代码，估计名列第一。
2.从各方面的问题，推理出这个软件团队在软件工程方面可以提高的一个重要方面(具体建议)。
希望在使用上可以针对部分的人群进行更加细致的功能，满足不同用户的需求。
3.你在第一部分发现的bug，为何软件团队不能在发布前修复？
除了在国内经常连接超时的问题，没有发现其它太大的bug。从这一点也能看出，GitHub是较为完善的一款产品。
Gitee
- 分析这个软件目前的优劣(和类似软件相比)，这个产品的质量在同类产品中估计名列第几？
Gitee可以说是目前最为适合中国人使用的一款代码托管平台了，因为定位的是中国化的平台，所以相较于GitHub，虽然开源代码量和世界知名度不足，但是在功能上确是适合国人的，且其还能面向高校版和企业版的功能。估计名列第二。
2.从各方面的问题，推理出这个软件团队在软件工程方面可以提高的一个重要方面(具体建议)。
希望在使用上可以针对部分的人群进行更加细致的功能，满足不同用户的需求。
3.你在第一部分发现的bug，为何软件团队不能在发布前修复？
我发现的这个bug其实是比较难发现的，因为仓库挂件的功能本来就多时应用在公开的仓库上，对外展示用的，而这个bug是在私有仓库下才会出现的bug。所以出现的原因可能是测试不够严格。
建议和规划
市场概况
- 市场有多大？
目前可以认为只要是需要用到大量代码的从业人员都会是市场的一部分。
这其中不仅仅包括了计算机相关的行业，同样也涉及通信、电气等行业。只要是需要用到大量代码的行业，都需要有一个平台进行代码托管。
除了商业上，同时还有教育、科研领域人员同样需要代码托管平台。
除此之外，代码托管平台甚至不一定要托管代码，同样可以作为一些非代码信息的发布平台。
综述所述，代码托管平台发展至今，GitHub上不仅仅发布代码，也发布了其它的信息。使用者中大部分是计算机相关人员，同样也包括了大量的非计算机相关人员。
- 直接的用户有多少？潜在的用户又有多少？
中华人民共和国工业和信息化部最新报告显示：软件和信息技术服务业从业人数稳步增加，2020年末，全国软件和信息技术服务业从业人数704.7万人，比上年末增加21万人，同比增长3.1%。
根据图表可知，国内直接用户至少在700万人以上，潜在用户至少在30万人。
市场现状
- 目前市场上有什么样的产品了？
目前市场上较为常用的产品为GitHub、GitLab、Gitee、CODE.CHINA等。
- 上述产品的定位、优势与劣势在哪里？
| 产品 | 定位 | 优势 | 劣势 |
|---|---|---|---|
| GitHub | 面向全球开发者 | 庞大的开发者和生态体系，和世界国家50强公司、大量开发工具的合作 | 国内使用较为困难 |
| GitLab | 面向专业的开发者 | 更加适合专业的从业开发人员 | 对初学者不够友好，适用小群体的专业人员的代码托管 |
| Gitee | 面向国内开发者 | 更加适合国内的从业开发人员 | 缺少大量高质量开源代码 |
| CODE.CHINA | 面向国内开发者、CSDN用户 | 依托于CSDN的庞大流量 | 功能、代码均不足 |
- 上述产品之间呈现什么样的关系
毫无疑问，四个产品都有功能重叠的部分，互相之间都具有竞品关系。在国内，使用GitHub和GitLab具有网络门槛，Gitee和CODE.CHINA是较为激烈的竞品关系。但因为GitHub庞大的生态体系，可以说GitHub不管在哪个赛道上都有竞品关系。
GitHub官方2020报告中显示，其已具有5600万以上的用户，超过72%的世界50强公司使用GitHub。可以说GitHub目前不管在哪个赛道上都是“霸主”级别。
Gitee官方2020报告中显示，平台已有超过600万用户和18万企业。可以说，Gitee在中国具有非常庞大的市场。
CODE.CHINA的用户默认由CSDN用户迁移过来，且诞生较晚，目前无法评估具体用户数等信息，但是根据网站搜索情况看，目前的开发者数量不如其它产品。
市场与产品生态
- 核心用户群体
计算机相关开发者
- 典型用户
张明，大学学历，30岁，计算机专业，爱好编程，收入为某公司软件开发工程师。表面需求是可以在平台上发现自己感兴趣的项目，参与开发。潜在需求是需要在平台上寻找高质量的开源代码以增加工作效率。
李成，大学在校生，22岁，软件工程专业，爱好参与竞赛，收入为各项竞赛奖金。表面需求是希望在平台上进行软工实践作业。潜在需求是希望在比赛中使用平台来进行团队编程、或者查找利于比赛的代码。
王丽丽，博士学历，35岁，计算机专业，爱好科研、开源代码，收入为开源项目赞助、专利费等。表面需求是可以在平台上开源项目、开源论文研究代码等。潜在需求是通过平台来提升自身名气。
- 产品的用户群体之间是否存在一定的关系？是否有利用其相互作用二次构成特定用户生态的可能性？
用户一和用户二有一定关系。他们都需要在平台上查找自己需要的开源项目。用户一和用户三有一定关系，学生时代没有太大经济压力，有实力的学生或许可以成为开源项目开发者的一员。
- 产品的子产品，以及其他相关产品之间是否存在一定的关系？是否有利用各个产品特性之间的相互关系二次构成产品生态的可能性？
GitHub的特点是面向所有的、全球的开发者；GitLab面向专业的开发人员、企业；Gitee可以面向企业，也可以面向高校；CODE.CHINA可以获得CSDN大量的引流。它们虽然功能大体相同，但具有自身不同的定位和优势，互相之间的人群可以有重合。比如，作为学生自己通过CSDN学习知识可能用到CODE.CHINA，管理自己的代码可以使用适合国人的Gitee，软工实践等学习或与全球开发者交流可以使用GitHub，在企业中实习或许会使用到GitLab。
产品规划
- 功能以及NABCD分析
我希望在Gitee上实现一个功能，这个功能可以将博客园的班级组织和Gitee的高校版功能进行结合，在两者之间搭建一个桥梁。博客园发布的作业要求等可以同步到Gitee中，组织和人员也无需注册，Gitee中自动创建。作业完成后Gitee可以生成每一位学生的代码分析文档，其中包括自动查重、提交次数等，在博客园中可以很方便地引用Gitee中的代码。
| N | 高校老师在布置作业的时候需要组织同学在博客园注册账号并加入班级，之后又需要在GitHub或Gitee注册账号并加入组织，之后又需要老师人工在平台上查看代码提交情况，非常麻烦。 非常适合一些既需要发布博文报告，又需要编码的教学任务（这部分教学任务非常多） |
|---|---|
| A | 在博客园和Gitee之间搭建一个桥梁，方便老师同学的教学。可以自动通过Gitee对提交代码进行分析，并显示统计情况在博客园上，也可以在博客园的博客中上方便地引用Gitee代码。 |
| B | 方便老师同学完成教学任务 |
| C | 目前市面上没有相关功能 |
| D | 从下次软工实践作业开始实践 |
- 角色配置
前端开发：1人
后端开发：2人
美工：1人
测试：1人
产品经理：1人
- 16周的详细计划
| 周 | 任务 |
|---|---|
| 1 | 需求分析等 |
| 2 | 数据库设计、安全性设计、并发设计等 |
| 3 | 后端开发博客园账号登录注册Gitee接口及单元测试；前端开发班级管理页面 |
| 4 | 后端开发接收博客园数据创建作业功能；前端开发作业管理页面 |
| 5 | 后端开发代码查重功能 |
| 6 | 后端开发作业代码数据统计功能；前端开发统计页面 |
| 7 | 后端安全开发，防御各种攻击 |
| 8 | 后端并发开发，增强并发性能 |
| 9 | 前后端联调并修复bug |
| 10 | α测试并修复bug |
| 11 | 发布α版本并收集用户的建议 |
| 12 | 根据用户建议对功能进行修改 |
| 13 | 进行安全性测试并修复bug |
| 14 | 进行并发压力测试并修复bug |
| 15 | 进行β测试并修复bug |
| 16 | 项目上线 |
