目录

项目开发维护 | 开源规范

在开发过程中往往会涉及到很多规范,下面讲一下开发中常用的规范。当然同类规范也会因为团队差异而有所不同。常用的规范大致分为两类:

  • 编码类规范:主要包括目录规范、代码规范、接口规范、日志规范和错误码规范
  • 非编码类规范:主要包括开源规范、文档规范、版本规范、Commit 规范和发布规范

1. 开源规范

1.1. 为什么要开源

  • 一是,开源项目在代码质量、代码规范、文档等方面,要比非开源项目要求更高,在项目开发中按照开源项目的要求来规范自己的项目,可以更好地驱动项目质量的提高;
  • 二是,一些大公司为了不重复造轮子,会要求公司团队能够将自己的项目开源,所以提前按开源标准来驱动项目开发,也会为我们日后代码开源省去不少麻烦。

1.2. 开源协议

一个开源项目一定需要一个开源协议,开源协议规定了你在使用开源软件时的权利和责任,也就是规定了你可以做什么,不可以做什么。所以,开源规范的第一条规范就是选择一个合适的开源协议。

业界有上百种开源协议,每种开源协议的要求不一样。经常使用的有以下 6 种开源协议,也就是 GPL、MPL、LGPL、Apache、BSD 和 MIT。

  • GPL: General Public License,开源项目最常用的许可证,衍生代码的分发需开源并且也要遵守此协议。该协议也有很多变种,不同变种要求会略微不同。
  • MPL: MPL 协议允许免费重发布、免费修改,但要求修改后的代码版权归软件的发起者,这种授权维护了商业软件的利益,它要求基于这种软件的修改无偿贡献版权给该软件。
  • LGPL: Lesser General Public Licence,是 GPL 的一个为主要为类库使用设计的开源协议。LGPL 允许商业软件通过类库引用的方式使用 LGPL 类库而不需要开源商业软件的代码。但是如果修改 LGPL 协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用 LGPL 协议。
  • Apache: Apache 协议是 Apache 软件基金会发布的一个自由软件许可证,Apache 2.0 协议除了为用户提供版权许可之外,还有专利许可,非常适合涉及专利内容的项目。
  • BSD: BSD(Berkeley Software Distribution,伯克利软件发行版)。BSD 协议在软件分发方面,除需要包含一份版权提示和免责声明之外,没有任何限制,该协议还禁止用开源代码的作者/机构名字和原来产品的名字做市场推广。
  • MIT: 协议的主要内容为:该软件及其相关文档对所有人免费,可以任意处置,包括使用,复制,修改,合并,发表,分发,再授权,或者销售。唯一的限制是,软件中必须包含上述版权和许可提示。MIT 协议是所有开源许可中最宽松的一个,除了必须包含许可声明外,再无任何限制。

1.3. 如何选择开源协议

可以参考乌克兰程序员 Paul Bagwell 画的这张图:

https://img.dawnguo.cn/dev/61b4d5da6c8327b738e9657c6c144000.png

在上图中,右边的协议比左边的协议宽松,在选择时,可以根据菱形框中的选择项从上到下进行选择。另外,因为 Apache 是对商业应用友好的协议,使用者也可以在需要的时候修改代码来满足需要,并作为开源或商业产品发布 / 销售,所以大型公司的开源项目通常会采用 Apache 2.0 开源协议。

1.4. 开源规范

在参与开源项目或者按照开源项目的要求来规范代码时,总得有以下这些规范,其中重要的已经加粗了(其实一切为了让项目变得更优秀的规范,都应该属于开源规范)。

  • 项目结构:一个开源项目应该有一个合理、专业的、符合语言特色的项目结构。

  • 严格遵循代码规范:开源的代码,面向的人群是所有的开发者,一个不规范的代码,可读性差,不利于其他开发者阅读和贡献代码。

  • 代码质量:开源的代码,一定要保证代码的质量,一个低质量的代码,不仅隐藏了很多性能和功能缺陷,而且还会影响开源项目的品牌,进而影响开源效果。

  • 单元测试覆盖率:一个开源项目,要保证整个项目的单元测试覆盖率。一方面在第三方开发者开发完代码之后,能够很方便地对整个项目做详细的单元测试,另一方面可以保证代码的质量,使开源项目更专业,可以更加安心的发布版本

  • 版本发布规范:开源项目要遵循既定的版本规范,整个项目的更新迭代,要有版本号,目前用的比较多的是语义化的版本规范。

  • 向下兼容:代码要做到向下兼容,这样可以尽可能减少发布变更的影响,遵循语义化的版本规范,可以在一定程度上保证代码的向下兼容能力

  • **安全:开源的代码,要保证整个代码库和提交记录中,不能出现类似内部 IP、内部域名、密码、密钥这类信息。**否则,就会造成敏感信息外漏,可能会对我们的内部业务造成安全隐患。

  • 详细的文档说明:要保证代码能够被其他开发者很容易的阅读和贡献代码,所以不仅要保证文档的质量和数量,还要确保有某些需要的文档:

    • LICENSE(如果是开源项目,LICENSE 是必选的):软件协议,声明该开源项目遵循什么软件协议。
    • README.md:README 文件,放在项目的根目录下,包含项目的描述、依赖项、安装方法、使用方法、贡献方法、作者和遵循的软件协议等。
    • CHANGELOG:目录,用来存放版本的变更历史,方便其他开发者了解新版本或旧版本的变更内容。
    • Makefile:对于一个复杂的项目,通常也会包含一个 Makefile 文件,用来对项目进行构建、测试、安装等操作。
    • CONTRIBUTING.md:用来说明如何给本项目贡献代码,包含贡献流程和流程中每个环节的详细操作。
    • docs:目录,用来存放本项目所有文档,例如:安装文档、使用文档、开发文档等。一些重要的文档,可以链接到项目根目录的 README.md 文档中。这些文档要确保开发者能够轻松的理解、部署和使用该项目。
    • examples:完善的 examples,可以帮助用户快速学习和使用开源项目。

    开源项目的文档最好有中英文 2 份,优先使用英文,让来自全球的开发者都能了解、使用和参与你的项目。

  • 好的 Commit Message 记录:开源项目在 commit 时,要遵循一定的规范,这样其他开发者才能够快速浏览和理解变更历史,减小学习成本。

  • Git 工作流:选择合适的 Git 工作流,并遵循 GIt 工作流使用规范,例如 Gitflow 工作流。

  • 发布可用的版本:要确保每一次发布都经过充分的测试,每一个发布的版本都是可用的。

  • 持续的更新:一个好的开源项目,应该能够持续的更新功能,修复 Bug。对于一些已经结项、不维护的开源项目,需要及时的对项目进行归档,并在项目描述中加以说明

  • 及时的处理 pull request、issue、评论等:当项目被别的开发者提交 pull request、issue、评论时,要及时的处理,一方面可以确保项目不断被更新,另一方面也可以激发其他开发者贡献代码的积极性

  • 建立讨论小组:如果条件允许,最好和贡献者建立讨论小组,每周或每月组织讨论,共同维护。

  • 做好推广:如果有条件,可以宣传运营开源项目,让更多的人知道,更多的人用,更多的人贡献代码。例如:在掘金、简书等平台发表文章,创建 QQ、微信交流群等。

1.5. 参考

  1. https://github.com/marmotedu/geekbang-go/blob/master/%E5%BC%80%E6%BA%90%E8%A7%84%E8%8C%83%E8%AF%A6%E7%BB%86%E5%88%97%E8%A1%A8.md
  2. 极客时间.孔令飞.《Go 语言项目开发实战》