SPlayerX 协作开发

最近这两周,SPlayerX@2018 项目又有了不少进展。包括 7 个 Forks,28 个 Stars。支持了更多的视频格式,也有了更多的交互功能。我们希望能够在6月尽快交付第一个 Pre-alpha Version,所以也会希望更多童鞋加入我们的开发。远程参与项目,也可以快速提高自己的技术水平,学到很多学校中学不到但在工作中会非常有帮助的技巧。一份参与过开源项目的履历,也会被技术面试官格外重视。

 

README

查看 README 项目文档,可以初步了解 SPlayerX@2018 这个项目技术框架。根据我们的 README 文档,应该很快就可以编译通过,运行起一个开发中的版本。这个过程,对项目功能、代码和技术设计方向也能有一个初步的了解。

 

ISSUES

和所有开源项目一样,我们都有 Issues 区,也就是问题汇总。对项目有兴趣的爱好者,可以在 Issues/Bugs 中先找到一个自己感兴趣的小问题,作为第一个目标并尝试解决它。

不过 SPlayerX@2018 项目还是刚刚开始,所以目前的 issues 倒不是很多。而且我们的项目设计文档和任务管理主要还只是记录在我们团队的 Notion 中。所以,如果想参与项目,我更建议你直接Email给我 tomasen@gmail.com ,沟通我们的想法。

 
GitHub-SPlayerX.png

Git 版本管理工具

开源项目中使用的版本管理主要是 Git 工具。Git 确实有一定的学习成本。但只有掌握 Git,才有可能和其他项目开发者并行开发并进行友好的协作。如果之前对 Git 的使用不熟悉,那么在完成第一个 Todo/Issue 的阶段,也是摸熟 Git 的好时机。

 

Fork

Fork 是个很难准确翻译的词,原意是餐具中的叉子。在开发者的世界,或可引申为师出同源的几个叉子尖。当你对项目有一想法时,项目管理者可能并不愿意在项目中看到这样的实验性分支。这时就可以 fork 一个分支项目,来实现自己的想法。尤其是 github 大流行的背景下,fork 后再 merge back 变得很容易,所以 fork 对项目的维护负担也非常小,越来越可以忽略不计。

 

PR(Pull Request)

决定开发的目标之后就是 fork 和 PR 了。PR 就是 Pull Request,这是一个 Git 概念,相当于申请 Merge。换句话说,就是要求项目来 Pull 自己的Commit的代码。

Screen Shot 2018-06-08 at 1.56.23 AM.png

在项目进入一个稳定阶段后,就不允许再直接修改主分支了,对于SPlayerX@2018 来说也就是 develop 分支。所以,包括我们团队自己的代码提交,也要先 fork,修改代码后,再通过网页提交 PR。

提交PR的好处是方便代码审核和CI工具对质量的判断。

 

代码规范

我们对代码规范的要求还是比较严格的。毕竟在几十人以上和近百万行代码的项目中,没有代码规范就很难保证代码的可读性。所以在撰写代码时,一定要注意是否符合该项目中对代码规范的要求,以免被退票。

 

遵守规则

SPlayerX@2018 项目中还有一些关于技术选择的约定。比如何时应该使用 vuex 的 data store,何时使用 Global Event Bus。这些都有在README中说明。

一些大型项目中,可能还有除了代码规范之外的项目规则。建议都要仔细阅读清楚主页或开发者社区的相关说明,以避免浪费时间。

 

联系项目管理者

当有一些可能带来重大改变的想法时,务必要先和项目管理者保持良好的沟通。通过 email 等方式将你的想法描述清楚。获得项目管理者和项目中其他开发者的认同和帮助是一个关键。附带提一句,初次联络时,务必不要忘记自我介绍,这并不仅仅是礼貌,更是建立信任的主要基础。

 

成为固定成员

通过积累PR和建立信任的阶段之后,通常管理者都会主动邀请你成为固定的开发成员。我们的项目当然很欢迎有同学愿意加入成为项目固定成员。而且暑假快到了,对项目有兴趣的实习申请都可以 Email: tomasen@gmail.com 投递简历。